Migración de Proyectos

de Mantenimiento
Aplicacional JIRA a ServiceNow
Quick Guide
https://edp.service-now.com

Enero 2023
Migración a ServiceNow

Dentro del Proyecto de homogenización de procesos y procedimientos para las

aplicaciones de Viesgo dentro del marco de EDP España, a partir del próximo 1 de
Febrero, los Proyectos JIRA vinculados al Mantenimiento Aplicacional pasarán a
gestionarse a través de ServiceNow. https://edp.service-now.com

Esto afectará a los siguientes Proyectos:

3
Migración a ServiceNow

4
Migración a ServiceNow

5
Migración a ServiceNow

Las incidencias directamente abiertas en los Proyectos JIRA de los Equipos de

Mantenimiento pasarán a gestionarse en la nueva herramienta.

A continuación se describe el proceso de apertura y gestión de tickets.

6
01 Creación de Pedidos
Pedido → Creación

La creación de Pedidos en ServiceNow sustituye a las antiguas

Tareas/Peticiones de JIRA, tratándose de peticiones especiales
que no pueden tratarse específicamente como incidencias de la
Aplicación.
Para crear un ticket de este tipo, navegamos a través de la vista
Avanzada hasta “Catálogo de Peticiones de Servicio”
Pedido → Creación

En este punto, abrimos por completo el Catálogo EDPE-APLICACIONES para buscar la

aplicación sobre la que se desea realizar la petición.
Pedido → Creación

Una vez abierto todo el catálogo de aplicaciones disponible, se tendrá la opción de escoger.
02 Creación de Incidencia en
ServiceNow
Incidencia → New

Si el usuario accede a la Vista

Avanzada también puede crea
una incidencia a través del
menú Create New Incident.

12
Incidencia → Asignación

Los técnicos del grupo de asignación reciben una

notificación a través de la cual pueden acceder a la
incidencia.
También puede acceder a la incidencia a través del
menú “Asigned to My Groups” del módulo “Incident”.

13
Incidencia → Estados

En la parte superior de la
incidencia se pueden ver todos los
estados del flujo.
El estado en el que se encuentra la
incidencia aparece resaltado por
una línea inferior.

14
Incidencia → Estados

Diagrama de estados
de una incidencia

15
Incidencia → Gestión

El técnico puede retipificar la incidencia

modificando los campos categoría,
subcategoría y tipo.
Automáticamente se informará el grupo al
que se asignará la incidencia una vez
pulsado el botón [Update].

El técnico puede cambiar la prioridad de la

incidencia actualizando los campos impacto
y/o urgencia según la siguiente matriz:

16
Incidencia → Gestión

Un incidente dispone de tres campos de

edición para texto libre “Resolution note”,
“Additional Comments” y “Work Notes”.
Los campos “Resolution note” y
“Additional Comments” son visibles por el
usuario.
El campo “Work Notes” solo es visible
para los técnicos.

17
Incidencia → Botones

A través de los botones que aparecen en la parte superior

derecha el técnico puede realizar las siguientes acciones:
▪ Pending User: La incidencia pasa al estado pendiente de
usuario. Al usuario le llega una notificación
informándole de que es necesaria una acción por su
parte.
▪ Programmed intervention: La incidencia pasa al estado
intervención programada. El técnico debe informar una
fecha de reactivación en la cual la incidencia pasará de
nuevo al estado asignado.
▪ Cancel Incident: La incidencia pasa al estado cancelado.
▪ Resolved: La incidencia pasa al estado resuelta.
▪ Attachment: Permite adjuntar un fichero a la incidencia.
▪ Template: Si la tipificación de la incidencia tiene una
plantilla definida cuando se pulsa este botón la plantilla
se informa en el campo comentarios adicionales de la
incidencia.

18
Incidencia → Botones → Pending User

Pending User

Cuando el técnico pulsa el botón [Pending

User] debe cumplimentar los campos
“Substate” y “Additional Comments”, a
continuación debe pulsar el botón
[Update].

Al usuario le llega una notificación

informándole de que es necesaria una
acción por su parte.
El usuario debe añadir un comentario en
el campo “Additional Comments” y pulsar
el botón [Reactivate] para que la
incidencia se reactive pasando al estado
“Assigned”.
19
Incidencia → Botones → Programmed Invervention

Programmed Invervention

El técnico debe cumplimentar el campo

“Expected Start Date” con la fecha de
reactivación de la incidencia y pulsa el
botón [Programmed Invervention].

La incidencia se reactivará pasando al

estado “Assigned” cuando se cumpla la
fecha de reactivación marcada.

20
Incidencia → Botones → Cancel Incident

Cancel Incident

Cuando el técnico pulsa el botón

[Cancel Incident] la incidencia pasa al
estado “Cancelled”.
Es obligatorio añadir un comentario
de cancelación.

Una vez cancelada una incidencia no

es posible operar sobre ella.

21
Incidencia → Botones → Resolved

Resolved

Cuando el técnico pulsa el botón

[Resolved] la incidencia pasa al estado
Resolved.
Es obligatorio añadir un comentario en
el campo “Resolution notes” y
seleccionar una valor en el campo
“Resolution code”.

Al usuario le llega una notificación

informándole de la resolución de la
incidencia. Tiene la opción de
reactivarla a través del botón [Reopen]
o de cerrarla a través del botón [Closed]
.

Una vez cerrada una incidencia no es

posible operar sobre ella.

22
Incidencia → Botones → Attachment

Attachment

El técnico puede añadir un adjunto a

una incidencia a través del botón
[Attachment].

23
Incidencia → Botones → Template

Template

Si la tipificación de la incidencia tiene

una plantilla definida cuando se pulsa
este botón [Template] ésta se informa
en el campo “Additional Comments”.

24
03 Creación de cambio
Correctivo
Corrective Change → New

Cuando la resolución de una

incidencia requiere de la
implementación de un
desarrollo el proveedor debe
crear un corrective change a
través del botón [New] en la
pestaña “Corrective Changes”.
Corrective Change → New

El proveedor cumplimenta el
campo “Configuration item” y
pulsar el botón [Save].

Una vez creado el corrective

change la incidencia pasa al
estado “Pending Corrective
Change”.

La gestión del desarrollo se

realiza desde este momento a
través del corrective change.
Corrective Change → Planning

Una vez creado el corrective

change el proveedor debe
adjuntar el diseño técnico de
la solución en el campo
“Technical Solution” y
cumplimentar los campos
“Planned End Date” y
“Planned Effort”.
Seleccionar la acción
“Request Approval” y pulsar
el botón [Update].
Corrective Change → Planning Approval

El grupo IT puede cancelar el

corrective change a través de
la acción “Cancel Corrective
Change”, devolverlo al
proveedor solicitando
revisión seleccionando la
acción “Reject technical
solution and planning” o
aprobarlo con la acción
“Approve technical solution
and planning”.
Corrective Change → Work in progress

El proveedor debe
cumplimentar los campos
“Cause” y “Actual Effort”,
adjuntar las pruebas en el
campo “ADM Vendor Tests”,
seleccionar la acción
“Corrective Change
Implemented” y pulsar el
botón [Update]
Corrective Change → Testing/QA

El grupo IT puede ejecutar las siguientes

acciones:
▪ Request Affected User to Test:
solicitar pruebas al usuario afectado.
▪ Request review of implementation:
devolver el corrective change al
proveedor solicitando revisión.
▪ Request Key User to Test: solicitar
pruebas al key.
▪ Accept evidence and Authorize
deployment to production: avanzar el
corrective change a la siguiente fase.
▪ Cancel Corrective Change: cancelar el
corrective change.
Corrective Change → Deployment

Una vez transportado el

desarrollo al ambiente de
producción el proveedor
cumplimenta el campo “Close
Notes” y ejecuta la acción
“Close Corrective Change”.

El corrective change avanza al

estado “Closed Complete”.
04 Creación de Mejora
Aplicacional
Mejora aplicacional

Documento anexo.

https://jira.cloud.viesgo.com/secure/attachment/841811/ServiceNow_Mejora_Aplicacional%20-%20Evolutivos.pdf