Instructivo - Tickets de Cambio - V1.1

h

2013

Produban Argentina Grupo Santander

Enero

Gestión de Cambios Ingreso de solicitudes de cambio

Pág. 1

Produban Argentina Gestión de Cambios y Delivery Isban

Gestión de Cambios – Ingreso de solicitudes de Cambio

Índice

Índice ............................................................................................................................................................. 1

Control de actualizaciones ............................................................................................................................ 2

Introducción .................................................................................................................................................. 3

Referencias ................................................................................................................................................ 7

Ambientes ..................................................................................................................................................... 8

Producción ................................................................................................................................................ 8

Ambientes previos .................................................................................................................................... 8

Selección del circuito en Producción ............................................................................................................ 8

Planilla de circuitos ................................................................................................................................... 8

Ejemplo de Creación de un Cambio .......................................................................................................... 9

Datos básicos y asignación de nivel de riesgo .................................................................................... 10

Clasificación y Clase de Cambio .......................................................................................................... 12

Información de Trabajo ....................................................................................................................... 13

Tareas .................................................................................................................................................. 14

Asignación ........................................................................................................................................... 18

Relación con otros tickets ................................................................................................................... 18

Fechas ................................................................................................................................................. 20

Datos Requeridos ................................................................................................................................ 20

PIR (Post Implementation Review) ............................................................................................................ 23

Selección del circuito en Ambientes previos .............................................................................................. 26

Aviso Importante – Impacto en Producción ........................................................................................... 26

Criterio .................................................................................................................................................... 26

Solicitudes al área Administración de Ambientes .................................................................................. 29

Preguntas Frecuentes ................................................................................................................................. 30

Pág. 2


Control de actualizaciones

Versión Explicación del

Cambio Redactó(s) Revisó(s) Aprobó(s) Distribución

Fecha

Aprobación Liberación

1.0 Primera

Liberación

Eduardo

Jamilis Emilio Siri

Eduardo

Jamilis

Personal

Produban e

Isban

Argentina

08/02/2013 15/02/2013

1.1

Se modifica

circuito RI de

Ambientes y se

agrega ejemplo

de Tarea

Eduardo

Jamilis Emilio Siri

Eduardo

Jamilis

Personal

Produban e

Isban

Argentina

08/02/2013 15/02/2013

Pág. 3


Introducción

El proceso de Gestión de Cambios 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.

Si no se cumple con las formalidades requeridas, el sector Gestión de Cambios al hacer los controles y verificar la existencia de errores o información faltante, cancelará los pedidos, que deberán cargarse nuevamente y obviamente en consecuencia, generará demoras adicionales a la hora de contar con los cambios solicitados en Producción. Esto es así porque si bien transitoriamente Gestión de Cambios está pasando los tickets a borrador, esto crea confusión respecto a los 10 días de anticipación 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 cancelación de pedidos son:

1. Datos Requeridos incorrectos o faltantes

2. Cambios Correctivos sin Incidencia relacionada

3. Cambios Normales-N2 con menos de 240hs.

4. Clasificación Incorrecta (un ticket mal clasificado no tiene el circuito de aprobación

correcto ni se dirige al grupo de resolución que corresponde).

5. Cambios solicitados como N3 sin ID de catálogo

6. Cambios normales N3 pedidos con menos de 72 horas de antelación

7. Nivel de Riesgo erróneo

8. Tareas sin especificación de grupo asignado a ejecutarla.

Pág. 4


9. Cambios solicitados sin especificar a qué aplicación impacta (Campo “Sistemas” en la

pestaña ”Datos Requeridos”)

10. Implementación solicitada en ventana diferente a la definida en el Calendario de

Cambios

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:

1. Enviar antes de la hora del comité 11hs, de lunes a viernes 2. mail: [email protected] (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:

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

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

mailto:[email protected]

Pág. 5


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

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

Pág. 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 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.

Dado que los cambios N2 (Riesgo Bajo) no se analizan en detalle durante el Comité de Cambios semanal, a menos que sea requerido específicamente por Gestión de Cambios o el Banco, puede suceder que las instrucciones ingresadas para la tarea no sean totalmente claras o estén incompletas. Ej: Implementar paquete SRVMDF098, sin especificar en qué servidor.

Si NO SE USA LA CLASIFICACIÓN correcta, el pedido NO PASA por la evaluación técnica.

Si se dan ambas condiciones, podría pasar que Gestión 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.

Sólo son válidos 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 válidos prestando atención a las columnas de circuitos Remedy, seleccionando de aquellos circuitos disponibles, el más 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 líderes.

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

Remedy para el Ambiente de Producción

Requerimientos Internos para los Ambientes Previos

http://remedyweb.ar.bsch:9080/arsys/shared/Manuales/2.xls

Pág. 7


Referencias

Es importante que quienes lean este instructivo hayan leído previamente los siguientes documentos:

Proceso Produban – Guia del usuario

La primera referencia debe ser la Guía 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 documentación generada por Produban, incluyendo la planilla de correlación entre circuitos de Requerimientos Internos y Remedy, videos explicativos de distintas operatorias, la Guía de Usuario mencionada más arriba y el catálogo vigente de Cambios N3.

Instructivo Isban

También constituye una referencia muy útil la consulta de este instructivo provisto por la Gerencia de Metodología de Isban: http://isban-

arg.ar.bsch/sites/ids/MYP/Herramientas/Procesos%20Isban/Proceso%20Gestión%20de%20Cambios%20Isban/Instructivo%20Gestion%20de%20Cambios%20Isban.doc

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: [email protected]

Es importante tener claros los conceptos expuestos en dichos documentos, válidos para todo el personal de Isban Argentina, y que aplican sólo a los pedidos para el ambiente de Producción. El contenido de este instructivo complementa lo establecido en la documentación de referencia precedente.

http://remedyweb.ar.bsch:9080/arsys/shared/Manuales/7.pdf

http://remedyweb.ar.bsch:9080/arsys/shared/manuales.html

http://isban-arg.ar.bsch/sites/ids/MYP/Herramientas/Procesos%20Isban/Proceso%20Gestión%20de%20Cambios%20Isban/Instructivo%20Gestion%20de%20Cambios%20Isban.doc




Pág. 8


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 ([email protected]), quienes informarán cuáles son los grupos involucrados (uno o más).

Si conocía el circuito de Requerimientos Internos puede usarlos como guía (columnas verdes). Si no, se busca sólo entre las columnas de Remedy (celestes).

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 las líneas aludidas serían:

http://remedyweb.ar.bsch:9080/arsys/shared/Manuales/2.xls


Pág. 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 están en la planilla, no se asignan automáticamente, ya que Remedy usa reglas predefinidas para la asignación, NO TENDRÁN 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 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).

http://remedyweb.ar.bsch:9080/arsys/shared/Manuales/7.pdf

Pág. 10


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


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.

Se define el nivel de riesgo N3 para cambios que se conoce que son de riesgo bajo. Se ha definido un catálogo de las tareas que cumplen esta condición y se aceptan como N3. Cualquier nuevo cambio que quiera agregarse a este catálogo debe ser solicitado a la Gerencia de Metodología ([email protected]) con las razones que justifican el pedido, quien coordinará el agregado (si se acepta) con el Banco y Produban.

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.

ARG


Pág. 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 Administración ITSM ([email protected]) para corregir los datos del usuario.

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:


Pág. 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.

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.

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


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


También pueden ingresarse tareas Ad-hoc, independientemente de que hayamos usando una plantilla de tareas (pero debemos agregar una o más) 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 línea (cinta o DVD).

Para ello se selecciona Tipo de Petición “Ad Hoc” donde antes seleccionamos “Plantilla de Grupo de Tareas” y se presiona Relacionar. Aparece el siguiente diálogo:

Pág. 16


Se completa el nombre de la tarea que se está creando y luego en Resumen y Notas detalles de

la solicitud. Revisamos las demás pestañas como hicimos con el resto de la petición de cambio y

las completamos.

Vemos continuación la pestaña Clasificación dentro de un Tarea, que es de llenado opcional:

Pág. 17


A diferencia con la clasificación 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 ningún grupo. Es por eso que la asignación debe hacerse manualmente.

Por eso es que en la pestaña “Asignación/Fechas“ no es necesario fijar las fechas de las distintas tareas: quienes realizan la evaluación técnica 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 podría quedar sin asignación específica, NADIE tendrá la responsabilidad de ejecutarla.

Debemos a continuación del mismo modo completar la pestaña “Relaciones” si aplica.

Vemos a continuación 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 continuación la descripción de la tarea faltante:

Pág. 18


Asignación

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

Pág. 19


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

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.

Pág. 21


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

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.

Pág. 22


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

En “Plan de Vuelta Atrás” se describe qué hacer para volver a la situación original, previa al cambio (en general no DEBE ponerse ”No Aplica”, pero si hubiera una razón por la que realmente no hay posibilidad o necesidad de aplicar un Plan de Vuelta Atrás, debe justificarse adecuadamente). No se aceptarán planes con un “no aplica” que no estén justificados.

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.

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. 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 aprobación, programación e implantación del cambio.

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.

Pág. 24


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

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 ejecución de la marcha atrás, previa validación con el Grupo de Gestión de Cambios.

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. se cumplieron en forma incompleta, o se generaron incidencias relacionadas que NO implican la ejecución de la vuelta atrás.

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


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


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. En el menú de Producto:

se selecciona la opción “Pedidos / Cambios”.

Pág. 27


En el de Sub-Producto lo más apropiado al tipo de cambio que se solicita:

Pág. 28


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


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

Documents

Instructivo - Tickets de Cambio - V1.1