Gestión de Cambios. Tutorial desarrollado por: TATIANA ARROYAVE MADRID LUISA FERNANDA ARANGO FERNÁNDEZ DANIEL ZULUAGA SIERRA

Transcripción

1 Gestión de Cambios Tutorial desarrollado por: TATIANA ARROYAVE MADRID LUISA FERNANDA ARANGO FERNÁNDEZ DANIEL ZULUAGA SIERRA UNIVERSIDAD EAFIT Medellín 2010

2 Gestión de Cambios Este tutorial hace referencia al procedimiento mediante el cual se inician, diseñan, revisan e implementan cambios requeridos sobre partes o documentos ya existentes. Su importancia radica en la Inclusión de la descripción de los tres ítems básicos de la gestión de cambios: PR (problema report), ECR (Engineering Change Request) y ECN (Engineering Change Notification), además de los procesos básicos a realizarse por medio de estos. Gestión de cambios hace referencia al procedimiento mediante el cual se inician, diseñan, revisan e implementan cambios requeridos sobre partes o documentos ya existentes. Administrar de una forma correcta estos cambios, le permite a una organización mejorar sus productos y obtener mayor éxito. Los procesos de gestión de cambios son administrados por el grupo de gestión de configuración (Configuration Management), dentro de cual se encuentran los Especialistas en Cambios (Change Specialists) que coordinan y toman decisiones para permitir o no llevar a cabo los cambios y avanzar entre los diferentes estados. Sin embargo, los problemas, solicitudes o notificaciones de cambio pueden ser ingresados por diferentes personas dependiendo de los permisos establecidos. Los tres ítems básicos de la gestión de cambios son: PR: Reporte de problema (Problem Report). Es utilizado para reportar problemas referentes a partes o documentos y puede ser generado por empleados o clientes. ECR: Solicitud de cambio de ingeniería (Engineering Change Request). Es utilizado para solicitar un cambio en una parte o documento. ECN: Notificación de cambio de ingeniería (Engineering Change Notice). Es utilizado para realizar la notificación final de cambio sobre una parte o documento. Para comprender mejor los procesos de efectuar ítems como los tres anteriores, entre otros, es importante saber que en ARAS, dichos procesos están definidos por una serie de actividades que requieren ser ejecutadas en un orden establecido para completar un determinado flujo de trabajo. Cada actividad puede contener de igual forma, cierta lista de acciones que la persona responsable de la presente etapa debe realizar. Todo lo anterior se puede sintetizar en la siguiente imagen que representa todo el flujo de un cambio realizado:

3 Figura 1. Modelo de un Flujo de Trabajo en ARAS 1. REPORTE DE PROBLEMA (PR) Es un procedimiento utilizado para reportar problemas relacionados con alguna parte o documento. Al ser creado, el reporte alerta la compañía sobre dicho problema y entonces entra a ser revisado, verificado y aprobado o también rechazado. El PR puede ser ingresado tanto por un cliente como por un empleado o cualquier persona que tenga acceso a la parte o documento en cuestión. El siguiente es el flujo de trabajo por defecto de un proceso PR en ARAS: Figura 2. Flujo de trabajo para un PR Al ser creado, un PR genera consigo un flujo de trabajo y entra a revisar el reporte de problema (Review PR). Allí un especialista de cambios (Change Specialist) lo analiza y determina si el reporte debe ser rechazado o si le da continuidad y lo remite a una revisión. Si el reporte es aceptado, es asignado a un ingeniero particular, quien responderá por el reporte y estará encargado de investigar a fondo para identificar el problema. El ingeniero documenta todo lo encontrado sobre la investigación en este reporte y decide si no debe ser verificado (PR Unverified) o continuar para verificación. Si el reporte continúa llega a la actividad donde debe ser aprobado por un especialista de cambios, quien revisa que toda la información necesaria respecto al problema esté correctamente ingresada y finalmente lo promueve como un reporte de problema pendiente (PR Pending).

4 Este proceso de aprobación de un PR es posible evidenciarlo en la siguiente figura, donde se muestran las personas que ejecutan cada una de las acciones anteriormente descritas para finalmente promover un PR. Figura 3. Representación con roles del flujo de trabajo de un PR 2. SOLUCITUD DE CAMBIO DE INGENIERÍA (ECR) Por lo general es el resultado de algún Reporte de Problema encontrado, o lo que se generará si se hacen modificaciones en partes o documentos. Una ECR generada de forma proactiva y anticipando un problema es mejor que una generada como consecuencia de un problema ya existente, pues el impacto sobre otras ramificaciones es claramente menor. Si el problema encontrado es muy específico y no altera demasiado otros procesos, es posible entonces adelantarlo en el flujo de trabajo para lograr una más pronta aprobación. El siguiente es el flujo de trabajo por defecto de un proceso ECR en ARAS: Figura 4. Flujo de trabajo para una ECR

5 La solicitud de cambio de ingeniería comienza cuando se vota para enviarla (Submit) a revisión (Review ECR). En esta actividad, un Especialista en Cambios revisa la información ingresada por el Creador de la solicitud y elige si Rechazarla o aprobarla para Revisión Técnica (Technical Review). Al ser Rechazada, el creador de la ECR puede ver los comentarios realizados por el Especialista para volver a remitir la solicitud o cancelarla definitivamente. Cuando el reporte entra en la Revisión Técnica, el Especialista en Cambios asigna la solicitud a un encargado que no sólo sea capaz de identificar el problema, sino también de dimensionar las ramificaciones de éste y de sus soluciones. Aquí, el encargado de la Revisión Técnica provee información, datos, comentarios y recomendaciones sobre la ECR, para luego enviarla a la siguiente actividad de Enrutar (Route ECR). El responsable de tomar esta decisión es el Especialista en Cambios, quien decide si es una Solicitud Directa (Fast Track ECR) o si requiere pasar por un Comité de Revisión de Cambios (Change Review Board - CRB). Si selecciona la ruta directa para la ECR, entonces ésta pasa a la actividad de Disposición (Disposition ECR) donde es devuelta nuevamente al encargado. Finalmente es él quien determina si la ECR es Aprobada, Rechazada o si es necesario Investigar más a fondo sobre ella. Si la ruta seleccionada por el Especialista en Cambios es la de remitir la ECR al CRB, entonces debe elegir si es necesaria una reunión con todos los miembros de la junta para discutir el problema o si es posible resolverlo en línea con ellos. El especialista debe presentar toda la información completa a los miembros del comité, quienes decidirán si deben reunirse (luego de intentarlo en línea) y, en última instancia si la ECR requiere mayor información, es Aprobada o Rechazada. Este proceso de aprobación de una ECR es más comprensible si se ilustra con la siguiente figura, para así evidenciar las etapas y acciones que se efectúan sobre cada una de ellas y sus responsables. Figura 5. Representación con roles del flujo de trabajo de una ECR

6 3. NOTIFICACIÓN DE CAMBIO DE INGENIERÍA (ECN) Es un proceso simple para implementar cambios dentro de una organización. Los cambios pueden ser de tres tipos: Agregar una parte o un documento: El proceso ECN se utiliza para llevar la parte desde su estado Preliminar (Preliminar) al estado de Lanzamiento (Released). Modificar una parte o un documento: El proceso ECN modifica el estado de la parte existente por Reemplazado (Superseded), y lleva la nueva revisión de la parte del estado Preliminar al de Lanzamiento. Eliminar una parte o un documento: El proceso ECN lleva la parte de su estado de Lanzamiento al de Reemplazado. El siguiente es el flujo de trabajo por defecto de un proceso ECN en ARAS: Figura 6. Flujo de trabajo para una ECN La ECN se comienza por un miembro del grupo gestión de configuración (CM). Uno de los especialistas de cambios llena la información requerida y adjunta las ECR y los archivos necesarios para ingresar la ECN. En la actividad de planeación (ECN Planning), el especialista de cambios toma decisiones sobre la propagación de los cambios en las líneas de ensamble de las partes. Le asigna además un encargado, por lo general ingeniero o técnico, quien es el responsable de la actividad de actualizar documentos (Update Documents). El encargado actualiza las listas de partes (BOM), los planos, las especificaciones y demás documentos afectados por este cambio, que no son solamente las partes cambiadas, sino todas aquellas que tengan algún tipo de relación con ellas. La ECN es devuelta al especialista en cambios para la actividad de revisión de documentos (Review Documents), de donde puede rechazar la ECN o aprobarla para que pase a una intervención (ECN Audit) y terminada esta sea lanzada la ECN (ECN Released), lo que actualiza automáticamente el estado de ciclo de vida de las partes y documentos.

7 La siguiente figura facilita la compresión del flujo de trabajo de una ECN identificando las personas que efectúan cada una de las actividades en las diferentes etapas del proceso de aprobación. Figura 7. Representación con roles del flujo de trabajo de una ECN