Instructivo - Service.now - Mantenimiento Aplicaciones Upstream

Clasificación YPF: No Confidencial
Gerencia Aplicaciones
Sistemas de Información
Tecnología e Innovación
VP Servicios
Service NOW
Instructivo Básico
Mantenimiento Aplicaciones Upstrem
Atención de Incidentes y Solicitudes
Autor: Juan Cristóbal García (RY10745)
Procesos y Sistemas Instructivo.Service.Now.Mantenimiento- Pág. 1 de 68

Aplicaciones-Upstream.2020-05 - Borrador-
jcgg - v2.docx

VP Servicios
Contenido
1. PRÓLOGO ................................................................................................................................. 4
2. INTRODUCIÓN .......................................................................................................................... 4
3. INCIDENTES ............................................................................................................................. 4
3.1. FLUJOS DE CARGA DE INCIDENTES........................................................................................................ 4
3.1.1 CARGA DE INCIDENTE DESDE PORTAL DE SERVICIO ...................................................................... 5
3.1.2 CARGA DE INCIDENTE DESDE PORTAL DE RESOLUTOR ................................................................. 8
3.2. FLUJO BÁSICO DE ATENCIÓN DE INCIDENTES. ..................................................................................... 9
3.3. FLUJO INCIDENTE CON CAMBIO CORRECTIVO .................................................................................... 15
3.3.1 PREPARACIÓN DE AMBIENTE DE TESTING .................................................................................... 15
3.3.2 UAT Y CAMBIOS A PRODUCCIÓN...................................................................................................... 17
3.4. FLUJO INCIDENTE CON SOLICITUD A INFRAESTRUCTURA ................................................................ 30
3.5. CARGA DE HORAS INCURRIDAS ............................................................................................................ 33
4. SOLICITUDES ......................................................................................................................... 35
4.1. FLUJO DE CARGA DE SOLICITUD POR PORTAL DE SERVICIO ............................................................. 35
4.1.1 FLUJO DE CARGA POR CATÁLOGO .................................................................................................. 35
4.1.2 FLUJO DE CARGA POR INGRESO DE PEDIDO DE ASISTENCIA (MESA CAU)................................. 38
4.2. FLUJO DE ATENCIÓN DE SOLICITUD VÁLIDA ....................................................................................... 44
4.3. FLUJO DE SOLICITUD CON SOLICITUD A INFRAESTRUCTURA ........................................................... 61
5. CARGA HORAS PARA TAREAS INTERNAS .............................................................................. 65
6. DIAGRAMAS ........................................................................................................................... 67
6.1. DIAGRAMA DE PROCESOS PARA SOLICITUDES ................................................................................... 67
6.2. ESQUEMÁTICO DE INTERRELACIÓN DE PROCESOS. ........................................................................... 68

jcgg - v2.docx

VP Servicios
Control de Versiones
Versión Responsable Fecha Descripción del cambio
1 Juan C. García 5/5/2021 Creación de documento

jcgg - v2.docx

VP Servicios
1. Prólogo
Hoy somos auditados en los siguientes puntos relacionados con la Gestión de Cambios a las
aplicaciones. Se debe tener especial cuidado de dejar las evidencias detalladas en Service Now al estar
llevándose adelante un cambio (mejora o correctivo). De no identificar cómo dejar estas evidencias
registradas en Service Now, consulte a su superior.
Aprobación de nuevos desarrollos o cambios (incluye correctivos)
Las solicitudes de cambios en los sistemas aplicativos son registradas por el usuario clave en Service Now y
aprobadas en la misma herramienta por el delegado/propietario según el tipo de cambio. Como mínimo en
Service Now tienen que quedar reflejados:
• Solicitud del cambio
• Evidencia de la fecha de solicitud
• Evidencia de las autorizaciones correspondientes (delegado/propietario)
• Información detallada del cambio:
o Detalle del objetivo del cambio
o Alcance
o Sistemas impactados
o Beneficios tangibles e intangibles (en caso de mejoras)
o Usuarios afectados
Testing funcional de cambios por parte del usuario
Los cambios en las aplicaciones deben ser testeados por las áreas usuarias de manera previa al pasaje a
producción en un entorno diferente al productivo y se debe conservar evidencia de que la prueba realizada
en Service Now. Como mínimo en Service Now tienen que quedar reflejados:
• Documentación sobre la ejecución de las pruebas realizadas por el usuario (capturas de pantalla)
• Fecha de la realización de las pruebas (previa a la puesta en producción)
• Evidencia del entorno en el que se realizaron
Aprobación del pasaje a producción
Todos los cambios son autorizados por delegado/propietario, luego son derivados automáticamente a los
implementadores para el pasaje a producción a través de Service Now. Como mínimo en Service Now tienen
que quedar reflejados:
• Autorización del paso a producción por parte del delegado/propietario y su fecha
• Evidencia de la implementación en producción en forma posterior a la autorización
2. Introdución
El siguiente instructivo muestra los flujos principales de registración y atención de Incidentes en
Service Now para los equipos de Soluciones NO-SAP.
Service NOW es la herramienta que Sistemas YPF utiliza para reemplazar E2E, HPSM y algunas
otras herramientas que gestionan la demanda de los usuarios de YPF.
El proyecto de Implementación de Service NOW en YPF se denomina SIMON, en la documentación
presentada por el proyecto se denomina SIMON al conjunto de Herramientas ( Portal de Servicios y Portal
del Resolutor )
Este documento está en construcción y adaptación permanente.
3. Incidentes
3.1. Flujos de Carga de Incidentes
• Los incidentes pueden ser cargados por los usuarios directamente desde el Portal de
Servicios (https://ypf.service-now.com/sp)
• Asimismo, los usuarios pueden informar los incidentes por email o por vía telefónica, los
Analistas pueden cargar el Incidente en SN a nombre del usuario en el Portal del Resolutor
o también desde el Portal de Servicios.

jcgg - v2.docx

VP Servicios
Los incidentes o incidencias se utilizan tanto para informar situaciones que generar problemas en el uso de
las aplicaciones como para hacer consultas o solicitar soportes que pueden ser resueltos en menos de 16hs
hábiles.
Describimos algunos de esos flujos a continuación:
3.1.1 Carga de Incidente desde Portal de Servicio
El usuario debería ingresar por Crear Incidente
Los campos obligatorios están marcados con *

jcgg - v2.docx

VP Servicios
Se puede seleccionar un usuario diferente para cargar el incidente, este es el usuario que va a
recibir las comunicaciones sobre el avance del incidente y el que va a aprobar el cierre y va a
responder la encuesta.
Se debe seleccionar una mesa, en el caso de Soluciones No-SAP se debe seleccionar “Soporte de
Aplicaciones”
Se ingresa la aplicación, los nombres de las aplicaciones se muestran con el nombre de la

instancia dentro del mapa de sistemas, para Proceso, en generar el Upstream pero para
aplicaciones multicriterio se puede elegir el negocio o área, Sociedad y Entorno -> No Aplica.
Las búsquedas se pueden realizar por ejemplo con un *delante de una palabra de búsqueda.

jcgg - v2.docx

VP Servicios
Se ingresa el resto de la información para describir el incidente.
Por último presionar:

jcgg - v2.docx

VP Servicios
3.1.2 Carga de Incidente desde Portal de Resolutor
Ingresar al Portal de Resolutor o Consola de Service Now y en el Filtro escribir “Incidencia”
Ingresar a Crear Nuevo y completar todos los datos marcados con

jcgg - v2.docx

VP Servicios
3.2. Flujo Básico de Atención de Incidentes.

En la Barra de accesos de la izquierda se encuentra la
sección Centro de Atención al Usuario, ahí se encontrarán
los principales accesos para atender Incidentes y
Solicitudes.
El ícono al lado de cada acceso nos permite ir creando

un conjunto de accesos favoritos.
Incidencias Muestra todas las incidencias activas de la

compañía, es útil para buscar los incidentes de otros grupos
o que queramos tomar para asignárnoslos.
Mi Trabajo va a mostrar todos los ítems de trabajo

asignados a mi usuario y que estén en estado pendiente.
Trabajo de mis grupos, muestra los ítems asignados a los

grupos a los cuales pertenezco
Items de trabajo pueden ser:

• Incientes (e.g. INC0013289 )
• Solicitudes (e.g. RITM0038228)
• Tareas de Incidentes (e.g. TASK1068647)
• Tareas de Catálogo (e.g. SCTASK0045704)
Y algunos tipos de ítem mas pero estos son los mas

importantes para enfocarnos.
Entramos en Incidencias y completamos los datos obligatorios, los incidentes cargados desde el Portal de
Servicio tendrán mas campos para completar, si lo cargamos nosotros desde el Portal de Resolutor, ya
los tendrá completos.
Es importante completar lo mas precisamente los campos Categoría y Subcategoría. En el caso de los
Soporte / Consulta que nos lleguen como un incidente, debemos seleccionar la sub-categoría
“Duda/Consulta” debido a que no representa una parada de servicio y puede ser atendido sin aplicar
correctivos en Producción.

jcgg - v2.docx

VP Servicios
Es importante seleccionar correctamente la urgencia y la prioridad, estos parámetros determinarán si el

incidente es normal o un Incidente Mayor. Los valores de Urgencia y Prioridad deben provenir de la
comunicación con el usuario y ante cualquier duda, se consulta con el responsable del Equipo de
Mantenimiento.
Todo incidente debe tener cargada una tarea para registrar las horas invertidas en la resolución
Para ello al final de la pantalla del Incidente abrimos la solapa “Tareas de incidentes” y seleccionamos
“Nuevo”
La tarea debe tener una descripción de la actividad que se ejecuta. Los campos obligatorios son:

jcgg - v2.docx

VP Servicios
• Elemento de Configuración: En general es el mismo Elemento de Configuración del Incidente.

• Grupo de Asignación: El Grupo al que pertenecemos.
• Asignado a: Cada Analista.
• Breve Descripción: Descripción de la tarea.
• Horas Incurridas, mientras la tarea está abierta, se puede ir actualizando la cantidad de horas
utilizadas.
• Fecha Objetivo: Es la fecha en la cual se van a contabilizar las horas incurridas, si esta fecha no se
carga, se toma la fecha de cierre. Esta fecha se utiliza para calendarizar las horas.
Una vez terminada la tarea se debe cambiar el estado a Cerrado Completo

jcgg - v2.docx

VP Servicios
Para cerrar el incidente una vez que haya quedado resuelto, presionamos en el Inciente “Resolver
Incidencia”, eso nos cambia el estado del incidente a Resuelto y nos resalta los campos a completar
obligatorios

jcgg - v2.docx

VP Servicios
Es importante ser precisos en el Código de Resolución y en las Notas de Resolución para poder reutilizar
conocimiento a posteriori, también hay que ser lo suficientemente claros con la nota que queda “VISIBLE
PARA EL CLIENTE”.

jcgg - v2.docx

VP Servicios
Una vez que se cierra el incidente, el usuario recibirá un correo solicitando la confirmación del cierre del
incidente.
Al acceder al link, se genera un mail que el usuario debe completar con datos si lo considerara necesario
y lo envía. En el caso que el usuario confirma, el Incidente queda en estado Cerrado, si no confirma, el
Incidente vuelve a quedar en estado Asignado.

jcgg - v2.docx

VP Servicios
3.3. Flujo Incidente con Cambio Correctivo

3.3.1 Preparación de ambiente de Testing
En el caso que sea necesaria la preparación del ambiente de Testing para que los usuarios puedan
ejecutar la UAT, se podrán generar desde el mismo incidente todas las Solicitudes de Cambio necesarias
para el equipo de Implemntación y Despliegues. Si la adecuación la podemo realizar nosotros sobre los
ambientes de Testing, no será necesario este paso.
Los cambios para ambiente de Testing se deben solicitar directamente desde el Incidente en la solapa de
Solicitud de cambio
Elegimos tipo de Cambio Estándar
Elegimos Soluciones
Elegimos YPF_IMPLEMENTACION_Y_DESPLIEGUES_CENTRAL_FF

jcgg - v2.docx

VP Servicios
Elegimos GDA – Paso Testing
En el Cambio tenemos que completar el CI de la instancia de Testing de la aplicación:
En la Breve Descripción indicamos el Changeset/Release que incluye el código, script, archivo o cualquier
artefacto que debe impactar en Testing

jcgg - v2.docx

VP Servicios
Completamos las fechas para cuando necesitamos el cambio implementado ( no es compromiso para
implementación y despliegues pero sirve para indicarles nuestra expectativa.
Finalmente Enviar. Esto genera el cambio y ya nos debería aparecer en la solapa de Solicitudes de Cambio
del incientes.
Es conveniente enviar un correo a DSIIMPLEMENTACIONYDESPLIEGUES@ypf.com indicando el número

del cambio.
Por último pasamos el incidente a estado “En Espera” y como causa indicamos “En Espera por Cambio”.
3.3.2 UAT y Cambios a Producción
En el caso que sea necesario solicitar un Cambio al equipo de Implementación y Despliegues

(ejecución de scripts en BBDD , aplicación de fixes en Aplicaciones Web, etc.) es necesario generar desde el
Incidente una Solicitud de Implementación, dentro de la Solicitud se solicita el Cambio.
Desde la Incidencia seleccionamos Crear Solicitud.

jcgg - v2.docx

VP Servicios
Seleccionar Catálogo Técnico
Acceder a Ver todos los Elementos

jcgg - v2.docx

VP Servicios
Seleccionar “Solicitud de Implementación – Aplicaciones específicas.

jcgg - v2.docx

VP Servicios
La Solicitud Implementación estructura el proceso para la ejecución de la UAT de parte del usuario y la
generación y verificación del Cambio que finalmente le llegará al equipo de Implementación y Despliegue.
Este tipo de Solicitud no requiere aprobación inicial del Propietario/Delegado de la aplicación, solo debe
aprobar el Paso a Producción. La Solicitud de Implementación es ejecutada íntegramente dentro del
Equipo de Mantenimiento, solo el Cambio Generado lo ejecuta Implementación y Despliegues.
Se debe especificar adicionalmente Aplicación/Proceso/Sociedad/Entorno indicando “No aplica” donde

corresponda.
Adjuntar un archivo Excel con la casos de prueba propuestos, también se pueden incluir los casos de
prueba ya ejecutados en el EMA para que le sirvan como guía a los usuarios.

jcgg - v2.docx

VP Servicios
Formulario.UAT.Apli
caciones.xlsx
Ejemplo de archivo de casos propuestos:
Después de presionar se genera la Solicitud de Implementación, hay que

acceder a la misma
En este momento es importante poner el incidente en el estado “En Espera”, el incidente tiene que estar
previamente en estado “En Curso”. El Motivo de poner en espera debería ser Esperando cambio.
El usuario recibirá un correo con un link para aprobar la UAT desde el Portal de Servicio, debe adjuntar el
archivo Excel con capturas de pantalla como evidencias y debe confirmar que ha realizado las pruebas.

jcgg - v2.docx

VP Servicios
De esta manera quedan aprobadas las pruebas de Usuario
En este punto, la Solicitud debe ser aprobada por el Propietario/Delegado.
Una vez aprobada por el Propietario/Delegado, la solicitud queda en Etapa de Pasaje a Producción

jcgg - v2.docx

VP Servicios

jcgg - v2.docx

VP Servicios
Se genera automáticamente la tarea para la creación del cambio para implementación:
Completar los datos y guardar la tarea.

jcgg - v2.docx

VP Servicios
La Creación del Cambio Correctivo se debe realizar desde el RITM, no desde la tarea, esto nos permite
iterar con diferentes cambios. Está acordado con Implementación y Despliegues.
Se debe cargar una nueva Solicitud de Cambios
Elegir Cambio estándar para Soluciones

jcgg - v2.docx

VP Servicios
Seleccionar YPF_IMPLEMENTACION_Y_DESPLIEGUES_CENTRAL_FF
Seleccionar GDA-Paso Producción

jcgg - v2.docx

VP Servicios
Completar los datos específicos para la creación del Cambio a Implementación y Despliegues,
fundamentalmente el Elemento de Configuración y la planificación solicitada
Al darle Enviar se genera el cambio para Implementación y Despliegue:
Una vez que Implementación y Despliegues cierra el Cambio, se debe verificar que se ejecutó el cambio
correctamente, hay que cerrar la tarea de la Solicitud de Implementación, automáticamente se crea la
tarea de Cierre de la Solicitud.
Una vez que se cierra la tarea de verificación y cierre, se cierra automáticamente la Solicitud de
Implementación

jcgg - v2.docx

VP Servicios

jcgg - v2.docx

VP Servicios
En el Incidente Original queda registrada la Solicitud de Implementación y quedan asociadas todas las
evidencias de la Puesta en producción.
Antes de resolver el Incidente recordar generar una tarea para registrar las horas incurridas en la gestión
de la Solicitud de Implementación. Para que queden registrados a nivel del incidente.

jcgg - v2.docx

VP Servicios
3.4. Flujo Incidente con Solicitud a Infraestructura

Este Flujo está bajo revisión
En el caso que necesitamos alguna intervención de alguno de los equipos de infraestructura para
resolver un incidente, se deberá instanciar una Solicitud Catalogada desde el Catálogo Técnico.
Si la intervención que necesitamos del grupo de Infraestructura no está catalogada, debemos contactar
mediante correo o chat o llamada al equipo para que indique el mecanismo que esperan para recibir
nuestro requerimiento.
Una vez recibido el incidente y se determina que es necesaria la intervención de un equipo de

Infraestructura, generar una tarea que refleje la generación de la solicitud.
Desde el Incidente, crear la Solicitud

jcgg - v2.docx

VP Servicios
Cargar los datos necesarios:

jcgg - v2.docx

VP Servicios

jcgg - v2.docx

VP Servicios
La solicitud se crea y se asigna al grupo asociado al CI seleccionado:
Una vez que el equipo de Infraestructura cierra la solicitud, podemos verificar y cerrar el incidente.
3.5. Carga de Horas Incurridas

Todos los incidentes atendidos dentro de lo Equipos de Mantenimiento de Aplicaciones Upstream deben
tener declaradas las horas incurridas, para lo cual deben tener asociada al menos una tarea que refleje las
horas utilizadas para resolver el problema.

jcgg - v2.docx

VP Servicios
Una vez cerrada la tarea no hay forma de corregir errores, con lo que hay que verificar la
información antes de cerrar la tarea, si hay alguna tarea con errores en el cierre se debe informar al
responsable del Equipo de Mantenimiento de Aplicaciones.

jcgg - v2.docx

VP Servicios
4. Solicitudes
Los Evolutivos, Asesorías y Capacitaciones se deben requerir a los Equipos de Mantenimiento de
Aplicaciones (EMA), mediante una Solicitud.
Ver el Diagrama de proceso de Solicitudes para ver las diferencias.
Tal como ocurre hasta ahora con este tipo de demanda, las Solicitudes pueden requerir una
aprobación del Propietario/Delegado de la aplicación, también pasan por un proceso de Priorización y por
parte del equipo de BRM ( Business Relationship Management o Relación con le Negocio, RN) y recién en
ese punto es asignado al EMA.
También las Solicitudes se utilizan para formalizar intervenciones de las Áreas de Infraestructura TI
y para estructurar la forma en que solicitamos Cambios al equipo de Implementación y Despliegue.
Por último, pueden llegarnos Solicitudes derivadas desde la Mesa de Ayuda cuando un usuario
Solicita Asistencia al CAU pero referido a Aplicaciones nuestras, el CAU nos puede derivar ese tipo de
Solicitudes.
Cuando se crea una Solicitud se crea un par de Items denominados REQNNNN y RITMNNNN y en
nuestra implementación de SN siempre es una relación 1 a 1.
4.1. Flujo de Carga de Solicitud por Portal de Servicio

4.1.1 Flujo de Carga por Catálogo
Debería seleccionar Mantenimiento Aplicaciones Específicas

jcgg - v2.docx

VP Servicios
Cada ítem del catálogo de Solicitudes es atendido por diferentes equipos (Aplicaciones,
Ciberseguridad, Infraestructura, etc), también cada elemento dentro de cada catálogo puede
tener flujos de atención diferentes, nos vamos a dedicar al flujo de atención de “Mantenimiento de
Aplicaciones Específicas”.

jcgg - v2.docx

VP Servicios
El usuario debe describir la solicitud.

jcgg - v2.docx

VP Servicios
• Un usuario puede cargar una solicitud en nombre de otro usuario

(Cambiar el campo Solicitado Para)
• Se puede elegir el usuario de contacto que es quien va a aprobar las UAT
y a recibir las comunicaciones del avance de la solicitud.
• Se puede elejgir el método de contacto ( Telefónico , email )
• Se puede elegir el tipo de Servicio entre:
o Asesoría
o Capacitación
o Evolutivo
Una vez que selecciona Enviar le muestra al usuario la lista de etapas asociadas
al RITM
4.1.2 Flujo de Carga por Ingreso de Pedido de Asistencia (Mesa CAU)
Este tipo de flujos de solicitudes debería desaconsejarse debido a que el usuario no introduce los
datos necesarios y no se activan las etapas necesarias para que se haga la Gestión de la Demanda y se
obtengan las aprobaciones obligatorias de cara a Auditoría.
El analista que reciba este tipo de Solicitudes, antes de rechazarla, debe decidir si lo que procede es
una Solicitud o un Incidente indicándole al usuario en las notas de rechazo, el procedimiento correcto de
carga. En el caso que sea un incidente y quedando a criterio del analista, puede cargar él mismo el incidente
poniéndolo a nombre del usuario.
Deberíamos abstenernos de cargar Solicitudes en nombre de un usuario.
Aunque estas Solicitudes terminen siempre rechazadas, se detalla de todas formas el flujo de
carga.

jcgg - v2.docx

VP Servicios
El usuario ingresa por “Solicitar Asistencia”

jcgg - v2.docx

VP Servicios
Ingresa los datos de la Solicitud

jcgg - v2.docx

VP Servicios
EL RITM generado debe ser atendido por el CAU

jcgg - v2.docx

VP Servicios
Potencialmente el CAU , al ver el Título puede cambiar el Elemento de Configuración y/o el Grupo de
Asignación del RITM y ya nos quedaría bajo nuestra responsabilidad de atención.
El RITM entrará en nuestra bandeja de Trabajo “Centro de servicio al usuario/ Trabajo de mis grupos”

jcgg - v2.docx

VP Servicios
Agregamos un comentario y cancelamos el RITM

jcgg - v2.docx

VP Servicios
4.2. Flujo de Atención de Solicitud válida

Solo a modo informativo ya que no participamos en esta etapa, en la etapa Ingresada, el Delegado
de la aplicación deberá aprobar la Solicitud antes que entre en la gestión del BRM
correspondiente. El Delegado debería recibir un mail indicándole que tiene un RITM para aprobar,
asimismo en el Portal de Servicios le debería aparecer una alerta de Aprobación.
En este punto la necesidas entra en Etapa de Backlog

jcgg - v2.docx

VP Servicios
En el Portal del Resolutor ( o Consola ), en el menú de trabajo

buscamos “Centro de servicio al usuario”, dentro del la sección
“Trabajo de mis Grupos” debería aparecer el RITM que el usuario
creó.
Tener en cuenta que los RITM deben pasar inicialmente por la
autorización del Delegado.
El BRM analiza con el negocio la prioridad de las solicitudes y asigna una priorización entre los
siguientes valores:
La priorización de las solicitudes ya no dan un orden relativo entre las solicitudes, solo se asigna
una prioridad que indica la urgencia para ser atendida, es decir varias solicitudes pueden tener la
misma priorización y habrá que negociar por fuera del sistema el orden de atención.
Una vez priorizado, pasa a Backlog Priorizado.

jcgg - v2.docx

VP Servicios
Hasta este momento no hay tareas asignadas a la célula, al pasarlas a etapa “Análisis y
Estimación” empiezan a generarse las tareas que debemos ir ejecutando.
En esta etapa se van a generar tareas para Analisis y Estimación de la Solicitud.

Es importante que como primer paso, asignemos un responsable de la solicitud quien deberá
encargarse de hacer la gestión de la misma:

jcgg - v2.docx

VP Servicios
Se genera inicialmente una tarea a la Célula para realizar el relevamiento.
Cada tarea debe completarse con los criterios en la sección siguiente

jcgg - v2.docx

VP Servicios
Para todas las tareas de la Solicitud se deben completar los siguientes datos:
• Elemento de Configuración: En general es el mismo Elemento de Configuración de la
Solicitud.
• Grupo de Asignación: El Grupo al que pertenecemos.
• Asignado a: Cada Analista que ejecuta la tarea.
• Breve Descripción: Descripción de la tarea.
• Horas Incurridas, mientras la tarea está abierta, se puede ir actualizando la cantidad de
horas utilizadas.
• Fecha Objetivo: Es la fecha en la cual se van a contabilizar las horas incurridas, si esta
fecha no se carga, se toma la fecha de cierre. Esta fecha se utiliza para calendarizar las
horas.
Para las solicitudes las tareas se van generando automáticamente, en el caso que una tarea
automática deba desglosarse, se pueden cargar tareas adicionales utilizando el botón Nuevo.
Importante tener en cuenta lo siguiente:
• La tarea automática la toma (Asignado A) el analista que ha tomado la Solicitud
• Las tareas desglosadas deben llamarse ( Descripción) Con nombres significativos que
incluyan el nombre de la tarea Automática mas el Analista que la atiende.
• La tarea automática se cierra solo cuando todas las tareas desglosadas se han cerrado (
para no activar antes de tiempo el workflow) y se debe cerrar con horas incurridas
indicando solo el tiempo dedicado a coordinar el resto de las tareas desglosadas o 0 (no
vacío ).
• Casos posibles de desglose:
o Un Análisis que se lleva a cabo en paralelo por 2 o mas analistas
o En la tarea de la Construcción intervienen varios desarrolladores.

jcgg - v2.docx

VP Servicios
Una vez terminada la tarea de Análisis, hay que realizar la estimación la cual consta de dos
partes, la Fecha de Entrega Estimada (Prueba de Usuario) que se selecciona a nivel del RITM y las
horas estimadas que se seleccionan dentro de la tarea de estimación.
No olvidar completar igualmente las horas incurridas para determinar las horas Estimadas.

jcgg - v2.docx

VP Servicios
Una vez se cierra la tarea de estimación, automáticamente la necesidad entra en etapa de

Ejecución
En esta etapa aparecen dos tareas que estructuran el trabajo para la construcción de la solución
de la solicitud.
Se deben ir ejecutando y cerrando las tareas, el entregable de estas dos etapas debería ser la
construcción de la solución en el ambiente de testing y el diseño de las pruebas unitarias y la
designación de las pruebas sugeridas para ejecutar durante la UAT.

jcgg - v2.docx

VP Servicios
Es posible que para la preparación del ambiente de Testing, se deban crear Cambios estándar a
Implementación y Despliegue
Seleccionar Estándar
Seleccionar la Plantilla de Soluciones
Seleccionar YPF_IMPLEMENTACION_Y_DESPLIEGUES_CENTRAL_FF

jcgg - v2.docx

VP Servicios
SeleccionarGDA-Paso Testing
Completar el CI del ambiente de Testing y en la Descripción indicar el Changeset o Release
Y se le da a Enviar.

jcgg - v2.docx

VP Servicios
Al cerrar la tarea de Especificación Funcional se abre la tarea de Pruebas Integrales para que
realicemos y documentemos las pruebas sobre la solución en ambiente de testing pero ejecutado
por personal del equipo de Mantenimiento.
Antes de cerrar la tare de Pruebas Integrales, es importante adjuntar al RITM el documento con
las pruebas ejecutadas para que el usuario las tenga disponibles en la siguiente etapa.

jcgg - v2.docx

VP Servicios
Una vez cerrada la tarea anterior la Solicitud entra en fase de Prueba de Usuario
El usuario recibirá una comunicación :
Al acceder, el usuario debe acceder al link del RITM:
En este punto al usuario se le presenta un pop-up para que cargue el documento de pruebas, si
todavía no lo tiene listo y tiene que descargárselo, debe cerrar el pop-up, descargarse el

jcgg - v2.docx

VP Servicios
documento de pruebas, completarlo y tenerlo listo para subirlo, para lo cual debe volver a
acceder al link para que se despliegue el pop-up.

jcgg - v2.docx

VP Servicios
Si el usuario no acepta las pruebas, la solicitud vuelve a fase de Ejecución , revirtiéndose las tarea
de Construcción, Especificación Funcional y Pruebas Integrales para corregir el error.
(la captura es sobre otra solicitud)

Una vez ejecutadas estas tareas, el usuario debe ejecutar las pruebas y generar evidencia para
decidir si acpeta las UAT.

jcgg - v2.docx

VP Servicios
Si el usuario Acepta las UAT, entonces la solicitud pasa a fase de Aprobación

Propietario/Delegado quien va a autorizar a pasar a producción la solución construida:
El Propietario/Delegado debería recibir en su Portal de Servicio la siguiente notificación:
Si el Propietario/Delegado rechaza una Puesta en Producción, la Solicitud vuelve a UAT y el

usuario con el BRM deberán gestionar con el Propietario Delegado por que razón no aprueba el
pasaje a producción.

jcgg - v2.docx

VP Servicios
Una vez que el Propietario/Delegado aprueba, la solicitud para a etapa “Pasaje a Producción”
En esta etapa se genera la tarea para la creación de Cambio a Implementación y Despliegues

jcgg - v2.docx

VP Servicios
El Cambio a Implementación y Despliegues se realiza desde la solapa “Solicitudes de Cambio”
Se selecciona un Cambio tipo Estándar ( que está pre-aprobado ).
Seleccionamos la plantilla de Soluciones
Y se selecciona la categoría siguiente:

jcgg - v2.docx

VP Servicios
Importante indicar el Elemento de configuración de la aplicación afectada ( no del servidor u otra

parte de la infraestructura ), Y el Changeset en TFS / DevOps con el script a ejecutar o el
documento describiendo los cambios a realizar.
Se podrán ir agregando todas las solicitudes de cambio que sean necesarias desde el RITM, nunca
desde la tarea “Generar Cambio” ya que el cierre del Cambio, automáticamente genera el cierre
de la tarea y se pasa a la etapa de “Post Implementación”.

jcgg - v2.docx

VP Servicios
Una vez cerrada la tarea de “Generar el Cambio” se abrirá la tarea de “Cerrar Solicitud”
En esta tarea verificamos que todo esté correcto en la implementación, una vez cerrada esta
tarea, la solicitud queda en etapa “Completado” y ya no se podrán abrir nuevos cambios
Así queda concluida la Solicitud.
4.3. Flujo de Solicitud con Solicitud a Infraestructura

Hay casos donde desde dentro de una solicitud, en especial durante la Construcción de la Solución
es necesario crear Solicitudes catalogadas al equipo de Infraestructura.
A diferencia de otro tipo de interacciones con Infra, para realizar una Solicitud asociada a una
Solicitud de Aplicaciones, se debe gestionar primero la Solicitud a Infra y luego relacionarlas.

jcgg - v2.docx

VP Servicios
En el menú de Self-Service accedemos al

Catálogo Técnico
Seleccionamos el ítem de catálogo que necesitemos solicitar a Infra
En este caso accedemos por Gestión de Aplicaciones

jcgg - v2.docx

VP Servicios
Se completan todos los datos

( pueden variar dependiendo
del tipo de Solicitud ) y se le
da a Enviar. También se
puede adjuntar un
documento si la Solicitud lo
requiere.
Se genera un par REQ/RITM
Hay que acceder al RITM accediendo al link sobre el campo descripción y copiamos el número del RITM
Una vez que tenemos el RITM anotado, vamos a la Solicitud de aplicaciones donde queremos relacionar la
Solicitud de infra, en la Solapa “Elementos Pedidos” vamos a acceder por “Editar”

jcgg - v2.docx

VP Servicios
Escribimos en el filtro el RITM de infra, lo pasamos a la lista de “Elementos pedidos” con el botón y
le damos a guardar.
De esa manera quedan ambos RITM relacionados.

jcgg - v2.docx

VP Servicios
5. Carga Horas Para Tareas Internas

Para cargar horas asociadas a tareas no relacionadas a Solicitudes o Incidentes de Usuarios, es
posible cargar Solicitudes Internas.
Es importante que solo se carguen horas que no pueden relacionarse directamente a una Solicitud o
Incidente de Usuario, tales como reuniones, check-ins, documentación interna, etc.
Abrir el Catálogo Técnico
Seleccionar Solicitud Interna

jcgg - v2.docx

VP Servicios
Si las actividades a registrar están relacionadas por ejemplo con un servidor o con una aplicación en
particular se puede establecer el Elemento de Configuración.
La Solicitud Interna genera automáticamente una Tarea
Hay que tener cuidado de no cerrar esta tarea hasta que se quiera cerrar la Solicitud Interna (Cambio de
Año por ejemplo) Ya que al cerrar esta tarea se cierra la Solicitud.
Tanto la Solicitud como la Tarea Automática debería asignarse al Líder del Equipo de Mantenimiento.
Cada uno de los Analistas que deba registrar horas, puede crear una nueva tarea con el botón .
Se deberían cargar todos los datos resaltados.

Para cargar horas para semanas pasadas, se debe especificar correctamente la Fecha Objetivo para que
sea bien contabilizada. La Fecha Objetivo debe caer en algún día dentro de la semana a la cual se quiere
asignar.

jcgg - v2.docx

VP Servicios
6. Diagramas
6.1. Diagrama de procesos para Solicitudes

jcgg - v2.docx

VP Servicios
6.2. Esquemático de interrelación de procesos.

jcgg - v2.docx

Instructivo - Service.now - Mantenimiento Aplicaciones Upstream

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Instructivo - Service.now - Mantenimiento Aplicaciones Upstream

Cargado por

Copyright:

Formatos disponibles

Clasificación YPF: No Confidencial

Autor: Juan Cristóbal García (RY10745)

Procesos y Sistemas Instructivo.Service.Now.Mantenimiento- Pág. 1 de 68

Clasificación YPF: No Confidencial

5. CARGA HORAS PARA TAREAS INTERNAS .............................................................................. 65

Procesos y Sistemas Instructivo.Service.Now.Mantenimiento- Pág. 2 de 68

Clasificación YPF: No Confidencial

Procesos y Sistemas Instructivo.Service.Now.Mantenimiento- Pág. 3 de 68

Clasificación YPF: No Confidencial

Aprobación de nuevos desarrollos o cambios (incluye correctivos)

Testing funcional de cambios por parte del usuario

Aprobación del pasaje a producción

Procesos y Sistemas Instructivo.Service.Now.Mantenimiento- Pág. 4 de 68

Clasificación YPF: No Confidencial

Describimos algunos de esos flujos a continuación:

3.1.1 Carga de Incidente desde Portal de Servicio

El usuario debería ingresar por Crear Incidente

Los campos obligatorios están marcados con *

Procesos y Sistemas Instructivo.Service.Now.Mantenimiento- Pág. 5 de 68

Clasificación YPF: No Confidencial

Se ingresa la aplicación, los nombres de las aplicaciones se muestran con el nombre de la

Procesos y Sistemas Instructivo.Service.Now.Mantenimiento- Pág. 6 de 68

Clasificación YPF: No Confidencial

Se ingresa el resto de la información para describir el incidente.

Por último presionar:

Procesos y Sistemas Instructivo.Service.Now.Mantenimiento- Pág. 7 de 68

Clasificación YPF: No Confidencial

3.1.2 Carga de Incidente desde Portal de Resolutor

Ingresar al Portal de Resolutor o Consola de Service Now y en el Filtro escribir “Incidencia”

Ingresar a Crear Nuevo y completar todos los datos marcados con

Procesos y Sistemas Instructivo.Service.Now.Mantenimiento- Pág. 8 de 68

Clasificación YPF: No Confidencial

3.2. Flujo Básico de Atención de Incidentes.

El ícono al lado de cada acceso nos permite ir creando

Incidencias Muestra todas las incidencias activas de la

Mi Trabajo va a mostrar todos los ítems de trabajo

Trabajo de mis grupos, muestra los ítems asignados a los

Items de trabajo pueden ser:

Y algunos tipos de ítem mas pero estos son los mas

Procesos y Sistemas Instructivo.Service.Now.Mantenimiento- Pág. 9 de 68

Clasificación YPF: No Confidencial

Es importante seleccionar correctamente la urgencia y la prioridad, estos parámetros determinarán si el

Procesos y Sistemas Instructivo.Service.Now.Mantenimiento- Pág. 10 de 68

Clasificación YPF: No Confidencial

• Elemento de Configuración: En general es el mismo Elemento de Configuración del Incidente.

Una vez terminada la tarea se debe cambiar el estado a Cerrado Completo

Procesos y Sistemas Instructivo.Service.Now.Mantenimiento- Pág. 11 de 68

Clasificación YPF: No Confidencial

Procesos y Sistemas Instructivo.Service.Now.Mantenimiento- Pág. 12 de 68

Clasificación YPF: No Confidencial

Procesos y Sistemas Instructivo.Service.Now.Mantenimiento- Pág. 13 de 68

Clasificación YPF: No Confidencial

Procesos y Sistemas Instructivo.Service.Now.Mantenimiento- Pág. 14 de 68

Clasificación YPF: No Confidencial

3.3. Flujo Incidente con Cambio Correctivo

Elegimos tipo de Cambio Estándar

Procesos y Sistemas Instructivo.Service.Now.Mantenimiento- Pág. 15 de 68

Clasificación YPF: No Confidencial

Elegimos GDA – Paso Testing

En el Cambio tenemos que completar el CI de la instancia de Testing de la aplicación:

Procesos y Sistemas Instructivo.Service.Now.Mantenimiento- Pág. 16 de 68

Clasificación YPF: No Confidencial