h

2013
Produban Argentina
Grupo Santander

Enero

Gestin de Cambios
Ingreso de solicitudes de cambio

Pg. 1

Gestin de Cambios Ingreso de solicitudes de Cambio

ndice

ndice ............................................................................................................................................................. 1
Control de actualizaciones ............................................................................................................................ 2
Introduccin .................................................................................................................................................. 3
Referencias................................................................................................................................................ 7
Ambientes ..................................................................................................................................................... 8
Produccin ................................................................................................................................................ 8
Ambientes previos .................................................................................................................................... 8
Seleccin del circuito en Produccin ............................................................................................................ 8
Planilla de circuitos ................................................................................................................................... 8
Ejemplo de Creacin de un Cambio .......................................................................................................... 9
Datos bsicos y asignacin de nivel de riesgo .................................................................................... 10
Clasificacin y Clase de Cambio .......................................................................................................... 12
Informacin de Trabajo....................................................................................................................... 13
Tareas .................................................................................................................................................. 14
Asignacin ........................................................................................................................................... 18
Relacin con otros tickets ................................................................................................................... 18
Fechas ................................................................................................................................................. 20
Datos Requeridos ................................................................................................................................ 20
PIR (Post Implementation Review) ............................................................................................................ 23
Seleccin del circuito en Ambientes previos .............................................................................................. 26
Aviso Importante Impacto en Produccin ........................................................................................... 26
Criterio .................................................................................................................................................... 26
Solicitudes al rea Administracin de Ambientes .................................................................................. 29
Preguntas Frecuentes ................................................................................................................................. 30

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 2

Control de actualizaciones

Versin

Explicacin del
Redact(s) Revis(s) Aprob(s)
Cambio

1.0

Primera
Liberacin

Eduardo
Jamilis

1.1

Se modifica
circuito RI de
Ambientes y se
agrega ejemplo
de Tarea

Eduardo
Jamilis

Produban Argentina

Fecha
Distribucin

Emilio Siri

Eduardo
Jamilis

Personal
Produban e
Isban
Argentina

Emilio Siri

Eduardo
Jamilis

Personal
Produban e
Isban
Argentina

Aprobacin

Liberacin

08/02/2013

15/02/2013

08/02/2013

15/02/2013

Gestin de Cambios y Delivery Isban

Pg. 3

Introduccin
El proceso de Gestin de Cambios tiene como principal objetivo la evaluacin y planificacin del
proceso de cambio para asegurar que, si ste se lleva a cabo, se haga de la forma ms eficiente,
siguiendo los procedimientos formales establecidos y asegurando en todo momento la calidad
y continuidad del servicio TI.
Esto implica que deben cumplirse los estndares, procesos y procedimientos de
implementacin establecidos. Y es rea de Gestin de Cambios de Produban la encargada de
verificar su cumplimiento, en tiempo y forma.
Es por esto que no puede impactarse en Produccin NINGN cambio sin un pedido de cambio
asociado. No es vlido hacer los cambios pedidos informalmente, y LUEGO ingresar un pedido
para regularizarlo.
Todos los cambios deben ser ingresados al sistema de Gestin (en Remedy) con la anticipacin
mnima requerida, segn el caso. A estos cambios los clasificamos como normales y son
analizados en primera instancia por los especialistas, verificando la factibilidad de su ejecucin
y luego por un CAB (Change Advisory Board o Comit de Cambios) con participacin de todos
los involucrados, Isban, Produban y Banco Santander Ro, que evalan el riesgo y acuerdan la
realizacin del mismo, o lo rechazan fundadamente, ya sea por la naturaleza del cambio o por
la ventana escogida para su realizacin.
Si no se cumple con las formalidades requeridas, el sector Gestin de Cambios al hacer los
controles y verificar la existencia de errores o informacin faltante, cancelar los pedidos, que
debern cargarse nuevamente y obviamente en consecuencia, generar demoras adicionales a
la hora de contar con los cambios solicitados en Produccin. Esto es as porque si bien
transitoriamente Gestin de Cambios est pasando los tickets a borrador, esto crea confusin
respecto a los 10 das de anticipacin que requiere un cambio normal, los que cuentan
indefectiblemente desde la ltima vez que se avanz el cambio desde estado borrador.
Las principales causas que generan la cancelacin de pedidos son:
1.
2.
3.
4.
5.
6.
7.
8.

Datos Requeridos incorrectos o faltantes

Cambios Correctivos sin Incidencia relacionada
Cambios Normales-N2 con menos de 240hs.
Clasificacin Incorrecta (un ticket mal clasificado no tiene el circuito de aprobacin
correcto ni se dirige al grupo de resolucin que corresponde).
Cambios solicitados como N3 sin ID de catlogo
Cambios normales N3 pedidos con menos de 72 horas de antelacin
Nivel de Riesgo errneo
Tareas sin especificacin de grupo asignado a ejecutarla.

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 4

9. Cambios solicitados sin especificar a qu aplicacin impacta (Campo Sistemas en la

pestaa Datos Requeridos)
10. Implementacin solicitada en ventana diferente a la definida en el Calendario de
Cambios

No es admisible el ingreso de un ticket solicitando la implementacin 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 das de anticipacin en el pedido de un cambio normal es necesario para realizar
un adecuado anlisis 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 algn modo implicara 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 razn 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 slo es su necesidad, sino tambin 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 aplicacin de estos cambios.
En estos casos, se debe enviar oportunamente la siguiente informacin con el detalle de los
cambios a tratar en el comit ECAB como se describe a continuacin:
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:

-----------------------------------------------------

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 5
Detalle:
Plan de Implementacin:
Plan de Pruebas:
Plan de Vuelta atrs:
Fecha Inicio:
Fecha Fin:

EJEMPLO PLANILLA CON DATOS

----------------------------------------------------------------------------------------------------------

Nro de CRQ : CRQ000000059576

Solicitante: Miguel Duffy
Participantes del ECAB: Miguel Duffy

Motivo de la Emergencia: Se realiz una revisin 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 produccin.
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 estn afectadas son
RIO57 >El FS comprometido es /RIO57/data14 -->
RIO2 >FS comprometidos > /RIO2/data07 y /RIO2/index04 --> 3hs
Plan de Implementacin: 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 asignacin de LUN, y consultar con storage que estn en
modo PPRC, antes de comenzar la tarea.
Plan de Vuelta atrs: 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

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 6

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 Revisin post Implementacin). Esa evaluacin 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.
Dado que los cambios N2 (Riesgo Bajo) no se analizan en detalle durante el Comit de Cambios
semanal, a menos que sea requerido especficamente por Gestin de Cambios o el Banco,
puede suceder que las instrucciones ingresadas para la tarea no sean totalmente claras o estn
incompletas. Ej: Implementar paquete SRVMDF098, sin especificar en qu servidor.
Si NO SE USA LA CLASIFICACIN correcta, el pedido NO PASA por la evaluacin tcnica.
Si se dan ambas condiciones, podra pasar que Gestin de Cambios no detecte el error y que
cuando el implementador intente llevar a cabo su tarea, encuentre que le faltan datos. Ser el
solicitante quien deber reingresar adecuadamente el pedido para que la tarea se lleve a cabo,
una vez que el pedido original se haya cerrado fallido.
Slo son vlidos los circuitos definidas por las clasificaciones enumeradas como tales en la
planilla de RI vs Remedy http://remedyweb.ar.bsch:9080/arsys/shared/Manuales/2.xls. No es
fundamental conocer los circuitos previos de Requerimientos Internos. Si no se los conoce,
simplemente se ignoran esas columnas de la planilla, y se seleccionan los circuitos vlidos
prestando atencin a las columnas de circuitos Remedy, seleccionando de aquellos circuitos
disponibles, el ms apropiado de acuerdo al tipo de cambio que se solicita.
Ante la duda y como primera medida, lo ptimo es solicitar el asesoramiento de pares y
lderes.

Dependiendo del ambiente del que se trate, los pedidos a la fecha se ingresan por sistemas
diferentes:

Remedy para el Ambiente de Produccin

Requerimientos Internos para los Ambientes Previos

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 7

Referencias
Es importante que quienes lean este instructivo hayan ledo previamente los siguientes
documentos:

Proceso Produban Guia del usuario

La primera referencia debe ser la Gua del Usuario de Cambios que describe en detalle el
proceso, y el uso de la herramienta. Este documento describe todas las actividades y conceptos
que esta herramienta prev: http://remedyweb.ar.bsch:9080/arsys/shared/Manuales/7.pdf.
En http://remedyweb.ar.bsch:9080/arsys/shared/manuales.html van a encontrar toda la
documentacin generada por Produban, incluyendo la planilla de correlacin entre circuitos de
Requerimientos Internos y Remedy, videos explicativos de distintas operatorias, la Gua de
Usuario mencionada ms arriba y el catlogo vigente de Cambios N3.

Instructivo Isban
Tambin constituye una referencia muy til la consulta de este instructivo provisto por la
Gerencia de Metodologa de Isban: http://isbanarg.ar.bsch/sites/ids/MYP/Herramientas/Procesos%20Isban/Proceso%20Gestin%20de%20Cambios%2
0Isban/Instructivo%20Gestion%20de%20Cambios%20Isban.doc

Cdigo:

ARG-SPA-INT-003-MYO

Ttulo:

Instructivo Gestin de Cambios Isban

Objetivo:

Describir en forma detallada las actividades del proceso a realizar por Isban
para solicitar una implementacin o cambios en la infraestructura del
ambiente productivo gestionado por Produban segn su proceso de Gestin
de Cambios corporativo de Produban.

Vigencia inicial:

28 / 09 / 2012

ltima revisin: 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 dichos documentos, vlidos para todo el
personal de Isban Argentina, y que aplican slo a los pedidos para el ambiente de Produccin.
El contenido de este instructivo complementa lo establecido en la documentacin de referencia
precedente.

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 8

Ambientes
Produccin
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, Homologacin, PreProduccin) se ingresan en el sistema de Requerimientos Internos (RI).

Seleccin del circuito en Produccin

Planilla de circuitos
Dentro de la documentacin 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 cul 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 informarn cules son los grupos involucrados (uno o ms).
Si conoca el circuito de Requerimientos Internos puede usarlos como gua (columnas verdes).
Si no, se busca slo entre las columnas de Remedy (celestes).
En consecuencia, lo que debe hacerse es filtrar la planilla por grupo resolutor, y luego elegir el
circuito ms adecuado para el tipo de pedido que estamos haciendo. Ej: si vamos a solicitar la
implementacin de un nuevo job en Control-M DS en servidor Unix, NO PODEMOS cargarlo
como corrida de job en control-M, ms all de que eventualmente el grupo resolutor sea el
mismo.
Concretamente las lneas aludidas seran:

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 9

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.
Si no se ponen los circuitos tal como estn en la planilla, no se asignan automticamente, ya
que Remedy usa reglas predefinidas para la asignacin, NO TENDRN el workflow de
aprobaciones y controles correctos y deber ser rechazado.
Una vez seleccionado el circuito apropiado, se ingresa a la herramienta Remedy siguiendo las
instrucciones de la gua http://remedyweb.ar.bsch:9080/arsys/shared/Manuales/7.pdf del
usuario de cambios y se carga el ticket correspondiente.

Ejemplo de Creacin de un Cambio

Vemos a continuacin un ejemplo referido a una solicitud de Catalogacin de un nuevo Job en
Control-M DS (distribuido) a correr en el servidor Unix SRVxxxx (primer ejemplo mostrado
arriba).

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 10

Para realizar la carga de una solicitud de cambio debe primeramente hacerse clic en la opcin
Crear desde la consola de gestin de cambios, ver ilustracin siguiente:

Datos bsicos y asignacin de nivel de riesgo

Luego de hacer clic en la opcin Crear tal como se muestra en la ilustracin anterior, el
sistema abrir una nueva ventana que contiene los datos a cargar en una solicitud de cambio
tal como muestra a continuacin:

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 11

ARG

Tal como puede verse en la ilustracin, se puede visualizar en la parte superior a la barra que
indica el estado en el flujo del proceso (ver recuadro rojo), y algo ms abajo (ver recuadro
verde) puede identificarse a la lista de datos denominados Datos Bsicos 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.
Se define el nivel de riesgo N3 para cambios que se conoce que son de riesgo bajo. Se ha
definido un catlogo de las tareas que cumplen esta condicin y se aceptan como N3. Cualquier
nuevo cambio que quiera agregarse a este catlogo debe ser solicitado a la Gerencia de
Metodologa (PROCESOS_ISBAN@santanderrio.com.ar) con las razones que justifican el
pedido, quien coordinar el agregado (si se acepta) con el Banco y Produban.
Cambios N3 requieren menos das para su ejecucin (72 hs. entre la fecha de peticin de
autorizacin y la fecha programada de Inicio en lugar de 240 hs. como lo requiere un ticket N2Normal) porque se sabe que son de riesgo acotado y no requieren anlisis 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 da siguiente, previo envo de la planilla con
la informacin adecuada.
Las solapas disponibles cambian segn la fase del ciclo de vida que se est transitando.
Algunas solapas (por ejemplo Aprobadores) no estarn disponibles hasta que se avance a una
fase determinada.

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 12

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 Administracin
ITSM (administracion_itsm@santanderrio.com.ar) para corregir los datos del usuario.

Clasificacin y Clase de Cambio

Luego se ingresan los datos de Clasificacin (que determinan en qu bandeja caern para ser
programados y ejecutados), as como tambin la Clase (Normal o Emergencia) y el Motivo del
cambios: Evolutivo, Correctivo (debe estar relacionado con un ticket de Incidencia ingresado
previamente), Auditora, Normativo (debe tener el identificacin de la norma a la cual hace
referencia) o Ejecutivo (debe que estar acompaado con un mail con las aprobaciones de los
Directores Generales de Isban y Produban y la del CIO del Banco).

Como pueden ver, esta informacin de categorizacin coincide EXACTAMENTE con la que
encontramos en la planilla publicada (columnas en azul), y que repetimos a continuacin:

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 13

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.
Informacin de Trabajo

En esta solapa se debe agregar toda informacin o comunicacin relevante a la solicitud de

cambio. Es posible indicar entre otras cosas informacin adicional relacionada a la
implementacin, comunicacin con el solicitante, resultados de pruebas realizadas, informacin
sobre los riesgos potenciales, datos necesarios para auditoras, etc.

Nota: no poner en ningn 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 especficas que se solicitan
deben estar completa y correctamente explcitas en el ticket.

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 14

Tareas

Si lo que se est pidiendo slo requiere de una tarea, la solapa Tareas podra 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. Usndolos, nos aseguramos de que estn incluidas todas
las tareas (una o ms) 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 verificacin. Para ello seleccionamos
Plantilla de Grupo de Tareas en Tipo de peticin (como se muestra en el grfico 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 Creacin 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 Informacin del Trabajo, que vimos previamente.

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 15

Tambin pueden ingresarse tareas Ad-hoc, independientemente de que hayamos usando una
plantilla de tareas (pero debemos agregar una o ms) o que estemos ingresando un ticket con
varias tareas, y que no cuenta con plantilla. De este modo se ingresan tareas manualmente.
Ejemplo: CRQ para bajar backup en servidor, que tiene como tarea secuencial, copiar ese
backup a un medio de almacenamiento fuera de lnea (cinta o DVD).

Para ello se selecciona Tipo de Peticin Ad Hoc donde antes seleccionamos Plantilla de
Grupo de Tareas y se presiona Relacionar. Aparece el siguiente dilogo:

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 16

Se completa el nombre de la tarea que se est creando y luego en Resumen y Notas detalles de
la solicitud. Revisamos las dems pestaas como hicimos con el resto de la peticin de cambio y
las completamos.
Vemos continuacin la pestaa Clasificacin dentro de un Tarea, que es de llenado opcional:

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 17

A diferencia con la clasificacin a nivel de ticket, en el caso de la tarea especificar la tarea puede
que no asigne al grupo correcto, o que incluso no asigne la tarea a ningn grupo. Es por eso que
la asignacin debe hacerse manualmente.
Por eso es que en la pestaa Asignacin/Fechas no es necesario fijar las fechas de las distintas
tareas: quienes realizan la evaluacin tcnica definen las ventanas dentro de la ventana
definida a nivel superior; pero s es obligatorio asignar la tarea a un grupo. De otro modo la
tarea podra quedar sin asignacin especfica, NADIE tendr la responsabilidad de ejecutarla.

Debemos a continuacin del mismo modo completar la pestaa Relaciones si aplica.

Vemos a continuacin un ejemplo de un ticket creado con 2 tareas y se muestra en la imagen
siguiente que la primera de ellas ya fue completada.

Vemos a continuacin la descripcin de la tarea faltante:

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 18

Asignacin

Una vez completados los detalles del pedido (incluyendo las tareas si correspondiera) se pasa a
la solapa de Relaciones (a nivel de Cambios, a diferencia de lo mencionado para Tareas, la
solapa de Asignacin se completa sola y no es necesario revisarla).

Relacin 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 Gestin 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:

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 19

Debe elegirse con qu tipo de ticket se va a relacionar, y al presionar Buscar se hace la

bsqueda y finalmente se establece la relacin.

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 20

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 anticipacin establecidos, para permitir que las actividades
de verificacin tcnica, anlisis de impacto, aprobacin y planificacin se ejecuten
normalmente. Para un cambio Normal (N2) se requieren 240 horas de anticipacin (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 anticipacin.

Fechas

Como en todas las dems solapas, slo 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
informacin disponible para que el Remedy realmente sirva como una herramienta para hacer
el tracking de los cambios en Produccin.

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 21

Sistemas

Campo de seleccin, se debe seleccionar el aplicativo de

la lista provista por la herramienta. Dicha lista es la
resultante del vuelco de sistemas definidos en INVAP..

Nmero Proyecto GUIA

Se debe indicar el cdigo del ID de GUIA del Proyecto.

Este campo se deber cargar siempre y cuando la
implementacin est relacionada con un proyecto.

ID Banco Nombre de
Proyecto

Campo de seleccin por nombre de proyecto creado en

PPM

Banca de Negocio

Completar con el negocio de banco asociado

Pedido Menor

Se debe indicar el cdigo del RI del Pedido Menor. Este

campo se deber cargar siempre y cuando la
implementacin est relacionada con un Pedido Menor.

# Expediente Changeman

En el caso de una implementacin 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 implementacin 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.

Versin

En el caso que corresponda debe indicarse la versin del

aplicativo que se est implementando. En general aplica a
sistemas Midrange.

Canal Afectado

Se debe detallar que canales pueden ser afectados por la

implementacin. (Ej.: OBP, OBCM, etc)

Identificador Carpeta CQ/CI

En caso de que ser una implementacin 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.

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 22

Es de suma importancia llenar adecuadamente los campos referidos a Plan de

Implementacin, Plan de Pruebas y Plan de Vuelta atrs.
En Plan de Implementacin es necesario especificar las Instrucciones de ejecucin o realizacin
del cambio, pudiendo tratarse de tareas de configuracin, anlisis, verificacin o comunicacin (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 revisin de resultados esperados del cambio. Se realizan luego del plan
de implementacin y permiten determinar si el cambio cumpli sus objetivos (cambio exitoso)
o no (cambio fallido).
En Plan de Vuelta Atrs se describe qu hacer para volver a la situacin original, previa al
cambio (en general no DEBE ponerse No Aplica, pero si hubiera una razn por la que
realmente no hay posibilidad o necesidad de aplicar un Plan de Vuelta Atrs, debe justificarse
adecuadamente). No se aceptarn planes con un no aplica que no estn justificados.

Es buena prctica 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.
Nota: no poner en ningn 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 especficas que se solicitan deben
estar completa y correctamente explcitas en el ticket. Contar con estos datos es especialmente
til para el implementador durante la ejecucin del Plan de Pruebas o el de Vuelta Atrs.

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 23

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. Sin este paso no se
pasa a las etapas de aprobacin, programacin e implantacin del cambio.

PIR (Post Implementation Review)

El PIR o Revisin post Implementacin 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.

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 24

Los tickets que estn esperando por una Revisin post Implementacin estn marcados con un
Si en la columna PIR precedente. Eso las distingue de una Autorizacin normal previa a la
ejecucin de un cambio.
Nota: no seleccionar ms de un ticket, ya que de este modo slo se evala
el primero, y el resto quedan como implementados sin errores.

Para cada uno de los tickets (que deben seleccionarse de a uno) debe hacerse la evaluacin
correspondiente.
Si en el ejemplo anterior, queremos rechazar el cambio, lo seleccionamos (slo al que estamos
evaluando), presionamos

y cuando vemos el pop-up ponemos las razones:

Al rechazar un cambio en fase PIR, NO se da conformidad al resultado del cambio. Debe

justificarse los motivos e incluso puede ser necesario la ejecucin de la marcha atrs, previa
validacin con el Grupo de Gestin de Cambios.
Si lo vamos a Aprobar, porque entendemos que la tarea se hizo, presionamos
tenemos 2 opciones:

Con xito: todo fue realizado como se pretenda 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. se cumplieron en
forma incompleta, o se generaron incidencias relacionadas que NO implican la ejecucin
de la vuelta atrs.

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 25

Si lo aceptamos como exitoso el trmite finaliza aqu. Si decimos que hubo problemas es
necesario explicar las razones en el campo al efecto:

La correcta implementacin de los cambios es crucial para lograr la mejor disponibilidad en

Produccin. 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
especficas 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.

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 26

Seleccin del circuito en Ambientes previos

Aviso Importante Impacto en Produccin
Para ambientes previos la organizacin continuar utilizando la herramienta de Requerimientos
Internos hasta nuevo aviso.
Hay cambios que aunque sean para ambientes previos, IMPACTAN EN PRODUCCIN.
Por lo tanto habr que gestionar los cambios relacionados con Storage, Balanceadores,
Networking y Correo va tickets de Remedy, siendo el objetivo no exponer la infraestructura
productiva a riesgos innecesarios que puedan darse (debido a que hoy en da no se evaluando
factibilidad tcnica ni riesgos de los cambios que se gestionan a travs de RI como se hace con
los tickets en Remedy). Debemos tener en claro que ms 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 seleccin de Circuitos en Requerimientos Internos continan siendo los que
habitualmente usamos. En el men de Producto:

se selecciona la opcin Pedidos / Cambios.

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 27

En el de Sub-Producto lo ms apropiado al tipo de cambio que se solicita:

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 28

Por ejemplo: si estamos pidiendo una nueva instancia de servidor WebSphere: seleccionamos la
opcin WEB y eso nos lleva al combo de Concepto:
All seleccionamos Desarrollo o Test/Homo segn corresponda. Recordar que NO DEBE
usase RI para pedidos de PRODUCCIN.

Y en Sub-Concepto seleccionamos ABM de Instancia.

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 29

Solicitudes al rea Administracin de Ambientes

Si se requieren servicios del rea Administracin de Ambientes (siempre referidos a los
ambientes de Homologacin), NO ENVIAR dichos pedidos por mail, sino a travs del siguiente
circuito:

Estos pedidos de configuraciones, implementaciones, etctera, sern atendidos por el grupo de

Administracin de Ambientes, o de considerarlo ms apropiado, lo derivarn al grupo resolutor
que corresponda.

Produban Argentina

Gestin de Cambios y Delivery Isban

Pg. 30

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 peridicamente.
Sugerimos desde aqu echarle un vistazo peridicamente ya que las distintas consultas que
vayamos recibiendo y entendamos que son de inters para un nmero grande de usuarios,
sern incorporadas al mismo.

Produban Argentina

Gestin de Cambios y Delivery Isban