Post on 10-Apr-2016
description
h
2013
Grupo Santander Jamilis, Eduardo
Enero
Gestión de Cambios Ingreso de solicitudes de cambio
Pág. 1
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
Gestión de Cambios – Ingreso de solicitudes de Cambio
Índice
Índice ............................................................................................................................................................. 1
Introducción .................................................................................................................................................. 2
Ambientes ..................................................................................................................................................... 6
Producción ................................................................................................................................................ 6
Ambientes previos .................................................................................................................................... 6
Selección del circuito en Producción ............................................................................................................ 6
Planilla de circuitos ................................................................................................................................... 6
Ejemplo de Creación de un Cambio .......................................................................................................... 7
Datos básicos y asignación de nivel de riesgo ...................................................................................... 8
Clasificación y Clase de Cambio .......................................................................................................... 10
Información de Trabajo ....................................................................................................................... 11
Tareas .................................................................................................................................................. 11
Asignación ........................................................................................................................................... 13
Relación con otros tickets ................................................................................................................... 13
Fechas ................................................................................................................................................. 15
Datos Requeridos ................................................................................................................................ 15
Selección del circuito en Ambientes previos .............................................................................................. 18
Aviso Importante – Impacto en Producción ........................................................................................... 18
Criterio .................................................................................................................................................... 18
Solicitudes al área Administración de Ambientes .................................................................................. 21
PIR (Post Implementation Review) ............................................................................................................. 22
Preguntas Frecuentes ................................................................................................................................. 25
Pág. 2
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
Introducción
El proceso de Gestión de Cambios tiene tiene como principal objetivo la evaluación y
planificación del proceso de cambio para asegurar que, si éste se lleva a cabo, se haga de la
forma más eficiente, siguiendo los procedimientos formales establecidos y asegurando en todo
momento la calidad y continuidad del servicio TI.
Esto implica que deben cumplirse los estándares, procesos y procedimientos de
implementación establecidos. Y es área de Gestión de Cambios de Produban la encargada de
verificar su cumplimiento, en tiempo y forma.
Es por esto que no puede impactarse en Producción NINGÚN cambio sin un pedido de cambio
asociado. No es válido hacer los cambios pedidos informalmente, y LUEGO ingresar un pedido
para regularizarlo.
Todos los cambios deben ser ingresados al sistema de Gestión (en Remedy) con la anticipación
mínima requerida, según el caso. A estos cambios los clasificamos como normales y son
analizados en primera instancia por los especialistas, verificando la factibilidad de su ejecución
y luego por un CAB (Change Advisory Board o Comité de Cambios) con participación de todos
los involucrados, Isban, Produban y Banco Santander Río, que evalúan el riesgo y acuerdan la
realización del mismo, o lo rechazan fundadamente, ya sea por la naturaleza del cambio o por
la ventana escogida para su realización.
No es admisible el ingreso de un ticket solicitando la implementación de un componente, si el
mismo no está terminado y en condiciones de funcionamiento, a la fecha de ingreso del ticket.
El plazo de 10 días de anticipación en el pedido de un cambio normal es necesario para realizar
un adecuado análisis de impacto y poder garantizar la integridad del proceso, pero NO DEBE NI
PUEDE usarse para “ganar tiempo” pidiendo implementaciones antes de contar con el
componente. Eso de algún modo implicaría para el CAB aprobar un “cheque en blanco” sin
saber qué es exactamente lo que ese componente hará en su forma final.
Cuando por alguna razón un cambio NO PUEDE o NO DEBE esperar el plazo establecido para un
cambio normal, puede pedirse un cambio como emergencia. En este caso, ese cambio que debe
ser adecuadamente fundamentado (no sólo es su necesidad, sino también respecto a su
urgencia) debe ser analizado por el ECAB (Emergency CAB o Comité para Cambios de
Emergencia) que es el órgano designado para autorizar la aplicación de estos cambios.
En estos casos, se debe enviar oportunamente la siguiente información con el detalle de los
cambios a tratar en el comité ECAB como se describe a continuación:
Pág. 3
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
1. Enviar antes de la hora del comité 11hs, de lunes a viernes 2. mail: gestiondecambios@produban.com.ar (CASILLA GESTION DE CAMBIOS) 3. Utilizar la siguiente planilla
PLANILLA MODELO
----------------------------------------------------------------------------------------------------------
Nro de CRQ:
Solicitante:
Participantes del ECAB:
------------------------------------------------------------------------------------------- ---------------
Motivo de la Emergencia:
Genera corte de Servicio: Cuanto dura el corte de servicio:
Aplicativos y/o recursos afectados:
---------------------------
---------------------------
Detalle:
Plan de Implementación:
Plan de Pruebas:
Plan de Vuelta atrás:
Fecha Inicio:
Fecha Fin:
EJEMPLO PLANILLA CON DATOS
----------------------------------------------------------------------------------------------------------
Nro de CRQ : CRQ000000059576
Solicitante: Miguel Duffy
Participantes del ECAB: Miguel Duffy
Pág. 4
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
Motivo de la Emergencia: Se realizó una revisión proactiva del servicio de PPRC donde
se detectaron errores en 3 LUNs.
Para mitigar este problema se deben migrar los datos a nuevas LUNs en modo PPRC para
estar preparados ante un DRP producto de Falla en producción.
Genera corte de Servicio: NO Cuanto dura el corte de servicio: N/A
Aplicativos y/o recursos afectados:
---------------------------
CRQ000000054612 - Reasignacion de LUN para PPRC
---------------------------
Detalle: Por problemas en el PPRC se procederá a migrar los datos de las LUN existentes
a una nueva LUN en modo PPRC. Las bases que están afectadas son
RIO57 >El FS comprometido es /RIO57/data14 -->
RIO2 >FS comprometidos > /RIO2/data07 y /RIO2/index04 --> 3hs
Plan de Implementación: Se migrara los datos de las LUN actuales a una nueva, en
modo PPRC. Esto no requiere corte de servicio.
Plan de Pruebas: verificar la asignación de LUN, y consultar con storage que estén en
modo PPRC, antes de comenzar la tarea.
Plan de Vuelta atrás: Ante cualquier problema no mover los datos a las nuevas LUN y
frenar el cambio.
Fecha Inicio: 2012-09-21 19:00:00
Fecha Fin: 2012-09-22 10:00:00
Una vez impactados los cambios (implementaciones, configuraciones, instalaciones, etc.) el
solicitante o alguien de su grupo debe evaluar dicho cambio. Esa es la finalidad del PIR (Post
Implementation Review o Revisión post Implementación). Esa evaluación es fundamental para
evaluar la calidad de los cambios que se aplican y proceder al mejoramiento de la calidad en
caso que se detecten deficiencias en el proceso.
Pág. 5
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
Es importante que quienes lean este instructivo hayan leído antes el documento:
Código: ARG-SPA-INT-003-MYO
Título: Instructivo Gestión de Cambios Isban
Objetivo: Describir en forma detallada las actividades del proceso a realizar por Isban para solicitar una implementación o cambios en la infraestructura del ambiente productivo gestionado por Produban según su proceso de Gestión de Cambios corporativo de Produban.
Vigencia inicial: 28 / 09 / 2012
Última revisión: 28 / 11 / 2012
Vigencia hasta: 28 / 11 / 2014
Dirigir Consultas a mail: PROCESOS_ISBAN@santanderrio.com.ar
Es importante tener claros los conceptos expuestos en dicho documento, distribuido por
Arquitectura y Metodología de Isban a todo el personal de Isban Argentina, y que aplica sólo a
los pedidos para el ambiente de Producción.
Es necesario también que tengan conocimiento de lo establecido en la guía del usuario de
cambios http://remedyweb.ar.bsch:9080/arsys/shared/Manuales/7.pdf.
Dependiendo del ambiente del que se trate, los pedidos a la fecha se ingresan por sistemas
diferentes, tal como veremos a continuación.
Pág. 6
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
Ambientes
Producción
Los pedidos de cambio para ambientes productivos se ingresan forma de tickets en Remedy.
Ambientes previos
Los pedidos de cambio para ambientes previos (Desarrollo, Test, Homologación, Pre-
Producción) se ingresan en el sistema de Requerimientos Internos (RI).
Selección del circuito en Producción
Planilla de circuitos
Dentro de la documentación provista hay una planilla, en
http://remedyweb.ar.bsch:9080/arsys/shared/Manuales/2.xls, en la que se muestran los
circuitos posibles. Verificar en 2.xls que NO HAYAN flitros que nos impidan ver el circuito que
necesitamos.
Esta planilla debe abrirse desde la web ante cada nuevo uso, dado que la misma puede sufrir
modificaciones en cualquier momento.
Cuando el solicitante ingresa un ticket, usualmente conoce exactamente cuál es el grupo
resolutor para ese tipo de pedido. En caso de desconocer el grupo implantador y si el mismo
corresponde a IBM, deberá hacer la consulta previamente con la gente de IBM SRIO Cambios
(sriochg@ar.ibm.com), quienes informarán cuáles son los grupos involucrados (uno o más).
En consecuencia, lo que debe hacerse es filtrar la planilla por grupo resolutor, y luego elegir el
circuito más adecuado para el tipo de pedido que estamos haciendo. Ej: si vamos a solicitar la
implementación de un nuevo job en Control-M DS en servidor Unix, NO PODEMOS cargarlo
como corrida de job en control-M , más allá de que eventualmente el grupo resolutor sea el
mismo.
Concretamente la líneas aludidas serían:
Pág. 7
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
Es importante que cada cambio sea tipificado y clasificado adecuadamente ya que de esto
depende que cumpla con el ciclo completo de aprobaciones y sea asignado de manera correcta.
Una vez seleccionado el circuito apropiado, se ingresa a la herramienta Remedy siguiendo las
instrucciones de la guía http://remedyweb.ar.bsch:9080/arsys/shared/Manuales/7.pdf del
usuario de cambios y se carga el ticket correspondiente.
Ejemplo de Creación de un Cambio
Vemos a continuación un ejemplo referido a una solicitud de Catalogación de un nuevo Job en
Control-M DS (distribuido) a correr en el servidor Unix SRVxxxx (primer ejemplo mostrado
arriba).
Pág. 8
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
Para realizar la carga de una solicitud de cambio debe primeramente hacerse clic en la opción “Crear” desde la consola de gestión de cambios, ver ilustración siguiente:
o
Datos básicos y asignación de nivel de riesgo
Luego de hacer clic en la opción “Crear”‖ tal como se muestra en la ilustración anterior, el sistema abrirá una nueva ventana que contiene los datos a cargar en una solicitud de cambio tal como muestra a continuación:
Pág. 9
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
Tal como puede verse en la ilustración, se puede visualizar en la parte superior a la barra que
indica el estado en el flujo del proceso (ver recuadro rojo), y algo más abajo (ver recuadro
verde) puede identificarse a la lista de datos denominados ”Datos Básicos”‖ que deben
completarse. Los que tienen asteriscos son obligatorios. Aquí es donde se asigna el nivel de
Riesgo (N1, N2, N3), el impacto, la prioridad y la urgencia.
Cambios N3 requieren menos días para su ejecución (72 hs. entre la fecha de petición de
autorización y la fecha programada de Inicio en lugar de 240 hs. como lo requiere un ticket N2-
Normal) porque se sabe que son de riesgo acotado y no requieren análisis de impacto. Eso NO
IMPLICA que puedan ejecutarse en menos de 72 horas. Si se requiere que sean ejecutados
antes de las 72 horas, deben ser ingresados como N2 de emergencia y ser tratados en el
respectivo comité diario (ECAB) de las 11 horas del día siguiente, previo envío de la planilla con
la información adecuada.
Las solapas disponibles cambian según la fase del ciclo de vida que se esté transitando.
Algunas solapas (por ejemplo “Aprobadores”) no estarán disponibles hasta que se avance a una
fase determinada.
Como vemos los datos del solicitante vienen precargados. En el campo Empresa, para
empleados de Isban, debe decir ISBAN ARG. Si no es así, por favor informar a Administración
ITSM (administracion_itsm@santanderrio.com.ar) para corregir los datos del usuario.
ARG
Pág. 10
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
Clasificación y Clase de Cambio
Luego se ingresan los datos de Clasificación (que determinan en qué bandeja caerán para ser
programados y ejecutados), así como también la Clase (Normal o Emergencia) y el Motivo del
cambios (Evolutivo, Correctivo (debe estar relacionado con un ticket de Incidencia ingresado
previamente), Auditoría, Normativo (debe tener el identificación de la norma a la cual hace
referencia) o Ejecutivo (debe que estar acompañado con un mail con las aprobaciones de los
Directores Generales de Isban y Produban y la del CIO del Banco).
Como pueden ver, esta información de categorización coincide EXACTAMENTE con la que
encontramos en la planilla publicada (columnas en azul), y que repetimos a continuación:
De este modo sabemos que el cambio está en el circuito correcto, y tendrá los controles,
aprobaciones y resolutores correctos para el tipo de tarea de que se trata.
Pág. 11
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
Información de Trabajo
En esta solapa se debe agregar toda información o comunicación relevante a la solicitud de cambio. Es posible indicar entre otras cosas información adicional relacionada a la implementación, comunicación con el solicitante, resultados de pruebas realizadas, información sobre los riesgos potenciales, datos necesarios para auditorías, etc.
Tareas
Si lo que se está pidiendo sólo requiere de una tarea, la solapa Tareas podría saltearse.
No obstante, se recomienda que siempre que se ingrese un pedido, se verifique la lista de
“Grupos de Tareas” predefinidos para ver si existe uno creado que sea apropiado para el tipo
de requerimiento que se va a hacer. Usándolos, nos aseguramos de que estén incluidas todas
Nota: no poner en ningún caso “llamar al solicitante”. Pueden consignarse
los datos del solicitante para que el implementador pueda contactarlo y
aclarar dudas sobre la tarea, pero las acciones específicas que se solicitan
deben estar completa y correctamente explícitas en el ticket.
Pág. 12
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
las tareas (una o más) necesarias para ese tipo de pedido, y de que el mismo no será rechazado
por no estar completo.
Entonces vamos a la solapa de tareas y hacemos esta verificación. Para ello seleccionamos
“Plantilla de Grupo de Tareas” en Tipo de petición (como se muestra en el gráfico de abajo),
presionamos “Relacionar” y se busca entre los grupos que se muestran en la ventana
emergente.
En este caso, se ve que la plantilla (como ejemplo) para “Creación de VIP de F5” tiene 3 tareas.
Si hubiera un grupo apropiado, lo seleccionamos de la lista y presionamos “Relacionar”.
Como no hay un grupo apropiado para la solicitud de “Correr un Query” como la que estamos
confeccionando, no necesitamos definir Tareas, y nos aseguramos de haber cargado TODO el
detalle de lo que se pide en la solapa “Información del Trabajo”, que vimos previamente.
Pág. 13
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
Asignación
Una vez completados los detalles del pedido (incluyendo las tareas si correspondiera) se pasa a
la solapa de Relaciones (para Cambios la solapa de Asignación se completa sola y no es
necesario revisarla).
Relación con otros tickets
Si es necesario relacionar este pedido con uno anterior, por ejemplo porque es un cambio
derivado de una incidencia reportada (y YA CARGADA en la Consola de Gestión de Incidencias)
o porque está vinculado a un cambio anterior mal ejecutado, en esta solapa se especifica con
qué otro ticket se relaciona.
Para ello:
Debe elegirse con qué tipo de ticket se va a relacionar, y al presionar “Buscar” se hace la
búsqueda y finalmente se establece la relación.
Pág. 14
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
En este ejemplo se especifica que el cambio que ingresamos corrige la incidencia especificada.
Luego se ingresa la fecha en la que pedimos el cambio o la tarea. Es importante recordar que
debe cumplir con los tiempos de anticipación establecidos, para permitir que las actividades
de verificación técnica, análisis de impacto, aprobación y planificación se ejecuten
normalmente. Para un cambio Normal (N2) se requieren 240 horas de anticipación (como en el
ejemplo de abajo) al inicio de la tarea, independientemente del tiempo que sea necesario para
ejecutar la misma. Para un cambio N3 se requieren 72 horas de anticipación.
Pág. 15
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
Fechas
Como en todas las demás solapas, sólo son obligatorios los campos marcados con (*).
Datos Requeridos
Finalmente se completa la solapa de Datos Requeridos. En esta solapa debe evitarse en lo
posible completar los distintos campos con “No Aplica” o “NA”. Debe brindarse toda la
información disponible para que el Remedy realmente sirva como una herramienta para hacer
el tracking de los cambios en Producción.
Sistemas Campo de selección, se debe seleccionar el aplicativo de
la lista provista por la herramienta. Dicha lista es la
resultante del vuelco de sistemas definidos en INVAP..
Número Proyecto GUIA Se debe indicar el código del ID de GUIA del Proyecto.
Este campo se deberá cargar siempre y cuando la
implementación esté relacionada con un proyecto.
ID Banco – Nombre de
Proyecto
Campo de selección por nombre de proyecto creado en
PPM
Banca de Negocio Completar con el negocio de banco asociado
Pág. 16
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
Pedido Menor Se debe indicar el código del RI del Pedido Menor. Este
campo se deberá cargar siempre y cuando la
implementación esté relacionada con un Pedido Menor.
# Expediente Changeman En el caso de una implementación Mainframe, y si
correspondiera, se deberá ingresar el aplicativo y nro. de
expediente Changeman que corresponda. Ej CTD3000015
Path Completo En caso de que ser una implementación Midrange y que
sea por contingencia (no se implementa por ClearQuest)
se debe informar la carpeta donde está el paquete a
implementar para que Implementaciones lo tome de allí
para realizar la tarea.
Versión En el caso que corresponda debe indicarse la versión del
aplicativo que se está implementando. En general aplica a
sistemas Midrange.
Canal Afectado Se debe detallar que canales pueden ser afectados por la
implementación. (Ej.: OBP, OBCM, etc)
Identificador Carpeta CQ/CI En caso de que ser una implementación Midrange y que
sea por el circuito normal (es decir utilizando ClearQuest),
se debe informar el ticket de ClearQuest que utilizará
Implementaciones para realizar la tarea. (Ej:.
BSCH0000004567). Este ticket de ClearQuest debe
contar con todas las aprobaciones previstas por el
proceso antes de ingresar el ticket en Remedy.
Es de suma importancia llenar adecuadamente los campos referidos a “Plan de
Implementación”, “Plan de Pruebas” y “Plan de Vuelta atrás”.
En “Plan de Implementación” es necesario especificar las Instrucciones de ejecución o realización
del cambio, pudiendo tratarse de tareas de configuración, análisis, verificación o comunicación (o sea,
los pasos a seguir para ejecutar la tarea).
En “Plan de Pruebas” hay que describir la forma en que el implementador puede confirmar que
su tarea fue realizada correctamente, sin tener que consultar al solicitante del cambio. Se trata
de tareas de control y revisión de resultados esperados del cambio. Se realizan luego del plan
de implementación y permiten determinar si el cambio cumplió sus objetivos (cambio exitoso)
o no (cambio fallido).
Pág. 17
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
En “Plan de Vuelta atrás” se describe qué hacer para volver a la situación original, previa al
cambio (obviamente cuando hubo cambios reales a la infraestructura: puede ponerse ”No
Aplica” en un caso como el del ejemplo en que se pide Información, y por lo tanto NO se han
llevado a cabo cambios de ninguna naturaleza).
Es buena práctica poner datos de contacto en los campos para que el implementador del
cambio pueda contactar en el mismo momento en que lo está ejecutando al solicitante, ante
alguna necesidad de aclaraciones.
Finalmente se presiona “Guardar” para que el sistema dé por ingresado el Borrador de Cambio
y verifique que se hayan ingresado todos los valores obligatorios, con valores que dan
integridad a la solicitud. Una vez hecho esto, se avanza el estado del ticket.
Nota: no poner en ningún caso “llamar al solicitante” en reemplazo de NINGUNO de los 3 planes
requeridos. Si consignan los datos del solicitante es para que el implementador pueda
contactarlo y aclarar dudas sobre la tarea, pero las acciones específicas que se solicitan deben
estar completa y correctamente explícitas en el ticket. Contar con estos datos es especialmente
útil para el implementador durante la ejecución del Plan de Pruebas o el de Vuelta Atrás.
Pág. 18
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
Selección del circuito en Ambientes previos
Aviso Importante – Impacto en Producción
Para ambientes previos la organización continuará utilizando la herramienta de Requerimientos
Internos hasta nuevo aviso.
Hay cambios que aunque sean para ambientes previos, IMPACTAN EN PRODUCCIÓN.
Por lo tanto habrá que gestionar los cambios relacionados con Storage, Balanceadores, Networking y Correo vía tickets de Remedy, siendo el objetivo no exponer la infraestructura productiva a riesgos innecesarios que puedan darse (debido a que hoy en día no se evaluando factibilidad técnica ni riesgos de los cambios que se gestionan a través de RI como se hace con los tickets en Remedy). Debemos tener en claro que más allá del uso que se le puede dar a estos componentes, los mismos son productivos y cualquier cambio sobre ellos implica un riesgo sobre los servicios del Banco.
Criterio
Los criterios de selección de Circuitos en Requerimientos Internos continúan siendo los que habitualmente usamos. Del menú de Producto:
Pág. 19
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
se selecciona la opción “Pedidos / Cambios”. En el de Sub-Producto lo más apropiado al tipo de cambio que se solicita:
Pág. 20
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
Por ejemplo: si estamos pidiendo una nueva instancia de servidor WebSphere: seleccionamos la opción “WEB” y eso nos lleva al combo de Concepto: Allí seleccionamos “Desarrollo” o “Test/Homo” según corresponda. Recordar que NO DEBE usase RI para pedidos de PRODUCCIÓN.
Y en Sub-Concepto seleccionamos “ABM de Instancia”.
Pág. 21
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
Solicitudes al área Administración de Ambientes
Si se requieren servicios del área Administración de Ambientes (siempre referidos a los ambientes de Homologación), NO ENVIAR dichos pedidos por mail, sino a través del siguiente circuito:
Estos pedidos de configuraciones, implementaciones, etcétera, serán atendidos por el grupo de Administración de Ambientes, o de considerarlo más apropiado, lo derivarán al grupo resolutor que corresponda.
Pág. 22
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
PIR (Post Implementation Review) El PIR o Revisión post Implementación es un paso fundamental en el circuito, y que apunta a mejorar la calidad de las implementaciones. Todos los tickets, una vez cumplidos, deben ser evaluados por el solicitante o un miembro de su grupo, especificando si el cambio ha sido implementado con Éxito, si tuvo fallas, si está mal implementado, o si sencillamente quedó sin implementar.
Los tickets que están esperando por una Revisión post Implementación están marcados con un “Si” en la columna PIR precedente. Eso las distingue de una “Autorización normal” previa a la ejecución de un cambio.
Nota: no seleccionar más de un ticket, ya que de este modo sólo se evalúa
el primero, y el resto quedan como implementados sin errores.
Pág. 23
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
Para cada uno de los tickets (que deben seleccionarse de a uno) debe hacerse la evaluación correspondiente. Si en el ejemplo anterior, queremos rechazar el cambio, lo seleccionamos (sólo al que estamos
evaluando), presionamos y cuando vemos el pop-up ponemos las razones:
Si lo vamos a Aprobar, porque entendemos que la tarea se hizo, presionamos y tenemos 2 opciones:
Con éxito: todo fue realizado como se pretendía y el resultado fue el esperado.
Éxito con problemas: sin bien los solicitado fue realizado, el resultado no es exactamente el esperado, quedaron parte de las tareas sin realizar o se cumplieron en forma incompleta.
Pág. 24
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
Si lo aceptamos como exitoso el trámite finaliza aquí. Si decimos que hubo problemas es necesario explicar las razones en el campo al efecto:
La correcta implementación de los cambios es crucial para lograr la mejor disponibilidad en Producción. Es por ello que la etapa de PIR es fundamental: es la única forma que tenemos de evaluar la calidad de las implementaciones, de encontrar errores en el proceso o actividades específicas y buscar las soluciones para mejorar la calidad general. De nada sirve reclamar por mail por implementaciones mal hechas, si en el PIR se evaluó el cambio como “exitoso”.
Pág. 25
Autor: Eduardo Jamilis Gestión de Cambios y Delivery Isban
Preguntas Frecuentes En paralelo con este manual, Produban está publicando en conjunto con IBM un nuevo documento de FAQ (Frequently Asked Questions) que será actualizado periódicamente. Sugerimos desde aquí echarle un vistazo periódicamente ya que las distintas consultas que vayamos recibiendo y entendamos que son de interés para un número grande de usuarios, serán incorporadas al mismo.