relaciÓn entre la gestiÓn de cambios y los incidentes para minimizar su impacto...

FACULTAD DE INGENIERÍA

Carrera de Ingeniería Empresarial y de Sistemas

RELACIÓN ENTRE LA GESTIÓN DE CAMBIOS Y LOS INCIDENTES PARA MINIMIZAR SU IMPACTO

NEGATIVO EN LA EMPRESA GABBOT

Tesis para optar el Título Profesional de Ingeniero Empresarial y de

Sistemas

EDGAR PERCY CHAMBI BELIZARIO

ROBERT REYNA DEL AGUILA

Asesor:

Mg. Ángela Teresa Barreda Ramírez

Lima – Perú

2019

2

JURADO DE LA SUSTENTACIÓN ORAL

………………………………..…………………………………………….

Presidente

………………………………..…………………………………………….

Jurado 1

………………………………..…………………………………………….

Jurado 2

Entregado el: / /

Aprobado por:

………………………………………….

Edgar Percy Chambi Belizario Graduando

…………………………………………. ………………………………………….

Robert Reyna del Águila Graduando

Mg. Ángela Barreda Ramírez Asesor de Tesis

3

UNIVERSIDAD SAN IGNACIO DE LOYOLA

FACULTAD DE INGENIERÍA

DECLARACIÓN DE AUTENTICIDAD

Yo, Edgar Percy Chambi Belizario, identificado con DNI N° 43512583 y yo, Robert Reyna

del Aguila, identificado con DNI N° 09943386 Bachilleres del Programa Académico de la

Carrera de Ingeniería Empresarial y de Sistemas, de la Facultad de Ingeniería de la

Universidad San Ignacio de Loyola, presentamos nuestra tesis titulada:

Relación entre la Gestión de Cambios y los Incidentes para minimizar su impacto

negativo en la empresa GabBot.

Declaramos en honor a la verdad, que el trabajo de tesis es de nuestra autoría; que los

datos, los resultados y su análisis e interpretación, constituyen nuestro aporte. Todas las

referencias han sido debidamente consultadas y reconocidas en la investigación.

En tal sentido, asumimos la responsabilidad que corresponda ante cualquier falsedad u

ocultamiento de la información aportada. Por todas las afirmaciones ratificamos lo

expresado, a través de nuestra firma correspondiente.

Lima, 13 de diciembre del 2019

……………………………………………..

Edgar Percy Chambi Belizario

DNI 43512583

……………………………………………..

Robert Reyna del Aguila

DNI 09943386

4

Epígrafe

“Cuando ya no somos capaces de cambiar una situación, nos encontramos ante el desafío de cambiarnos a nosotros mismos” Viktor Frankl - 1945 en su obra “El hombre en busca de sentido”

5

ÍNDICE DE CONTENIDOS

ÍNDICE DE CONTENIDOS 5

ÍNDICE DE TABLAS 7

ÍNDICE DE FIGURAS 8

ÍNDICE DE ANEXOS 9

DEDICATORIA 10

AGRADECIMIENTO 11

RESUMEN 12

ABSTRACT 13

INTRODUCCIÓN 14

PROBLEMA DE INVESTIGACIÓN 15

Identificación del problema 15

Formulación del problema 20

Problema general. 20

Problemas específicos. 20

MARCO REFERENCIAL 21

Antecedentes 21

Antecedentes internacionales 21

Antecedentes nacionales 24

Estado del Arte 26

Marco Teórico 27

Gestión del cambio 27

Registro de Cambios de la empresa GabBot 32

Evaluación del riesgo de la empresa GabBot 34

Análisis de Cambios de la empresa GabBot 35

Planificación de los cambios de la empresa GabBot 36

Biblioteca de infraestructura de tecnologías de la información (ITIL) 38

OBJETIVOS 41

Objetivo general 41

Objetivos específicos 41

Objetivo específico 1 41



JUSTIFICACIÓN 42

Teórica 42

Práctica 42

Social 43

6

HIPOTESIS 44

Hipótesis general 44

Hipótesis específicas 44

Hipótesis específica 1 44



MATRIZ DE CONSISTENCIA 45

MARCO METODOLÓGICO 46

Metodología 46

Paradigma 46

Enfoque 46

Método 47

Variables 48

Independiente 48

Dependiente 48

Población y muestra 48

Población 48

Muestra 49

Unidad de análisis 49

Instrumentos y técnicas 49

Instrumentos 49

Técnicas 49

Procedimiento y método de análisis 50

Procedimiento 50

Método de análisis 50

RESULTADOS 52

DISCUSIÓN 76

CONCLUSIONES 78

RECOMENDACIONES 79

REFERENCIAS 80

ANEXOS 83

7

ÍNDICE DE TABLAS

Tabla 1. Lista de servicios, incidentes y eventos de GabBot. _____________________ 17

Tabla 2. Diagrama de Pareto. _____________________________________________ 18

Tabla 3. Cuestionario para evaluar el nivel de riesgo del cambio. _________________ 35

Tabla 4. Servicios tecnológicos prestados por la empresa GabBot a sus clientes. ____ 48

Tabla 5. Procesos de la gestión del cambio propuesto para la empresa GabBot. _____ 52

Tabla 6. Descripción de las características del cambio en la empresa GabBot. _______ 53

Tabla 7. Descripción de los datos del cambio en la empresa GabBot. ______________ 53

Tabla 8. Descripción de los detalles del cambio en la empresa GabBot. ____________ 54

Tabla 9. Evaluación de los cambios de tipo normal. ____________________________ 55

Tabla 10. Matriz de riesgos de cambios normales. _____________________________ 56

Tabla 11. Consideraciones Restore. ________________________________________ 58

Tabla 12. Información general del cambio. ___________________________________ 59

Tabla 13. Requisito de aprobación de cambio de emergencia. ____________________ 60

Tabla 14. Matriz RACI ___________________________________________________ 67

Tabla 15. Descripción de la simbología de los flujograma de proceso. ______________ 68

Tabla 16. Cronograma de la capacitación para la implementación de la nueva gestión

del cambio de la empresa GabBot. _________________________________________ 71

Tabla 17. Comparación de la lista de servicios, incidentes y eventos de la empresa

GabBot años 2018 y 2019. _______________________________________________ 71

Tabla 18. Valor porcentual de incidentes de la empresa GabBot para los años 2018 y

2019. ________________________________________________________________ 72

Tabla 19. Indicadores de cambios aprobados y cambios rechazados para el año 2018

y 2019. _______________________________________________________________ 73

Tabla 20. Relación de cambios aprobados e incidentes. ________________________ 73

Tabla 21. Relación de cambios realizados e incidentes. _________________________ 74

Tabla 22. Cantidad de actividades aprobadas e incidentes para los años 2018 y 2019. 74

Tabla 23. Relación de actividades planificadas e incidentes. _____________________ 75

8

ÍNDICE DE FIGURAS

Figura 1. Análisis FODA. _______________________________________________ 185

Figura 2. Diagrama de Ishikawa. __________________________________________ 16

Figura 3. Gráfico de Pareto. ______________________________________________ 33

Figura 4. Cálculo de costos de re trabajps por incidentes. _______________________ 37

Figura 5. Los 8 Pasos del cambio efectivo. __________________________________ 39

Figura 6. Etapas de la gestión de cambios 31

Figura 7. Formulario de la herramienta de gestión de cambios de GabBot. 33

Figura 8. Fases de un plan de trabajo. 37

Figura 9. Procesos de la ITIL. 39

Figura 10. Nivel de riesgos de la evaluación de cambios. ________________________ 57

Figura 11. Proceso de gestión del cambio. __________________________________ 68

Figura 12. Sub Proceso de cambio excepcional. ______________________________ 69

Figura 13. Sub Proceso de cambio Normal. __________________________________ 69

Figura 14. Sub Proceso de cambio de emergencia. ____________________________ 70

Figura 15. Número de incidentes y eventos atendidos por la empresa GabBot año 2018

y 2019. _______________________________________________________________ 72

9

ÍNDICE DE ANEXOS

Anexo 1. Plan de trabajo para la ejecución de cambios. 84

Anexo 2. Comité de cambios. 85

Anexo 3. Condiciones indispensables durante un cambio. 86

Anexo 4. Funciones, habilidades y actividades a realizar de los responsables de la

gestión del cambio. 87

Anexo 5. Costo y Beneficio 91

10

DEDICATORIA

Dedicado a Jehová por guiarme en todo

momento y hacer posible este objetivo. A

mis padres Edgar y Petronila por su

inmenso amor, por sus consejos y por ser

mi inspiración para seguir adelante. A mis

hermanos Isaías, Erika y Miriam, que con

su apoyo me enseñaron a esforzarme al

máximo y seguir firme con este objetivo.

Edgar Percy Chambi Belizario

Esta tesis se la dedico a mis hijos Tadeo y

Alejandro que son el motor y motivo de

superación, a mi esposa Marina por su

apoyo incondicional durante mis años

universitarios y también a mi mama

Adriana una mujer luchadora que siempre

me enseñó a salir adelante.

Robert Reyna del Aguila

11

AGRADECIMIENTO

Agradecer en primer lugar a Dios por brindarnos buena

salud e inteligencia para poder tomar buenas decisiones

y continuar mejorando a través de los estudios, también

a la empresa GabBot por brindarnos las facilidades

técnicas y documentación para la elaboración de la

presente tesis y un agradecimiento especial a nuestra

asesora Mg. Angela Barreda Ramírez por su minuciosa

revisión y paciencia.

12

RESUMEN

El presente estudio se trazó como propósito, determinar la relación entre la gestión de

cambios y los incidentes para minimizar su impacto negativo en la empresa GabBot. La

metodología utilizada fue cuantitativa, de campo, bajo un paradigma positivista, con un

enfoque cuasi experimental y transeccional, se aplicaron diferentes técnicas de recolección

de datos como fueron, la observación directa y el análisis de los datos recolectados sobre

el riesgo de los diferentes cambios, para poder demostrar la hipótesis del estudio. Siendo

la población similar a la muestra de siete servicios TI (Tecnología de Información) que

presentaron incidentes para el año 2018. Se realizó la propuesta de la nueva gestión de

cambios de acuerdo a la metodología ITIL V3 revisión 2011 (vigente al momento de iniciar

la presente tesis), que consta de ocho procesos: Registro de cambios, evaluación,

planificación y aprobación, ejecución, revisión y cierre, supervisión y comunicación,

métrica, descripción de la actividades y gestión y mejora del proceso; se aplicó una prueba

piloto de seis meses para el recojo de los datos y poder evaluarlos; se contabilizaron para

los mismos años 199 y 157 solicitudes de cambio, de las cuales se rechazaron el 8% y el

61% respectivamente, asimismo se realizaron 83 cambios para el año 2018 y 96 para el

año 2019; se evaluó la relación entre la gestión del cambio y los incidentes la cual fue

inversa y elevada, lo que significa que cuanto más apliquemos el proceso de gestión de

cambios y la planificación de los mismos, el porcentaje de incidentes disminuye logrando

resultados eficaces, y ahorro de costos en re trabajos, reprocesos y pagos de posibles

penalidades por indisponibilidad de servicios de los clientes de GabBot.

Palabra Clave: Cambio, incidente, aprobación, ejecución, cierre.

13

ABSTRACT

The purpose of this study was to determine the relationship between change management

and incidents to minimize their negative impact on GabBot. The methodology used was

quantitative, field, under a positivist paradigm, with a quasi-experimental and transectional

approach, different data collection techniques were applied, such as direct observation and

analysis of the data collected on the risk of the different changes, to be able to demonstrate

the hypothesis of the study. The population being similar to the sample of seven IT services

(Information Technology) that presented incidents by 2018. The new change management

proposal was made according to the ITIL methodology V3 review 2011 (effective at the time

of starting the this thesis), which consists of eight processes: Record of changes,

evaluation, planning and approval, execution, review and closure, supervision and

communication, metrics, description of activities and management and improvement of the

process; a six-month pilot test was applied to collect the data to evaluate it; 199 and 157

change requests were counted for the same years, of which 8% and 61% were rejected

respectively, 83 changes were also made for the year 2018 and 96 for the year 2019; the

relationship between change management and incidents was evaluated, which was inverse

and high, which means that the more we apply the change management process and its

planning, the percentage of incidents decreases, achieving effective results, and saving of

costs in rework, reprocesses and payment of penalties for unavailability of GabBot customer

services.

Keyword: Change, incident, approval, execution, close.

14

INTRODUCCIÓN

La presente investigación tuvo como finalidad la determinación de la relación entre la

gestión de cambios desde la fase de transición de ITIL y los incidentes en la infraestructura

de una empresa de servicios de tecnología de información, debido al elevado número de

incidentes que se presentaban dichos servicios a raíz de la ejecución de cambios.

Para dar posible solución a esta problemática, se utilizó una metodología (ITIL v3.0)

donde se hizo una propuesta de aplicar la gestión del cambio en la empresa GabBot, luego

realizar una prueba piloto para recolectar los datos de un semestre y realizar la

comparación de los años 2018 y 2019, para determinar la relación entre ambas variables

los cuales están estructurados de la siguiente manera:

En la primera etapa se identifica el problema de investigación en la empresa GabBot,

donde se aborda el problema principal y los específicos.

A continuación, se describen brevemente las investigaciones previas relacionadas con

el trabajo, que sirvieron de guía para su realización, además se desarrolló un estado del

arte relacionado con la investigación, luego se establecen los fundamentos teóricos que

dan sustento a la misma.

Como tercer punto, se describe el objetivo general y los objetivos específicos de la

investigación, en donde se establece el alcance de la misma, seguidamente se expone las

justificaciones por la cuales se realizaron estos estudios, además se establece las hipótesis

de la investigación, así como la matriz de consistencia.

Seguido, se desarrolló el marco metodológico donde se explica la metodología que se

llevó a cabo, el tipo de paradigma en el que se basó, el enfoque del estudio. Se describieron

las variables de la investigación, se indicó cual fue la población y muestra del estudio, se

mencionaron las técnicas de recolección de datos y se describe como se realizó la

validación y confiabilidad del instrumento utilizado, luego se mencionan los procedimientos

y el método de análisis de datos que se aplicó en la investigación.

Para finalizar, se presentan los resultados y el análisis estadísticos de los datos

recolectados, la discusión de los resultados, las conclusiones del estudio y las

recomendaciones para futuras investigaciones.

15

PROBLEMA DE INVESTIGACIÓN

Identificación del problema

A nivel mundial, las empresas que prestan servicios de tecnología basan su éxito en la

prestación de servicios ininterrumpidos que les garanticen a las organizaciones el flujo y

respaldo adecuado de su información, por lo que requieren contar con herramientas de

gestión, a nivel estratégico, para poder dar respuesta a cualquier incidente que pueda

suscitarse durante el desarrollo de las actividades.

A continuación, presentamos el análisis FODA del problema (figura 1).

F O D A

OPORTUNIDADES AMENAZAS

- Gestionar los cambios antes de realizarlos

- Clientes Insatisfechos - Penalidades - Indisponibilidad del Servicio - Pérdida de clientes y dinero

FORTALEZAS Clasificar los cambios para mantener la agilidad de los

cambios menores

Gestionar los cambios para minimizar el impacto y evitar pérdida de clientes y dinero - Cambios rápidos

DEBILIDADES Implementar un proceso de gestión de cambios para

minimizar los riesgos y bajar los costos

Clasificar, planificar y llevar un control de los cambios con la

finalidad de evitar degradación y corte en el servicio que afecte a

los clientes.

- Riesgo alto - Elevados costos

Figura 1: Análisis FODA

Problema: Alto índice de incidentes asociados a cambios no gestionados.

Fuente: Elaboración Propia

Diagrama Causa Efecto:

En la figura 2 se muestra, el diagrama de causa/efecto, donde se grafica que los problemas

radican en el alto índice de incidentes asociados a cambios no gestionados, para lo cual

se muestran las siguientes causas principales.

Método o Proceso, se refiere a que no existe un análisis de riesgo, falta de estándares

de trabajo y sobre todo no existe un proceso de gestión de cambios.

Personas, se logró identificar la poca capacitación, alto índice de rotación de personal

16

y sobre todo el miedo natural al cambio cultural.

Medición, no se logró identificar bitácora de cambios para el control y tratamiento de los

incidentes.

Medio ambiente, se encontró la cultura del desorden y de hacer las cosas de manera

rápida sin hacer un análisis previo de los riesgos.

Figura 2: Diagrama de Ishikawa

Fuente: Elaboración Propia

Ahora bien, la norma internacional ISO/IEC-20000, referente a la “Gestión de Servicios

de Tecnología de Información”, explica que los incidentes hacen mención a las acciones

que pueden generar una interrupción o reducción en la calidad de los servicios prestados

a los consumidores, lo cual puede tener una connotación negativa. Es por esto que deben

manejarse por medio de un sistema de gestión de incidentes estructurado, al cual se le

considera, en términos gerenciales, como “gestión de cambios”.

La gestión del cambio indica, según Lazzati (2014), “el cambio en cualquiera de los

elementos de una organización (estrategia, estructura de sistemas, entre otras), dado que

su objetivo comprende el diagnóstico de la situación actual y el diseño e implementación

de la situación deseada, las cuales incluyen intervenciones adecuadas y el manejo de la

transición” (p. 20).

17

Por otra parte, Jáuregui (2016), menciona que, en el Perú, la mayoría de las empresas

peruanas conciben de manera positiva la gestión del cambio en sus negocios, viendo cómo

el 58% de los empresarios peruanos lo percibe como una oportunidad de mejora, el 11%

como algo ineludible, el 21% como negativo y el 10% piensa que es altamente inviable

económicamente. Existen muchas opiniones no homogéneas en la actualidad con respecto

a la gestión de cambios para sobrellevar los incidentes en las empresas.

En ese sentido, la empresa de Servicios de Tecnología GabBot, gestiona la

infraestructura de TI de sus clientes nuevos, quienes reportan un alto índice de incidentes,

los cuales, en un 80% de las veces según estadísticas propias, son asociados a los

cambios no gestionados y que afectan de manera directa la disponibilidad de servicios

críticos, por consiguiente, terminan incurriendo en pérdidas importantes de información, re

trabajos, reprocesos y sobrecostos en la operación del servicio.

A continuación, se presenta la lista de servicios y cantidad de cambios e incidentes

registrados por la empresa en el año 2018:

Tabla 1. Lista de servicios, incidentes de GabBot.

Servicios Incidentes Cambios exitosos

Total de Cambios

Aplicaciones SAP (Sistema empresarial principal del cliente) 79 23 102

CECOM (Centro de Comando, o primera línea de solución de incidentes) 29 7 36

SO y aplicaciones (Sistemas Operativos y aplicaciones de soporte, Directorio Activo, Correo Electrónico, Web) 15 2 17

NOC (Centro de Operaciones de Redes y comunicaciones, enlaces de internet) 6 2 8

Backups y restores (Respaldo de información crítica) 5 0 5

SOC (Centro de Operaciones de Seguridad) 2 0 2

Monitoreo (Revisión y análisis de eventos de tecnología y negocio) 1 0 1

Total 137 34 171

Fuente: Elaboración propia.

Enfocándose en las causas asignables de las interrupciones en la prestación de

servicios dado los incidentes presentados, se presenta, del mismo modo el porcentaje de

incidentes y el diagrama de Pareto:

18

Tabla 2. Diagrama de Pareto.

Servicios Frecuencia %

incidentes %

Acumulado

Aplicaciones SAP (Sistema empresarial principal del cliente) 79 58% 58%

CECOM (Centro de Comando, o primera línea de solución de incidentes) 29 21%

79%

SO y aplicaciones (Sistemas Operativos y aplicaciones de soporte) 15 11%

90%

NOC (Centro de Operaciones de Redes y comunicaciones, enlaces de internet) 6 4%

94%

Backups y restores (Respaldo de información crítica) 5 4% 98%

SOC (Centro de Operaciones de Seguridad) 2 1% 99%

Monitoreo (Revisión y análisis de eventos de tecnología y negocio) 1 1%

100%

Total 137


Figura 3. Gráfico de Pareto.


Como se observa en la figura 1, el mayor porcentaje de incidencias ocurre en las

aplicaciones SAP (58%) y Cecom (21%), mientras que en SO y Aplicaciones, NOC, Back

Ups y Restores, SOC y Monitoreo se presentaron porcentajes de 11%, 4%, 4%, 1% y 1%,

respectivamente. Esto, dado que cuando se produce un cambio en la infraestructura de

información porque el resultado no fue planificado, se convierte en un incidente, lo que

genera indisponibilidad o deficiencia en el desempeño de los servicios prestados a sus

clientes.

19

Asimismo, estos incidentes representan costos considerables en la organización, puesto

que los más agravantes son aquellos que muestran mayor porcentaje de incidencias.

Durante el semestre (Mayo – Octubre) del año 2018, se tuvieron 79 incidentes del sistema

SAP y 29 de Operaciones Cecom (108 incidentes en total), esta es la muestra con la que

se trabajó el piloto (el cual representa el 79% según pareto), lo cual representó un tiempo

de parada o «Downtime» de 2 horas cada uno. El sistema SAP ERP o sistema empresarial

clave para el negocio y Cecom Operaciones, es utilizado por 10 colaboradores para la

gestión empresarial (facturación, contabilidad, almacén, logística y ventas) y es soportado

por 2 ingenieros de TI, por lo que el costo del recupero o re trabajo por estos incidentes

fue de S/. 66,272.73 en los 6 meses o S/ 11 045.45 por mes.

Figura 4. Cálculo de costos de re trabajo por incidentes.

Fuente: Elaboración propia

20

Por todo lo mencionado anteriormente, esta investigación persigue la determinación de

la relación que existe entre la gestión de cambios y los incidentes en la infraestructura de

una empresa de servicios de TI, en este caso, en la empresa GabBot.

Formulación del problema

Problema general.

¿Cuál es la relación entre la gestión de cambios y los incidentes para minimizar su impacto

negativo en la empresa GabBot?

Problemas específicos.

1. ¿Cuál es la relación entre la gestión de cambios desde la fase de transición de ITIL

y los incidentes en la infraestructura de una empresa de servicios de tecnología de

información?

2. ¿Cuál es la relación entre la gestión de cambios desde la fase de operación de ITIL


información?

3. ¿Cómo se puede medir el impacto que tiene la planificación de la gestión de

cambios y los incidentes en la infraestructura de una empresa de servicios de

tecnología de Información?

21

MARCO REFERENCIAL

Antecedentes

Antecedentes internacionales

Blumberg, Cater-Steel, Rajaeian y Soar (2019) desarrollaron una investigación

denominada “Cambio organizacional efectivo para lograr el éxito Implementación de ITIL”,

la cual tuvo como objetivo identificar las estrategias de cambio organizacional empleadas

por las organizaciones que han llevado a cabo una implementación exitosa de ITIL. La

metodología empleada fue el estudio de caso múltiple que comprende implementaciones

ITIL exitosas en ocho grandes organizaciones australianas. Un enfoque de sistemas socio-

técnicos representado por el Leavitt's Diamond es adoptado como una lente para arrojar

luz sobre los atributos de las estrategias efectivas de cambio organizacional para una

implementación exitosa de ITIL. Como hallazgos se identificó que la implementación de

ITIL requería cambios en los cuatro componentes del sistema de trabajo socio-técnico

(STS) identificados en Leavitt's Diamond. Los cambios en un componente STS afectaron

a otros componentes STS al implementar ITIL; y ese esfuerzo aplicado a los componentes

STS no tenía por qué ser igual, sino adecuado a los requisitos de la implementación de

ITIL y de la organización.

Ruiz, Moreno, Dorronsoro y Rodriguez (2018) elaboraron un trabajo denominado “Uso

de la optimización basada en la simulación en el contexto del proceso de cambio de la

gestión de servicios de TI”, el cual tuvo como objetivo realizar la optimización multi objetivo

basada en la simulación para seleccionar estrategias óptimas de procesos de gestión de

cambios que ayuden a los CIO’s (Chief Information Officers) a alcanzar la eficiencia de los

procesos como un Factor de Éxito Crítico (CSF). La metodología se basó en la construcción

de un modelo de simulación multi objetivo, fundamentado en paradigmas de simulación de

eventos discretos y basados en agentes, para simular todo el ciclo de vida del proceso,

desde el inicio del cambio hasta su cierre; también se aseguró una entrega eficiente del

proceso de gestión del cambio que se requiere optimizar simultáneamente con los

correspondientes Indicadores Clave de Desempeño (KPIs) en los que se puede reducir el

CSF de la eficiencia del proceso; se aplicaron dos conocidos algoritmos evolutivos multi

objetivo, “NSGA-II” y “SPEA2”, para obtener un conjunto de soluciones óptimas para los

KPIs asociados; También comparamos los resultados obtenidos con el resultado del

algoritmo de optimización de un solo objetivo proporcionado por la herramienta de

simulación. Como resultado después de las simulaciones ejecutadas por los dos

22

algoritmos, se obtuvo un Pareto compuesto de 27 soluciones de alta precisión, donde se

evidencia que el 89% de las soluciones requieren una relación de duración inferior a 5.0;

además, se observó que las soluciones con mayor porcentaje de cambios realizados son,

como era de esperar, las más costosas (es decir, las que requieren mayor número de

estaciones). Las soluciones con más del 80% de cambios completados a tiempo requieren

al menos 15 personas. Al comparar las soluciones obtenidas con las de AnylogicTM

(software de simulación), podemos ver que esta última no puede superar a ninguna de las

soluciones seleccionadas a partir de los algoritmos multi objetivo.

Villegas (2018) desarrolló una investigación titulada “Propuesta de modelo de gestión

de incidencias y peticiones de servicios de TI para el Banco Desarrollo de los Pueblos

basado en ITIL V3:2011 como parte del plan estratégico”, el cual tuvo como finalidad

proponer un modelo de gestión de incidencias y peticiones de servicios de TI en el Banco

Desarrollo de los Pueblos empleando ITIL V3:2011. La metodología aplicada para esta

investigación fue de tipo cualitativo y nivel descriptivo, las técnicas de recolección de datos

aplicada fue la entrevista y el análisis de brecha de la metodología ITIL, se realizó un

diagnóstico de la situación actual de los procesos operativos del departamento de

operaciones y tecnología de información (DOTI), posteriormente se efectuó el diseño de

un modelo de gestión que abarca la gestión de tickets (incidencias y peticiones) abarcando

los servicios de negocios de la empresa. Se obtuvo como resultado, que el diagnóstico en

el DOTI tuvo un Nivel Inicial, considerado como caótico y no definido; igualmente se

destacaron como problemas internos: servicios no definidos, procesos no formalizados,

mientras que la gestión de incidencias y de petición de servicio carece de: más punto de

control, responsabilidades definidas, bases de datos de conocimiento y “configuration

management data base” (CMDB); la gestión de tickets recibirá las incidencias, peticiones

de usuarios, además describirá las etapas para solucionar en el menor tiempo posible por

medio de Acuerdos de Niveles de Servicios (SLA), mediante el indicador KPI09 como el

porcentaje de la gestión de tickets.

Cifuentes (2017) realizó una “Propuesta de ajuste al modelo de gestión de incidentes de

la empresa Claro Colombia S.A. para el mejoramiento continuo de los tiempos de respuesta

basado en ITIL V3”, el cual tuvo como objetivo de plantear alternativas de mejora al modelo

actual de gestión de incidentes de ITIL V3 en el proveedor de internet Claro en Colombia,

para bajar la tasa de los tiempos actuales de respuesta ante los incidentes reportados al

equipo de TI en las sedes remotas. La metodología aplicada fue un enfoque cualitativo, del

tipo descriptivo explicativo además de transversal, de igual manera se apoyó en el Ciclo de

Deming, enfocándose en la fase de operación e incidentes del servicio. Se obtuvo como

23

resultado, que el mayor número de incidentes asignado por soportes en un periodo de

septiembre a noviembre fue de 680, los cuales fueron catalogados como otros fallos entre

un total de 5 categorías; mientras que el promedio de incidentes mayores reportados a

soporte en el mismo rango de tiempo fue de 486.2; para determinar las causas de la

clasificación del número mayor de incidentes se evaluaron 245 de estos, se obtuvo que 76

incidentes fueron clasificados de forma incorrecta en la línea de soporte de servicio “Mi

PC”, además se encontró que 12 incidentes fueron clasificados mal en la línea de servicio

“Mis Aplicaciones Claro”, la causa principal fue la falta de opciones de clasificación de los

incidentes, representado el 62% de los incidentes estudiados; por otra parte 64 incidentes

no cumplen con los plazos de respuestas acordados, mientras que los restantes 181

incidentes si cumplen con los plazos acordados por la empresa; como propuesta para

mejorar la gestión de incidencias se crearon nuevas clasificaciones en la línea de servicio

“Mi PC” denominadas: “Periféricos/ Accesorios”, “Pc Escritorio”, “Portátil” y los nuevos tipos

de fallas son: “Monitor”, “Mouse”, “teclado”, “Fallas de conexión a la red” y “Configuración

del sistema operativo”; la revisión de la mejora propuesta al modelo actual de gestión de

incidentes, el cual fue evaluado por juicio de experto dio un promedio ponderado de 98.5%,

lo cual indica que el modelo fue aceptado, lo que quiere decir que es aplicable y factible en

la organización.

Pazmiño (2017) efectuó una investigación denominada “Propuesta de implementación

de una mesa de servicios utilizando como modelo de gestión ITIL en el departamento de

redes infraestructura y soporte técnico en la defensoría pública de Quito (Matriz)”, el cual

tuvo como objetivo proponer la implementación de una mesa de servicios empleando como

modelo de gestión a las actividades de la biblioteca de infraestructura de tecnologías de la

información (ITIL). Empleándose una metodología del nivel descriptivo cualitativa, además

se empleó el marco de madurez propio de ITIL. Entre los resultados obtenidos, se pudo

identificar el modelo de la función de la mesa de servicio adaptado adecuadamente a la

actualidad del departamento; luego se desarrolló la documentación propuesta que permite

realizar la implementación; la evaluación de la propuesta fue hecha a través de entrevista

del personal técnico; se observó un bajo nivel de madurez en cada una de las gestiones

evaluadas, siendo este igual a 1 (inicial), siendo las áreas evaluadas: Visión y dirección,

procesos, personas, tecnología y cultura.

24

Antecedentes nacionales

Fernández (2018) efectuó un trabajo de investigación denominado “Implementar una

aplicación en la web para mejorar la gestión de requerimientos e incidencias en el Hospital

General”, el cual tuvo como propósito implementar una aplicación Web para mejorar la

gestión de requerimientos e incidencias en el Hospital General. Esta investigación se basó

en las buenas prácticas de ITIL, siendo del tipo cuantitativo, no experimental, transversal y

correlacional, con un paradigma positivista; se empleó como técnica de recolección de

datos la observación directa, la entrevista y la encuesta. Como resultado se obtuvo que los

tiempos de respuesta para la atención de las incidencias y requerimientos generados por

los usuarios mejor; también se observó una disminución del tiempo aplicado para la

resolución; los costos relacionado con la demora en la resolución de las incidencias fue de

S/. 144,602.06; mientras que el costo de inversión para la implementación del software

OTRS fue de S/. 1,249.80, por lo cual se evidencia un beneficio relacionado por la

disminución del tiempo de atención de los requerimientos e incidencias.

Gómez (2018) desarrolló una “Mejora en la mesa de ayuda (Help Desk) de un organismo

regulador en el estado peruano utilizando ITIL”, la cual tuvo como finalidad Implementar

buenas prácticas de ITIL con un sistema de software que beneficie a la identidad

reguladora gubernamental. Mientras que la metodología aplicada fue de tipo experimental,

con un diseño de campo cuantitativo, además de realizarse una comparación de media del

tiempo del uso de buenas prácticas, también se aplicó el software CA Service Desk, para

realizar el registro de Tickets de incidencias. Como resultado se obtuvo la disminución del

50% de los costos de atención en relación al servicio de mesa de ayuda, también se redujo

el número de incidencia a un 27%.

Morillo (2018) ejecutó un trabajo denominado “Implementar un portal de conocimiento

por lecciones aprendidas sobre incidentes tecnológicos para incrementar la productividad

en empresa aseguradora”, el cual tuvo como objetivo determinar el aumento de la

productividad en una empresa aseguradora al aplicar un portal de conocimiento por

lecciones aprendidas sobre incidentes tecnológicos. La investigación tuvo una metodología

no experimental y correlacional, enfocado en un paradigma positivista, además de

enfocarse en un estudio cuantitativo, asimismo el proyecto seguirá la metodología de

ejecución del sistema de la empresa aseguradora peruana: análisis, diseño, construcción,

certificación e implementación. Como resultado que una vez implementado el portal

conocimiento por lecciones aprendidas se realizó la comparación del antes y después,

observándose que el tiempo de solución de incidentes promedio antes de la

25

implementación fue de 151.37 minutos, mientras que después de la aplicación fue igual a

96.97 minutos, lo cual representa una reducción de tiempo de 36%; relación a la búsqueda

de solución de los incidentes promedio para la evaluación previa fue de 56.34 minutos y

después de la aplicación fue de 32.29 minutos, observándose una reducción de 43%, el

número de reincidencias a partir de una incidencia promedio antes de la implementación

fue de 2.66 y después de la misma fue de 0.71, evidenciándose una reducción del 73%;

también se midió el re trabajo promedio originado por la incidencia antes de la

implementación el cual fue de 0.68 y después de esta fue de 0.18, observándose una

disminución del 74% del mismo; finalmente el nivel de disponibilidad de servicios promedio

antes de la implementación del portal era de 97.70% y posterior a la aplicación fue de

98.75%, observándose un aumento de 1.047%; con estos resultados se determinó la

relación entre la implementación de portal de conocimiento por lecciones aprendidas y la

productividad, al aplicar la prueba Mann-Whitney el valor de significancia fue de 0.033, lo

que indica que existe una relación directa y positiva, por lo que la implementación del portal

aumenta la productividad de la empresa aseguradora.

Díaz (2018) realizó un trabajo denominado “Formular un modelo de gestión de servicios

para SAAS a través de ITIL”: caso Siempresoft E.I.R.L Chiclayo el cual tuvo como objetivo

desarrollar un modelo de gestión de servicios para SaaS en la empresa Siempresoft para

garantizar la resolución de los de incidentes y problemas de TI. La metodología aplicada

se basó en una investigación aplicada, propositiva, relacional. Como resultado se obtuvo

que la estructura y organización de la mesa de ayuda a los servicios de TI, resolución de

incidentes y problemas, concientización de usuarios y calidad de servicios explican el

85.3% de la varianza de la gestión de incidentes y problemas de TI permitiendo demostrar

que estas dimensiones para evaluar el modelo de gestión de servicios para SaaS (Software

as a Service), basado en ITIL es aceptable y confiable.

Gonzales (2015) efectuó una “Implementación del marco de trabajo ITIL V.3.0 para el

proceso de gestión de incidencias en el área del centro de sistemas de información de la

gerencia regional de salud Lambayeque”, el cual tuvo como propósito implementar las

buenas prácticas del marco de trabajo ITIL v3.0, para la gestión de incidencias de TI en la

Gerencia Regional de Salud Lambayeque provincia de Chiclayo, con la intención de ofrecer

un mejor servicio de TI a los colaboradores de dicha entidad. Para recolección de la

información se empleó las encuestas y las fichas de observación. Los hallazgos evidencian

que al añadir herramientas y controles basados en ITIL v3.0, se evidenció que el número

de incidencias de TI registradas en el área del Centro de Sistemas de Información (CSI),

se redujo a un 30%; por otro lado los lapsos de tiempos para dar solución a incidencia de

26

TI de acuerdo al impacto y premura, se redujo en 30 minutos; mientras que el tiempo

promedio de la solución de incidente fue de 90 minutos de acuerdo a su impacto y premura,

lo que permitió el trabajo continuo; el tiempos para atender una incidencia de TI, mejoró en

dos horas, con un duración de seis horas promedio para la atención de las incidencias de

TI, lo que incrementó la efectividad y confiabilidad del área del CSI. La satisfacción de los

clientes se incrementó en un 65%.

Estado del Arte

En su esencia, ITIL se centra en el servicio y prescribe una infraestructura organizacional

para la prestación de servicios de TI a través de procesos. La última versión, ITIL V3,

publicada en 2007 y revisada en 2011, explica en cinco volúmenes (Estrategia del Servicio,

Diseño del Servicio, Transición del Servicio, Operación del Servicio y Mejora Continua del

Servicio) el conjunto de procesos que debe realizar un servicio de TI. Estos procesos

delinean cómo se mueve un servicio a través del ciclo de vida: cómo debe planificarse y

construirse el servicio de TI; cómo debe validarse, probarse e implementarse el servicio de

TI y los cambios relacionados; cómo deben gestionarse los eventos y las solicitudes

relacionados con el servicio de TI; cómo debe controlarse la configuración básica que

soporta el servicio de TI; y cómo deben resolverse los problemas operativos (Marrone &

Kolbe, 2011; Taylor, 2007 citado por Eikebrokk & Iden, 2017).

Un departamento de TI reconocerá la utilidad de los modelos de referencia de procesos

cuando el uso de los modelos de referencia reduzca el esfuerzo necesario para la

construcción de sus propios procesos. Sin embargo, cuanto más específico es un modelo

de procesos de referencia, menos departamentos de TI son lo que podrán aplicarlo: "el

dilema del modelado de referencia" (Becker, Delfman, Knackstedt y Kuropka, 2002 citado

por Eikebrokk & Iden, 2017).

De acuerdo a Van Bon (2002) citado por el autor anterior, la Biblioteca de Infraestructura

de la Tecnología de la Información (ITIL) se contextualiza dentro de la perspectiva y

evolución de la reingeniería de procesos y la gestión de los principales procesos del

negocio. La perspectiva del proceso se ha convertido en un enfoque aceptado de la forma

en que las organizaciones piensan y gestionan su negocio. En sus inicios, el pensamiento

de procesos (entonces llamado reingeniería de procesos) se posicionaba como un esfuerzo

episódico, en lugar de continuo (Hammer, 2010 citado por Eikebrokk & Iden, 2017).

Poco a poco, la orientación a los procesos ha ido evolucionando hasta convertirse en lo

que hoy en día se entiende por gestión de procesos empresariales, una disciplina que

27

abarca no sólo el rediseño y la implantación de los procesos empresariales, sino también

el control administrativo y de supervisión continuo para garantizar que sigan cumpliendo

los objetivos empresariales y las necesidades de los clientes (Smith & Fingar, 2003 citado

por Eikebrokk & Iden, 2017).

En este sentido, la implementación de los procesos de referencia ITIL en un

departamento de TI difiere de la reingeniería de procesos tradicional en que el objetivo de

un proyecto de implementación de ITIL es adaptar las prácticas organizativas existentes a

las prescritas por ITIL, mientras que un proyecto de reingeniería de procesos estándar tiene

más libertad en sus actividades de análisis y rediseño (Eikebrokk & Iden, 2017).

Hay muchas discusiones dentro de la comunidad de Gestión de Servicios de TI (ITMS)

sobre el mejor camino para implementar y mejorar los procesos de ITSM. Esto demuestra

que no existe ningún modelo de madurez de ITSM que se acepte globalmente como

referencia. Son pocos los modelos de madurez existentes que son consistentes con la

Biblioteca de Infraestructura de TI (ITIL), las mejores prácticas más populares para la

gestión de servicios de TI (Picard, Renault, & Barafort, 2015).

Según el autor, es comúnmente aceptado que la implementación de ITIL dentro de una

organización no es fácil, principalmente porque ITIL dicta "lo que" las organizaciones

deberían hacer idealmente, pero no mucho sobre "cómo" deberían hacerlo. El uso de un

modelo de madurez ITSM se considera a menudo como (parte de) la solución para

determinar el "cómo", pero es un malentendido del concepto de modelo de madurez, ya

que un modelo de madurez sólo describe los estados estables (es decir, los niveles de

madurez) que una organización debe alcanzar durante la implementación de sus procesos

de mejora. Sin embargo, la manera de lograr esta " Los estados de madurez " pueden ser

muy diferentes de una organización a otra (Picard et al., 2015).

Marco Teórico

Gestión del cambio

La literatura sobre el cambio en la organización abarca en gran medida diversas

perspectivas e inconsistentes sobre la gestión del cambio. Por esta razón se abordará dos

enfoques principales de la gestión del cambio: el cambio planificado y el cambio emergente.

28

Gestión del cambio planificado.

De acuerdo a los autores, el cambio planificado es un enfoque proactivo del cambio

organizacional que es impulsado predominantemente por el liderazgo de la organización.

El cambio planificado describe la progresión intencionada de las actividades que llevan a

una organización a una condición requerida que cumple con objetivos específicos. El

cambio planificado también se ha descrito como el traslado intencional de la organización

del estado actual a un estado preferido para lograr los objetivos establecidos. El cambio

planificado se produce cuando una organización aplica un proceso establecido y toma las

medidas apropiadas para cambiar la organización en términos de la forma en que opera,

las condiciones en la organización y la estructura de la organización. La intención es que

una organización identifique el requisito de cambio e inicie las acciones apropiadas antes

de que la necesidad del cambio ocurra realmente. Un enfoque de cambio planificado

permite la inclusión de los participantes necesarios durante la etapa de planificación,

aumentando así posiblemente el apoyo al cambio y, posteriormente, las oportunidades de

éxito del cambio (Buono y Kerber, 2010; Linstead et al., 2004; Ford y Greer, 2005; Kerber

y Buono, 2005 citados por Blumberg et al., 2019).

El modelo de cambio planeado de Lewin (1947) comprende tres etapas

(descongelación, cambio y recongelación). Es reconocida como la primera teoría que

aborda el cambio organizacional y ha sobrevivido más tiempo que muchas otras. Otro

modelo del cambio planificado lo establecen Bullock y Batten que incluye cuatro fases:

exploración, planificación, acción e integración; así como también el modelo de proceso de

seis pasos de Price y Chahal, que incluye la preparación, desarrollo e implementación,

verificación, comunicaciones y evaluación. (Burnes y By, 2012; By, 2005 citados por

Blumberg et al, 2019).

Gestión del cambio emergente.

Los autores antes citados por Blumberg et al. (2019) considera que el cambio planificado

y el desarrollo organizacional comenzaron a recibir críticas desde los años ochenta y desde

entonces surgieron nuevas y diferentes teorías de cambio. El cambio emergente es el

reconocimiento de que el cambio no ocurre como un evento aislado, sino que es continuo

e impredecible. Desde una perspectiva de cambio emergente, el cambio no ocurre como

algo único. Más bien, el cambio es un requisito continuo de reajustes de la organización

que no se puede predecir. De esta manera, la organización cambia como un ajuste a los

cambios en su entorno. Mientras que el cambio planeado es formal, el cambio emergente

es circunstancial e informal.

29

Según By, (2005 citado por Blumberg et al., 2019) existen tres modelos primarios de

cambio emergente, los cuales fueron desarrollados por diversos autores Kotter en 1996,

Kanter Stein y Jick en 1992, además de Luecke en 2003. Sin embargo, los libros oficiales

de ITIL no incluyen consejos sobre cómo implementar ITIL, pero proponen el modelo de

Kotter de cambio organizacional como un método útil para gestionar el cambio

organizacional. Los ocho pasos en el modelo de Kotter incluyen: establecer un sentido de

urgencia, formar una coalición líder poderosa, desarrollar una visión, comunicar la visión,

delegar a otros para actuar en la visión, generar ganancias a corto plazo, consolidar

mejoras y producir más cambios e institucionalizar los nuevos enfoques. (Norita et al.,

2013, AXELOS Limited, 2011, citados por Blumberg et al., 2019) (Ver figura 8)

Figura 5: Los 8 pasos del cambio efectivo

Fuente: John Kotter

Gestión del cambio ITIL.

La Gestión del cambio ITIL, es un proceso que tiene como objetivo comprender y reducir

los riesgos cuando se implementan cambios de TI (Informática para tu negocio, 2016).

Todas las organizaciones suelen tener dos requisitos clave para la prestación de servicios

de TI:

Los servicios deben ser firmes, íntegros y previsible.

Los servicios deben poder adaptarse rápidamente a las necesidades cambiantes

de la empresa.

Como se puede observar, estas expectativas son contradictorias. El objetivo de la

gestión del cambio es, facilitar que la gestión de los servicios de TI cumpla ambas

expectativas, permita un cambio veloz y reduzca el riesgo de interrupción del servicio.

La gestión del cambio para “Informática para tu negocio (2016)” a menudo utiliza un

proceso consecuente para provocar el cambio y por esta razón, en ocasiones se considera

30

como una forma de dificultar el cambio a través de procedimientos. Sin embargo, si uno de

los procesos de gestión de cambios se ejecuta cabalmente, puede permitir cambios más

significativos de lo que sería posible en ausencia de este. Efectuándose de la forma

siguiente:

- Asegurarse de que todos los cambios planteados se evalúen en función de sus aportes

y riesgos y teniendo en cuenta todos los impactos.

- Priorizar los cambios para que los recursos limitados se asignen a los cambios que

más beneficios generan al negocio.

- Requerir que se evalúen a profundidad todos los cambios y que cada implementación

contenga un método de copias de seguridad para hacer rollback (regresar al estado

anterior) si la implementación falla.

- Asegurarse de que el proceso de gestión de la configuración se renueva para mostrar

el impacto de los cambios.

Finalidad de la gestión del cambio Proceso de Gestión de Cambios.

La finalidad principal de la Gestión de Cambios es que se efectúen y apliquen

apropiadamente cada uno de los cambios requeridos en la infraestructura y servicios TI

certificando el persecución de operaciones pauta (ITIL® Foundation, 2011).

La Gestión de Cambios debe ocuparse para garantizar que los cambios:

Están justificados.

Se efectúan sin deterioro de la calidad del servicio TI.

Están útilmente registrados, clasificados y documentados.

Se han evaluado minuciosamente en un ambiente de ensayo.

Se ha registrado en la base de datos de la gestión de configuración (CMDB).

Pueden deshacerse por medio de métodos de "retirada del cambio" (back-outs) en

caso de un funcionamiento inadecuado después de su implementación.

31

Etapas de la gestión de cambios.

Las etapas fundamentales de la Gestión de Cambios se sintetizan en el siguiente

diagrama de flujo (Ver figura 6).

Figura 6. Etapas de la gestión de cambios.

Fuente: ITIL® Foundation (2011).

32

Una correcta ejecución de gestión del cambio tendrá los siguientes beneficios:

Reducir el número de potenciales incidentes y/o problemas relacionados al cambio.

Tener un plan de “rollback” (regresar al estado anterior del servicio), que ayude a

evitar el impacto negativo en los servicios de TI en caso se tuviese un incidente

asociado al cambio.

Disminuir el número de correcciones o rechazos relacionados al cambio.

Mejorar la aceptación de los cambios.

Evaluar los costes reales asociados al cambio, para tener costos claros de

inversión.

Mantener actualizada la CMDB (base de datos de configuración), para tener

información que ayuden a evaluar los futuros cambios.

Desarrollar y mantener actualizados los procedimientos de cambios (estándar,

normal, de excepción y emergencia).

Registro de Cambios de la empresa GabBot

El proceso inicia con registrar el RFC (Request For Change), este se realiza a través de la

herramienta de Tickets de GabBot. El responsable efectúa el RFC completando el

formulario de la herramienta de gestión de cambios (ver figura 7).

33

Figura 7. Formulario de la herramienta de gestión de cambios de GabBot.

Fuente: CA Service Desk (herramienta de Gestión de tickets)

Los campos obligatorios son:

Proyecto (o cliente, se debe poder agregar o quitar sin problemas este campo).

Líder del Cambio – (Gerente de Responsable de su ejecución y validación).

Prioridad.

Fecha estimada de implementación.

Duración de implementación.

34

Categoría (Servidores, Storage, Redes, Microinformática etc.).

Grupo Resolutor (Redes, Sistemas Operativos, etc.).

Resolutor (Persona en encargada del cambio).

Resumen.

Descripción.

Justificación.

Consecuencias de no realizar el cambio.

Una vez completada la plantilla RFC, se requiere analizar el riesgo que implica realizar

la implementación del cambio. Cuando el RFC y la evaluación de riesgo estén completadas

se debe informar al analista de cambios.

Evaluación del riesgo de la empresa GabBot

Durante la etapa de registro de un cambio, el responsable del cambio, envía el resultado

de la evaluación del riesgo. La evaluación del riesgo se realiza para determinar el nivel de

riesgo del RFC. El riesgo del RFC está definido en 4 niveles que van, desde 1 siendo el

más crítico y hasta 4 el menos crítico. Para completar la evaluación de riesgo, responsable

del cambio contestará un cuestionario que asignará un puntaje, el cual resolverá el nivel

de riesgo. El cuestionario consiste en 15 preguntas que están resumidas en la Tabla 3.

35

Tabla 3. Cuestionario para evaluar el nivel de riesgo del cambio.

Cuestionario (respuestas para seleccionar)

1 ¿Cambio en un equipo productivo? 9 ¿Asociado a una transferencia de servicio?

2 ¿Cuántos grupos solucionadores se requiere en la implementación?

10 ¿Los CIS asociados pueden ser impactados?

3 Se requiere un proveedor de servicios contratado por GabBot

11 ¿Algún problema que se encuentre pendiente de resolver?

4 ¿Se necesita ventana de indisponibilidad del servicio durante las tareas de implementación?

12 ¿Inconvenientes de desempeño y/o capacidad sobre los equipos administrados?

5 ¿Se necesita roll back y éste genera ventana de indisponibilidad del servicio?

13 ¿Es posible que afecte a los niveles de servicio?

6 ¿Se cuenta con documentación operativa? 14 ¿Otros procesos que afecten la implementación?

7 ¿Fue exitoso el último cambio? 15 En referencia a la seguridad de la información: ¿Afectan las políticas de seguridad implementadas?

8 ¿Asociado a una desactivación de servicio?


Cuando se conoce el tipo de cambio y nivel de riesgo se entregará como resultado los

aprobadores para la solicitud de cambio.

El resultado de completar el RFC y el cuestionario dará como resultado lo siguiente: el

tipo de cambio, nivel de riesgo y matriz de aprobación.

Análisis de Cambios de la empresa GabBot

En esta etapa se describen los pasos siguientes a la etapa de registro de cambios, además

de algunas actividades que el analista de cambios ejecuta durante el tiempo que un registro

de cambio está aún abierto y pendiente por implementarse.

Luego que el usuario envió su solicitud de cambio al analista de cambios se realizan los

pasos siguientes:

El plan de trabajo deberá ser cargado en la herramienta o sistema de información

Service Desk e informar al analista de cambios para su revisión. El plan de trabajo

no necesariamente se entrega en simultáneo con el RFC, pero durante el transcurso

de la evaluación y planeamiento del cambio se debe enviar al analista de cambio.

36

Las aprobaciones se determinan luego de contar con la evaluación del riesgo y el

plan de trabajo.

Durante el tiempo que el RFC está siendo registrado, evaluado, planificado y aprobado

el analista de cambios, se está haciendo el seguimiento para que la información como el

RFC, plan de trabajo y las aprobaciones sean entregadas a tiempo y con información

adecuada para que su revisión por el CAB (comité de cambios).

Planificación de los cambios de la empresa GabBot

El plan de trabajo es completado por el administrador. El administrador para la planificación

de las actividades del plan de trabajo solicitará las facilidades al responsable del cambio

tales como: aprobaciones de ventanas de indisponibilidad, coordinación con otros

proyectos que puedan ser afectados, disponibilidad de especialistas y proveedores para

completar el plan de trabajo, así como reservar su participación en la implementación; y

otras actividades que sean necesarias para obtener un plan de trabajo adecuado. El

planificador de trabajo planifica las actividades, su secuencia y tiempos. Los requisitos para

contar con un plan de trabajo exitoso que mitigue los riesgos son los siguientes:

1. El plan de trabajo debe ser elaborado de acuerdo a los plazos establecidos por el tipo

de riesgo que califique el cambio. Este plan de trabajo es enviado por correo electrónico

al analista de cambios.

2. Las coordinaciones y confirmación de los grupos solucionadores (administradores y

especialistas) debe ser confirmadas por los Supervisores y/o jefes de cada uno de los

grupos solucionadores.

3. Las actividades en el plan de trabajo deben estar descritas de tal manera que el

estimado de tiempo que implica hacer cada una de ellas, además debe ser de fácil

reconocimiento.

4. Las actividades del plan de trabajo deben ser un resumen de lo que se va a ejecutar y

de su propósito.

5. Los planes de trabajo deben tener identificado el responsable de ejecutar cada una de

las actividades.

6. Los planes de trabajo deben tener identificado el sistema (hostname/IP) en el cual se

va a ejecutar cada una de las actividades.

37

7. Todas las fases del plan de trabajo deben ser completadas de manera adecuada. Si

alguna actividad no se requiere completar debe contar con la debida justificación

técnica. Las fases de un plan de trabajo se muestran en el Figura 8.

Figura 8. Fases de un plan de trabajo.


8. En la fase 3 posteriores, el administrador de sistemas debe completar las actividades

de verificación.

9. El plan de trabajo debe completar la hoja de cambios. En esta hoja de cambios el

administrador de sistemas debe indicar que diferencias se presentan en la

configuración, es decir, el estado anterior y posterior a la implementación.

10. Los tiempos de las actividades a ejecutarse deben contar con un margen adicional

como factor de seguridad.

11. Cuando el plan de trabajo se encuentre listo, el administrador de sistemas le hace

entrega de la versión final del plan de trabajo al responsable del cambio. El responsable

del cambio enviará la versión final al analista de cambios para el resguardo

correspondiente.

12. Toda la documentación adicional que ayude a sustentar el plan de trabajo como

aprobaciones de clientes, de jefes o gerentes de proyecto, confirmación de la

38

participación de especialistas o proveedores, confirmación de reprogramación de

respaldos, participación de clientes, entre otros, son también parte del plan de trabajo

y en consecuencia deben ser entregados para su resguardo y consolidación.

Biblioteca de infraestructura de tecnologías de la información (ITIL)

De acuerdo a Mariño (2017), “ITIL (por sus siglas en ingles de Information Technology

Infrastructure Library) o Biblioteca de Infraestructura de Tecnologías de la Información”, es

un conjunto de buenas prácticas orientado a procesos, para gestionar adecuadamente los

servicios de tecnología.

Una buena práctica es una mejor forma de realizar actividades previamente definidas y

las cuales son acogidas por la industria de TI.

ITIL es un compilado y fuente de mejores prácticas, lo cual significa que muchos

especialistas de gestión de servicios a nivel mundial han aportado sus conocimientos a lo

largo del tiempo con resultados favorables, es por ello que estas mejores prácticas son

acogidas y utilizadas por la comunidad de TI a nivel mundial.

ITIL un marco de gestión de servicios orientado a procesos.

Según Mariño (2017), “ITIL no solo ha ido coleccionando mejores prácticas sobre la gestión

de servicios de tecnología, sino que también ha transformado esas mejores prácticas y las

ha convertido en procesos formales de gestión” (pag.7).

ITIL consta de 26 procesos y 4 funciones de gestión de servicios de TI (Ver figura 9).

Figura 9. Procesos de la ITIL.

Fuente: Mariño (2017)

Fase de Estrategia

La fase de estrategia tiene como principal objetivo ayudar a los proveedores de

servicios/área de TI a definir el aspecto, posición, modelos y planes, que necesitan tener

en cuenta para cumplir con los objetivos del negocio planteados por los clientes, las cuales

deben de estar alineados a la estrategia del negocio.

Fase de Diseño

La fase de diseño tiene como principal objetivo definir las políticas, procesos y gobierno

de TI, con la finalidad de asegurar la calidad de servicio, optimización de costos y

satisfacción del cliente.

Fase de Transición

La fase de transición tiene como principal objetivo garantizar la calidad de los servicios

(nuevos, modificados o retirados) y que estén alineados a la estrategia del negocio.

Fase de Operación

La fase de operación tiene como principal objetivo ejecutar coordinadamente todas las

actividades de gobierno de TI, procesos, políticas, para gestionar y entregar los servicios

con los niveles acordados con el negocio.

Fase de Mejora Continua

La fase de mejora continua tiene como principal objetivo identificar las necesidades

cambiantes del negocio e implementar las mejoras de manera eficiente y que estén

alineadas a la estrategia del negocio.

41

OBJETIVOS

Objetivo general

Determinar la relación entre la gestión de cambios y los incidentes para minimizar su

impacto negativo en la empresa GabBot.

Objetivos específicos

Objetivo específico 1

Determinar la relación entre la gestión de cambios desde la fase de transición de ITIL y los

incidentes en la infraestructura de una empresa de servicios de tecnología de información.


Determinar la relación entre la gestión de cambios desde la fase de operación de ITIL y los

incidentes en la infraestructura de una empresa de servicios de tecnología de información.


Calcular el impacto que tiene la planificación de la gestión de cambios y los incidentes en

la infraestructura de una empresa de servicios de tecnología de información.

42

JUSTIFICACIÓN

Teórica

Desde el punto de vista teórico la presente investigación logrará mejorar la comprensión

entre las variables en estudio, por un lado permite el entendimiento de los fundamentos de

la Gestión de Cambios en TI, basado en la fase de transición y la fase de operación de

ITIL, además de evaluar su impacto en los incidentes de infraestructura de tecnología; por

lo que este estudio podrá ser una herramienta de ayuda en el proceso de aprendizaje en

materia de Servicios de TI, cuyos resultados podrán utilizarse para hacer la propuesta de

mejora a las empresas y para ser incorporado como conocimiento a las ciencias de la

educación ya que se estaría demostrando que el uso de las buenas prácticas de la gestión

del cambio, ayudan a minimizar los incidentes de tecnología además de poder considerarse

un aporte para enriquecer el debate académico que sustentan los procesos de ITIL.

Práctica

Esta investigación se realiza porque, es de gran importancia para la empresa demostrar

que existe una relación inversa entre la gestión de cambios y los incidentes de

infraestructura de tecnología, dado que permite mejorar los procesos de la gestión de

servicios, planificando adecuadamente los cambios a realizar, estableciendo tiempos

aceptables para realizar los cambios y crear un comité de cambios que pueda evaluar el

alcance de los cambios a ejecutar, todo esto permitirá disminuir el número de incidentes

de infraestructura de tecnología, además de mejorar los niveles acordados de solución de

los posibles incidentes generados, lo que tendrá un impacto significativo en las operaciones

de la empresa y en los costos de operaciones, minimizando los costos de la empresa,

mejorando el proceso de la gestión de servicio, logrando finalmente consolidar la imagen

de la empresa ante los trabajadores y los clientes.

La importancia de mejorar los procesos de gestión de cambios es la siguiente.

Mejorar el índice de incidentes que ocurren por cambios no planificados con debida

anticipación.

Registrar todos los incidentes y la manera como se solucionaron, alimentando así la

base de datos de conocimientos.

Mejorar la satisfacción de los usuarios finales.

43

Tener ahorros considerables en Mano de obra de re trabajos y costos de

equipamiento.

Segmentar los cambios por tipo de prioridad, basados en el impacto y urgencia de

negocio.

Mejora los acuerdos de niveles de servicios contratados (SLA´s)

Social

Desde la perspectiva social, el desarrollo de esta investigación se justifica debido a que

dará alternativas de solución a los problemas que se presenta en los clientes de la empresa

GabBot desde el año 2018 para adelante, dado que GabBot es una empresa que inicio sus

actividades en dicho año, permitiendo brindar servicios de tecnología integrada de calidad

y aumentando la eficiencia operativa en el uso de los recursos tecnológicos.

El desarrollo de la presente investigación ayudará a las organizaciones a evaluar la

factibilidad y los beneficios de implementar la gestión de cambios como una buena práctica

en sus operaciones.

La metodología que se aplicará al presente estudio, constituye un aporte a ser tomado

en cuenta para futuras investigaciones en empresas del sector de tecnología, estos aportes

generarán alternativas de mejora frente a los incidentes que se generan en la

infraestructura tecnológica de las empresas.

44

HIPOTESIS

Hipótesis general

La relación entre la gestión de cambios y los incidentes para minimizar su impacto negativo

en la empresa GabBot, es inversa y elevada.

Hipótesis específicas

Hipótesis específica 1

La relación entre la gestión de cambios desde la fase de transición de ITIL y los incidentes

en la infraestructura de una empresa de servicios de tecnología de información, es inversa

y elevada.


La relación entre la gestión de cambios desde la fase de operación de ITIL y los incidentes

en la infraestructura de una empresa de servicios de tecnología de información, es inversa

y elevada.


El impacto que tiene la planificación de la gestión de cambios y los incidentes en la

infraestructura de una empresa de servicios de tecnología de información, es inverso y

elevado.

MATRIZ DE CONSISTENCIA

RELACIÓN ENTRE LA GESTIÓN DE CAMBIOS Y LOS INCIDENTES PARA MINIMIZAR SU IMPACTO NEGATIVO EN LA EMPRESA GabBot

Problemas Objetivos Hipótesis Variable (S) Definición Conceptual Dimensiones Indicadores Marco metodológico

General ¿Cuál es la relación entre la gestión de cambios y los incidentes para minimizar su impacto negativo en la en la empresa GabBot?

General Determinar la relación entre la gestión de cambios y los incidentes para minimizar su impacto negativo en la empresa GabBot.

General La relación entre la gestión de cambios y los incidentes para minimizar su impacto negativo en la empresa GabBot, es inversa y elevada.

Gestión del cambio

Es una disciplina que tiene por objetivo de gestionar los cambios asegurando que se empleen métodos y procedimientos estandarizados más apropiados para el manejo eficiente y oportuno de todas las incidencias (Heflos, 2019).

Fase de transición de ITIL

Número de solicitudes recibidas

Metodología Cuantitativa y de Campo

Número de actividades planificadas

Paradigma Positivista

Tiempo estimado para realizar el cambio

Enfoque Cuasiexperimental y transversal

Específicas 1. ¿Cuál es la relación entre la gestión de cambios desde la fase de transición de ITIL y los incidentes en la infraestructura de una empresa de servicios de tecnología de información?

Específicas 1. Determinar la relación entre la gestión de cambios desde la fase de transición de ITIL y los incidentes en la infraestructura de una empresa de servicios de tecnología de información.

Específicas 1. La relación entre la gestión de cambios desde la fase de transición de ITIL y los incidentes en la infraestructura de una empresa de servicios de tecnología de información, es inversa y elevada.

Fase de operación de ITIL

Número de actividades ejecutadas

Método Analítico, sintético, deductivo, intuitivo

2. ¿Cuál es la relación entre la gestión de cambios desde la fase de operación de ITIL y los incidentes en la infraestructura de una empresa de servicios de tecnología de información?

2. Determinar la relación entre la gestión de cambios desde la fase de operación de ITIL y los incidentes en la infraestructura de una empresa de servicios de tecnología de información.

2. La relación entre la gestión de cambios desde la fase de operación de ITIL y los incidentes en la infraestructura de una empresa de servicios de tecnología de información, es inversa y elevada.

Tiempo de ejecución para realizar el cambio

Población 7 Servicios tecnológicos que la empresa GabBot presta a sus clientes

3. ¿Cómo se puede medir el impacto que tiene la planificación de la gestión de cambios y los incidentes en la infraestructura de una empresa de servicios de tecnología de Información?

3. Calcular el impacto que tiene la planificación de la gestión de cambios y los incidentes en la infraestructura de una empresa de servicios de tecnología de información.

3. Calcular el impacto que tiene la planificación de la gestión de cambios y los incidentes en la infraestructura de una empresa de servicios de tecnología de información, es inversa y elevada.

Incidencia Una incidencia es toda interrupción o reducción de la calidad no planificada del servicio. Pueden ser fallos o consultas reportadas por los usuarios, el equipo del servicio o por alguna herramienta de monitorización de eventos (ServiceTonic, 2019)

--- Número de incidentes antes de la implementación

Muestra 7 Servicios tecnológicos que la empresa GabBot presta a sus clientes

Número de incidentes después de la implementación

Costo promedio por incidente


MARCO METODOLÓGICO

Metodología

La metodología de la presente investigación fue cuantitativa, de campo, ya que la

recolección de los datos se hizo directamente en el lugar donde se produce el fenómeno.

Para Hernández, Fernández y Baptista (2014) la perspectiva cuantitativa de una

investigación debe tener una estructura que va paso a paso y pueda ser comprobada, su

orden es riguroso, pero flexible a reajuste de algunas de las etapas de este.

En lo que se refiere a una investigación de campo Arias (2012), considera que esta

reside en la recolección de datos directa de los sujetos estudiados, o del fenómeno donde

ocurren los eventos, sin aplicar ningún tipo de control a las variables, es decir, el

investigador obtiene la información sin modificar la condición de esta.

Paradigma

La presente investigación se basó en un paradigma positivista, ya que se aplicó el método

científico para abordar la problemática del aumento de incidentes generados en la

infraestructura de TI de los clientes de la empresa GabBot, su relación con la gestión del

cambio y comprobar que existe una relación inversa. En este sentido Ricoy (2006) citado

por Ramos (2015), establece que este paradigma abarca las investigaciones de tipo

cuantitativa, empírico-analítica, entre otras que tengan como finalidad la comprobación de

las hipótesis planteadas a través de estadísticas.

Enfoque

El enfoque de este estudio fue cuasi experimental y transeccional, debido a que se observó

la relación entre las variables: gestión del cambio y los incidentes, además los datos fueron

recolectados en un momento determinado.

Según, Palella y Martins (2012), el diseño cuasiexperimental es un procedimiento de

control parcial, fundamentado en la filiación de factores que podrían tener injerencia en la

validez interna y externa del mismo.

De la misma manera, los autores antes mencionados consideran que el estudio

transeccional busca la descripción de las variables analizando su ocurrencia e interacción

en un determinado momento, sin manipulación de las mismas.

47

Método

Esta investigación se aplicó el método científico: analítico, sintético, deductivo e inductivo.

Seguidamente, se explican cada uno de ellos en particular:

Método científico: Se utilizó como base fundamental para determinar las propiedades

del objeto de estudio. Las cuales permitirán adquirir nuevos conocimientos,

definiciones, hipótesis, variables que proporcione la información para poder realizar el

trabajo investigativo. Según Arias (2012), “es un conjunto de técnicas y procedimientos

que permiten la formulación y la resolución de problemas de investigación, a través de

las pruebas de hipótesis” (p. 23)

Método analítico: Mediante este método se analizó la información conceptual, de la

misma manera, se elaboró un análisis de la relación entre la fase de transición de ITIL

y la fase de operación con los incidentes en la infraestructura de una empresa de

servicio TI. Según Gómez (2012) este método radica en descomponer el todo en sus

partes, con el fin de observar el medio y los efectos del fenómeno.

Método sintético: Permitió organizar todo el conocimiento investigado en forma

sintetizada a través de un proceso progresivo y sistemático, para poder obtener un

buen resultado investigativo. Para Sabino (1992), existe un momento donde el

investigador debe ordenar y sistematizar sus inquietudes, manifestar sus interrogantes

y elaborar organizadamente los conocimientos que establecen su punto de partida,

revisando y asimilando lo que se ya se conoce respecto al problema que se ha

planteado.

Método deductivo: Con el método deductivo se pudo extraer las conclusiones sobre

la relación entre la gestión del cambio y los incidentes, para minimizar su impacto

negativo en la empresa GabBot. Para Gómez (2012), este método es el procedimiento

racional que va de lo general a lo particular. Permitiendo a partir de datos generales

como definiciones, normas conceptos aceptados como válidos y después de un

razonamiento lógico, establecer conclusiones.

Método inductivo: Mediante el método inductivo se realizó una exploración para el

planteamiento del problema, el cual fue necesario para dar inicio a la investigación. De

acuerdo a Gómez (2012), es un procedimiento de sistematización que, a partir de

resultados particulares basados en investigaciones previas, intenta encontrar posibles

relaciones generales que fundamenten al presente estudio.

48

Variables

Independiente

Gestión del cambio

Es una disciplina que tiene por objetivo de gestionar los cambios asegurando que se

empleen procedimientos, métodos apropiados y estándares para la gestión oportuna y

eficiente de todos las incidentes (Pacheco, 2017).

Dependiente

Incidencia

Una incidencia es toda interrupción o reducción de la calidad no planificada del servicio.

Pueden ser fallos o consultas reportadas por los usuarios, el equipo del servicio o por

alguna herramienta de monitorización de eventos (ServiceTonic, 2019).

Población y muestra

Población

Para esta investigación se tomaron en consideración todos los servicios tecnológicos que

la empresa GabBot presta a sus clientes, el cual asciende a 7 servicios, lo cuales se

describen en la tabla 4.

Tabla 4. Servicios tecnológicos prestados por la empresa GabBot a sus clientes.

Servicios tecnológicos Descripción de Servicios

Aplicaciones SAP Sistema empresarial core de negocio

CECOM Operaciones Centro de comando, primera línea para solucionar incidentes

So y aplicaciones Sistemas operativos y aplicaciones de soporte

NOC Centro de operaciones de redes e internet

Backups y restores Respaldos de información critica

SOC Centro de operaciones de seguridad

Monitoreo Evaluación de eventos informáticos


Al respecto, Tamayo (2003) define la población como la totalidad de “un fenómeno de

estudio, incluye la totalidad de unidades de análisis o entidades de población que integran

dicho fenómeno y debe cuantificarse para un determinado estudio, integrando un conjunto

N de entidades que participan de una determinada característica” (p. 176).

49

Muestra

Dado que la población a estudiar fue accesible para la realización del estudio se tomó como

muestra su totalidad, es decir se evaluó el número de incidente que ocurrieron en cada uno

de los servicios tecnológico que presta la empresa GabBot, desde el mes de mayo hasta

octubre del año 2019, basado en lo descrito por Arias (2012), cuando la población por el

número de unidades que la completan, resulta accesible en su totalidad, no es obligatorio

extraer una muestra. En consecuencia, se puede investigar u obtener datos de toda la

población objetivo.

La selección de la muestra fue de tipo no probabilístico e intencional, como lo establece

el autor antes mencionado “en este caso los elementos son escogidos con base en criterios

o juicios preestablecidos por el investigador” (p.85).

Unidad de análisis

Los servicios tecnológicos prestados por la empresa GabBot.

Instrumentos y técnicas

Instrumentos

Para la recolección de los datos de este estudio, se empleó como instrumento la ficha de

registro donde se recolectó la información del tipo de cambio efectuado, el número de

incidentes totales, el número de incidentes solucionados y el tiempo de duración de las

incidencias atendidas.

También se utilizó el cuestionario, con preguntas cerradas y con escala de estimación,

basado en un cuestionario sobre el compromiso que tiene los empleados de realizar el

trabajo de la fase de transición y operación antes y después de la implementación de la

gestión del cambio.

En ese sentido, un instrumento de recolección de datos es cualquier recurso, sea

dispositivo o formato que se utiliza para obtener, registrar y almacenar la información, de

acuerdo con lo descrito por Arias (2012).

Técnicas

Como técnicas de recolección de información se utilizaron las que se describen a

continuación:

50

La observación directa en la que se hizo una revisión de los manuales de procedimiento

para realizar los procesos de cambio en las infraestructuras tecnológicas de los servicios

de TI. En la observación directa, para Palella y Martins (2012), el investigador se sitúa en

el lugar donde sucede el evento que se desea estudiar.

La encuesta es otra de las técnicas que se utilizó para la recolección de los datos, según

Arias (2012) la encuesta es una técnica que tiene como propósito obtener información de

una muestra de sujetos acerca de sí mismos, o en relación con una situación específica.

Procedimiento y método de análisis

Procedimiento

Los pasos a seguir para la comprobación de las hipótesis planteadas para la presente

investigación fueron los siguientes:

Se planteó las hipótesis de investigación, tanto la general como las específicas.

Se especificó el nivel de significancia, tomando como referencia lo propuesto por

Sáez (2012) “se rechazará la hipótesis nula en favor de la alternativa cuando el

p-valor asociado al valor que tome DN sea inferior a 0.05”.

Se determinó el tamaño de la muestra y el grupo experimental de investigación.

Se determinó la prueba estadística a utilizar considerando los resultados del test de

Kolgomorov Smirnov que indican si existe o no una distribución normal.

A partir de ello se utilizaron las estadísticas paramétricas o no paramétricas.

Para probar la hipótesis de la presente investigación se eligió el diseño cuasi

experimental. Para esto se manipuló la variable independiente (Gestión del cambio)

para luego ver el efecto en la variable dependiente (Incidentes).

Se recolectaron los datos del pre y post test y se llevaron a una base de datos en

el paquete estadístico SPSS para determinar el coeficiente de correlación.

Método de análisis

El análisis de datos se realizó con la utilización del software SPSS V23 para el tratamiento

estadístico de los datos, por otro lado, para el análisis de las estadísticas recabadas de la

51

empresa se utilizó el método analítico, además de la comprobación de hipótesis con la

información obtenida de la gestión del cambio y el número de incidentes.

En este contexto, Hernández et al (2014), explica que las técnicas de análisis de datos

se refieren a que: “los datos son recogidos a través cuestionarios, observación u otros

métodos para luego ser estudiados y poder dar respuestas preguntas de investigación y

comprobar las hipótesis planteadas.

Una vez aplicadas las técnicas de recolección de datos en la presente investigación, los

resultados se desarrollaron mediante herramientas estadísticas, a través de un sistema de

tabulación, en este sistema, los datos se agruparán por categorías asociadas a las

variables estudiadas. En cuanto a la representación gráfica, se aplicó mediante gráficos de

torta, los cuales facilitarán el procesamiento de los mismos para un mejor análisis e

interpretación de los mismos, utilizando la lógica matemática o estadística.

52

RESULTADOS

En la actualidad, la gestión del cambio llevada a cabo por la empresa GabBot, viene

presentando inconvenientes, en relación a que se presentan un número elevado de

incidentes cuando ocurre el proceso del cambio, originando retrasos importantes en las

actividades, lo que originan un retaso en el cierre de las solicitudes de cambios en los

sistemas de TI.

Por lo cual, es necesario realizar una propuesta de mejora de la gestión del cambio

actual, donde se hará un rediseño del proceso actual de la gestión del cambio, tomando

como base la fase de transición y de operación de la metodología ITIL V3.

El proceso general de la Gestión de Cambios propuesta tendrá las siguientes etapas:

Tabla 5. Procesos de la gestión del cambio propuesto para la empresa GabBot.

Código Procesos

1 Registro de Cambios (RFC o Request For Change)

2 Evaluación, planificación y aprobación

3 Ejecución

4 Validación de la implementación y cierre

5 Supervisar y comunicar

6 Métrica

7 Descripción de las actividades

8 Gestión y mejora del proceso


Cada uno de los procesos listados, serán describen a continuación:

1. Registro de Cambios (RFC o Request For Change)

El registro de solicitud de cambios, se mantendrá con la plataforma de Tickets de la

empresa GabBot la cual cuenta con una interface con campos que deben ser llenados por

el solicitante.

53

Tabla 6. Descripción de las características del cambio en la empresa GabBot.

N° Ítems Descripción

1 Proyecto Nombre del proyecto o cliente. Es un campo de llenado obligatorio.

2 Líder del cambio Se debe mencionar el nombre del Gerente de Responsable de su ejecución y validación. Es un campo de llenado obligatorio

3 Nombre Oracle del proyecto

Se debe colocar el nombre que tiene el proyecto en el sistema de gestión de base de datos de tipo objeto-relacional.

4 Código ALP

5 Jefe de proyecto

6 Estado

7 Tipo de cambio Breve descripción. Obligatorio

8 Prioridad Obligatorio

9 Riesgo asignado

10 Servicio

11 Fecha de registro

12 Fecha estimada de implementación

13 Duración de implementación

Obligatorio

14 Impacto

15 Urgencia


Tabla 7. Descripción de los datos del cambio en la empresa GabBot.


1 Categoría

2 Creador

3 Grupo resolutor

4 Resolutor

5 Momento de cancelación

6 Resultado de implementación-Resolutor.

7 Resultado de implementación-líder de cambio


54

Tabla 8. Descripción de los detalles del cambio en la empresa GabBot.


1 Resumen del cambio

2 Descripción del cambio

3 Justificación del cambio

4 Consecuencia de no realizar el cambio.

5 Fecha de resolución.

6 Fecha de cierre.


1. El responsable del cambio, solicita el cambio (RFC) completando el

formulario de la herramienta de gestión de cambios.

2. Una vez completada la plantilla RFC (Request For Change), se requiere

analizar el riesgo que implica realizar la implementación del cambio.

3. Cuando el RFC y la evaluación de riesgo estén completadas se debe

informar al analista de cambios.

4. La orden de cambio contiene otro documento necesario para su atención

que es el Plan de Trabajo.

2. Aprobación del cambio

Para la aprobación del cambio a realizar, se debe clasificar de acuerdo al tipo: cambio

de emergencia, normal y excepcionales.

Cambio de emergencia: Este tipo de cambio es de máxima prioridad, que es

empleado para dar solución a un incidente que afecta la disponibilidad o nivel de

servicio o un requerimiento solicitado por el cliente.

Cambio normal: este es el cambio que es planificado para mejorar los servicios de

tecnología de los clientes a solicitud de estos, pero sin ninguna prioridad para su

ejecución.

Cambio excepcional: Es cuando los tiempos de evaluación, planificación y

aprobación son menores a los establecidos para un cambio normal. Este tiempo se

calcula entre la fecha de registro de la solicitud de cambio y la fecha esperada de su

implementación.

55

Ahora bien los cambios normales, poseen una clasificación las mismas que son

propuestas por Villaverde (2016): crítico, mayor, medio, menor y rutinario. Estos son

evaluados de acuerdo al nivel de complejidad y su influencia en la organización, los cuales

se describirán a continuación:

Crítico: Estos cambios son los que tienen el valor de riesgo más elevado, además

del potencial de una influencia sobre los servicios de TI. Estos cambios necesitan

un tiempo mayor de planificación, además de requerir la intervención de diferentes

áreas. El tiempo promedio para la planificación es de 14 días.

Mayor: Estos cambios tienen un valor de riesgos elevado y una alta influencia en los

servicios de TI, este tipo de cambio requiere una planificación de 8 a 13 días.

Medio: Estos cambios tienen un valor moderado de riesgo y un nivel de influencia

baja en los servicios de TI, este tipo de cambio requiere una planificación de 4 a 7

días.

Menor: Estos cambios tienen un riesgo bajo y una influencia baja en los servicios de

TI, la planificación de este trabajo requiere 1 a 3 días.

Rutinario: Estos cambios son procedimientos que están establecido por la

organización y se realizan durante el mantenimiento de las actividades diarias, estas

no tienen una influencia en los servicios de TI.

Ahora bien, para categorizar el tipo de cambio normal, se deberá realizar la evaluación

de acuerdo a los ítems de la tabla 9 y valorado con la tabla 10.

Tabla 9. Evaluación de los cambios de tipo normal.

Ítems Respuesta Valor

¿Cuál es el número de usuarios afectados?

Más de 150 5

De 100 a 150 4

De 50 a 150 3

1 a 49 2

Ninguno 1

¿Cuántos Grupos Solucionadores se requiere en la implementación?

3 o más grupos solucionadores 5

2 grupos solucionadores 4

1 grupo solucionador 3

2 personas 2

Una persona 1

¿Cuánto es el tiempo medio de solución?

De 9 a 14 días 5

5 a 8 días 4

De 2 a 4 días 3

1 día 2

56

Menos de 1 día 1

¿Se necesita ventana de Indisponibilidad del servicio durante las tareas de implementación?

Con 3 ventanas 4

Con 2 ventanas 3

Con 1 ventana 2

Sin ventana 1

¿Cuánto tiempo demora en

regresar a la versión anterior?

Más de 2 horas 4

De 1 a 2 horas 3

1 hora 2

Se puede regresar con facilidad 1


Tabla 10. Matriz de riesgos de cambios normales.

Valor obtenido Clasificación de riesgo

5-8 Rutinario

9-12 Medio

13-15 Menor

16-19 Mayor

20-23 Crítico


Evaluación de riesgos de la solicitud del cambio

El cuestionario consiste en 15 preguntas que están resumidas en la Tabla 3, durante la

etapa de registro de un cambio, el responsable del cambio envía el resultado de la

evaluación del riesgo para completar su evaluación, el responsable del cambio contestará

un cuestionario que asignará un puntaje, el cual resolverá el nivel de riesgo.

La evaluación del riesgo se realizará para determinar el nivel de riesgo del cambio. El

riesgo del cambio está definido en 4 niveles, como se muestra en la figura 10.

57

Figura 10. Nivel de riesgos de la evaluación de cambios.


Cuando se conoce el tipo de cambio y nivel de riesgo se entregará como resultado los

aprobadores para la solicitud de cambio.

El resultado de completar el RFC y el cuestionario dará como resultado lo siguiente: el

tipo de cambio, nivel de riesgo y matriz de aprobación.

Después de categorizar el tipo de cambio se debe realizar el análisis del cambio

solicitado, por parte del analista de cambios, este es un proceso que se efectúa después

del registro del cambio. Sin embargo, existe actividades que el analista de cambios debe

ejecutar durante el tiempo que un registro de cambio está aún abierto y pendiente por

implementarse.

Luego que el usuario envió su pedido de cambio al analista de cambios se realizan los

pasos siguientes:

1. El Plan de Trabajo se debe cargar en la herramienta o sistema de información

Service Desk e informar al analista de cambios para su revisión. El Plan de Trabajo

no necesariamente se entrega en simultáneo con el RFC, pero durante el transcurso

de la evaluación y planeamiento del cambio se debe enviar al analista de cambio.

2. Las aprobaciones se determinan luego de contar con la evaluación del riesgo y el

plan de trabajo.

58

Durante el tiempo que el RFC está siendo registrado, evaluado, planificado y aprobado

el analista de cambios está haciendo el seguimiento para que la información como el RFC,

Plan de Trabajo y Aprobaciones sean entregadas a tiempo y con información adecuada

para que su revisión en el Comité de Cambios sea satisfactoria.

Plan para realizar el cambio

El plan de la ejecución del cambio solicitado debe contener las consideraciones que se

muestran en la tabla 11, también deben contener la información general (ver tabla 12) y

estar dividido en las siguientes etapas: tareas previas, tareas en implementación, tareas

posteriores, tareas de Roll Back (ver Anexo 1).

Tabla 11. Consideraciones Restores.

Formato de requerimiento de restauración solicitado al centro de operaciones (COT)

Datos Detalle del requerimiento

Cliente o código del proyecto (ALP)

Fecha / hora del inicio de la solicitud

Administrador de sistemas solicitante

Jefe de proyecto encargado

Nombre del contacto (cliente/usuario)

Correo electrónico del contacto

Número de celular, personal y/o anexo

Servidor origen de la restauración

Ruta origen de la restauración

Tipo de restore: filesystem o integracion (oracle, sap, exchange, mailbox, sql, sharepoint, db2, vmware, … entre otros)

Servidor destino para la restauración

Ruta destino donde se debe restaurar

Fechas que se necesita restaurar


59

Tabla 12. Información general del cambio.

DC F 18 Plan de trabajo

Rev. 4 Fecha efectiva Pág. 1 de 1

Plan de Trabajo

Proyecto

Breve Descripción

Responsable del Plan de Trabajo

Alcance

¿Se está monitoreando?

¿Se encuentra alineado a la política de respaldos?

Registro (Cambio)


Aprobación del cambio

La aprobación del cambio se hace basado en la prioridad y la categoría, el cambio será

canalizado a un determinado proceso para su evaluación y aprobación:

El gestor de cambios será el aprobador de los cambios tipo estándar.

EL comité de cambios será el aprobador de los cambios normales y normales con

alta prioridad.

Todos los cambios de emergencia deben ser evaluados y aprobados por el comité

de cambios (mínimo dos integrantes).

Aprobación de cambios excepcionales

Este tiempo se calcula entre la fecha de registro de la solicitud de Cambio y la fecha

esperada de implementación del mismo.

Los Cambios Excepcionales se dan:

Cuando el cliente por necesidad de negocio requiere con urgencia implementarlos.

En este caso, los riesgos de reducir la planificación son asumidos por el jefe y/o

gerente de proyecto. Estos cambios deben contar con un acta de aceptación de

riesgo firmada por parte del cliente, la cual se encuentra en el Service Desk

(información del cambio\carta de aceptación de riesgo).

Cuando GabBot lo solicita. Estos cambios deberán contar con la aprobación del

60

gerente responsable, para todos los niveles de riesgo.

Las aprobaciones de los cambios excepcionales son gestionadas por el jefe o gerente

de proyecto o supervisor y son enviadas al gestor de cambios vía correo electrónico para

su resguardo.

Aprobación de cambios de emergencia.

En el caso de un Cambio de Emergencia, éste se solicita cuando el Cambio es parte de la

solución de un incidente que afecta la disponibilidad o nivel de servicio.

Un cambio de emergencia es solicitado después de que el gerente de proyecto o

incident manager, necesita elaborar una implementación para solucionar el incidente crítico

o problema que va a afectar la continuidad del servicio.

Luego de que el gerente de proyecto o incident manager cuenta con una solución

permanente o temporal y ha elaborado su Plan de Trabajo, entonces procede a solicitar las

autorizaciones para este cambio de emergencia por medio de correo electrónico

notificando previamente vía telefónica, la aprobación del mismo debe quedar registrada.

Las aprobaciones que se necesitan para cualquier cambio de emergencia se encuentran

descritas en la tabla 13.

Tabla 13. Requisito de aprobación de cambio de emergencia.

Tipo Riesgo Jefe de Grupos

Solucionadores

Gerente de Servicios de Data Center o

Incident Manager

Emergencia Crítico


Luego que se cuente con las aprobaciones correspondientes entonces se procede a

implementar el Cambio de Emergencia.

61

Operación del Comité de Cambios.

El comité de cambios (ver Anexo 2) es el último punto de aprobación y sus funciones son

las siguientes:

1. Tener una visión de todos los cambios que se han solicitado durante la semana.

2. Priorizar y comprender qué cambios se requieren implementar, en tal sentido los

cambios identificados como riesgo 1 y 2 son los más críticos por revisar.

3. Evaluar la calidad de los planes de trabajo de los cambios 1, 2 y 3, así como

recomendar ajustes menores que aseguren la implementación con el menor riesgo

posible.

4. Identificar aquellos cambios (RFC, aprobaciones y planes de trabajo) que no reúnen

las condiciones para su corrección y posterior ejecución.

5. Evaluar la carga de pedidos actuales y a futuro.

6. Identificar los cambios que están asociados a una entrega de servicio, desactivación

y/o transferencia de servicio.

7. Identificar puntos de mejora para ser posteriormente analizados e incorporados para la

mejora del proceso.

8. Resumir las operaciones realizadas por los cambios de emergencia para mejorar las

actividades ante problemas o incidentes críticos que se presentan de manera súbita.

9. Identificar los cambios excepcionales, evaluarlos y aprobarlos para su implementación.

Este punto implica reprogramar actividades.

10. Identificar las causas de los cambios cancelados.

11. Identificar las causas de los cambios no satisfactorios.

El Comité de Cambios tiene un tiempo promedio de duración de 02 hrs, el cual concluye

en un Acta de Reunión y la aprobación final de los cambios que van a atenderse durante

esa semana.

62

3. Ejecución del cambio

Tratamiento de incidentes durante la implementación de un cambio.

Si durante la implementación de un cambio se produce un incidente o problema

entonces se procede a evaluar si la solución se puede realizar dentro de los tiempos que

permite el factor de seguridad del plan de trabajo, para lo cual se informa al jefe de proyecto

que confirmará si se continúa con las actividades programadas. Si los tiempos exceden al

plan de trabajo entonces el jefe o gerente de proyecto procede a cancelar el cambio

indicando los motivos mediante un correo electrónico al analista de cambios. Si las

actividades requieren deshacer los cambios ya implementados, se ejecutará las

actividades descritas en el roll back.

Todos los cambios sin importar el riesgo, sobre equipos compartidos y que afecte a dos

clientes o más se deben realizar los días sábados a partir de las 11pm hasta el domingo

6am.

Si alguna de las condiciones descritas en el

Anexo 3 se incumple por alguna emergencia o excepción, esta deberá ser aprobada

por el gerente de servicios datacenter, el gerente de línea o incident manager.

Regularización de un cambio de Emergencia.

Luego de atendido un cambio de emergencia se requiere regularizar la información

siguiente:

Solicitud RFC: El analista de cambios envía un correo al jefe o gerente de proyecto o

supervisor de facilities para que complete el RFC señalando en el tipo de cambio que es

una emergencia.

Análisis de Riesgo: El jefe o gerente de proyecto o supervisor de facilities procede a

completar el RFC además de realizar el análisis de riesgo completando el cuestionario.

Aprobaciones: El jefe o gerente de proyecto o supervisor de facilities solicitan las

aprobaciones para evidenciar la autorización que fue otorgada como emergencia.

Plan de Trabajo: El jefe o gerente de proyecto o supervisor de facilities solicitan al

Administrador de Sistemas que actualice el Plan de Trabajo ejecutado en el Cambio de

63

Emergencia. Cuando este Plan de Trabajo esté documentado entonces se envía por correo

electrónico al Analista de Cambios para resguardar la evidencia.

4. Validación de la implementación y cierre del cambio

Una vez concluida la atención del cambio se requiere realizar los pasos siguientes:

Cambios Implementados:

1. El resolutor del cambio luego de finalizada la implementación completa el formulario

en la herramienta de gestión, colocando el resultado de la implementación.

2. El analista de cambios verifica que la hoja de cambios incluida en el plan de trabajo

se encuentre debidamente completada. Si la hoja de cambios presenta alguna

observación entonces se solicitará al administrador de sistemas completar la

información y procede a cambiar el estado del cambio a “Pendiente Validación”.

3. El Líder de cambio deberá completar el resultado de la implementación y proceder

al cierre de la orden de cambio.

Resultados de un cambio por parte del resolutor y líder de cambio:

- Implementado exitoso: Con este resultado podemos determinar que el cambio logro

su objetivo.

- Implementado Fuera de Plan: Este resultado hace referencia a aquellos cambios

que requieren de actividades adicionales o disminución de actividades al plan de

trabajo.

- Implementado Fuera de Tiempo: Este resultado hace referencia a aquellos cambios

que logran su objetivo fuera del tiempo determinado que se indica en las actividades

del plan de trabajo.

- Implementado Parcial: Hace referencia a aquellos cambios que no llegaron a

culminarse en su totalidad.

- Implementado. Presenta Problemas: Este resultado hace referencia a aquellos

cambios que presentan un problema o inconveniente durante la implementación.

- No Implementado con roll back: Hace referencia a aquellos cambios en los cuales

no se completaron las tareas de implementación y requieren de la ejecución de las

64

tareas de roll back.

- No Implementado sin roll back: Hace referencia a aquellos cambios que no

ejecutaron las tareas de implementación y por lo tanto no requieren de roll back.

Cambios Cancelados:

a. El cambio puede cancelarse si el RFC enviado al analista de cambios presenta campos

vacíos y su actualización no ha sido atendida durante las 24hrs de enviada la solicitud.

b. El cambio puede ser cancelado si el RFC solicitado está fuera del alcance del servicio.

c. El cambio se cancela si durante la implementación éste no cumple con los tiempos

establecidos.

d. El cambio puede ser cancelado en caso el comité de cambios identifique que el plan

de trabajo presenta inconsistencias.

e. El cambio puede ser cancelado en caso el comité de cambios identifique varios trabajos

críticos programados en el mismo período de tiempo.

f. El cambio de excepción se cancela si es que no cuenta con las aprobaciones

correspondientes hasta la hora de reunión del comité de cambios que revisa los planes

de trabajo programados para esa semana.

g. El cambio puede ser cancelado en caso se postergue más de tres veces.

h. El cambio de emergencia se cancela si no cuenta con la aprobación del comité de

emergencia.

i. Los estados para los cambios cancelados pueden ser los siguientes, de acuerdo a lo

que corresponda:

“Cancelado por Incumplimiento del Proceso”

“Cancelado por Cantidad de Postergaciones”

“Cancelado por Cliente”

“Cancelado por Proveedor”

“Cancelado por Falla de Registro”

65

“Cancelado por Encuesta de Riesgos”

5. Supervisar y comunicar

Ahora bien, al final de la implementación del cambio se debe notificar al gestor de cambio

la finalización del mismo, indicando el resultado del cambio y las pruebas; los incidentes

que pudieran haber ocurridos y si se cumplió con la ventana de tiempo.

Mientras que el gestor del cambio, debe realizar la supervisión de todas las actividades

ejecutadas de acuerdo al reporte de los operadores del cambio.

6. Responsabilidades y matriz RACI

La matriz RACI, dentro de la gestión de cambios tiene los siguientes roles:

Promotor del Cambio

Es la persona encargada de iniciar un requerimiento de cambio basado en alguna

necesidad de negocio o para solucionar un incidente. Una vez detectada la necesidad debe

iniciar el procedimiento de gestión de cambios a través de un RFC.

Los promotores o gestores de cambio podrían ser las siguientes:

El promotor del cambio o gerente de proyecto: una vez detectada la necesidad del

cambio deberá crear el RFC en la herramienta de gestión de tickets para iniciar el proceso

Personal técnico de TI: durante la fase de transición del servicio el personal de TI puede

hacer los requerimientos de cambio de manera directa, ya que en esta fase el servicio aún

no está en producción, si no en implementación.

Los clientes pueden canalizar sus requerimientos de cambio a través de los gestores de

proyecto quien analizara los acuerdos de niveles de servicio para hacer la planificación del

cambio y la coordinación con las áreas internas de GabBot para canalizar la disponibilidad

de los recursos.

Gestor del Cambio

Dentro de la fase de operación del servicio existe un gestor de cambios quien deberá

apoyar y asesorar al ejecutor del cambio en la gestión para asegurar que se cumplan los

acuerdos de niveles de servicio (SLA).

66

El rol de gestor de cambio podrá ser un jefe o supervisor de las áreas técnicas

responsables de la ejecución de los mismos.

Responsable del Cambio

El responsable del cambio o jefe de proyecto deberá definir, implantar los hitos de control

del plan de trabajo y las coordinaciones con todas las áreas técnicas involucradas en el

cambio a ejecutar, el cual debe contar con la autoridad o jerarquía necesaria; con la

finalidad de garantizar la disponibilidad de los medios y recursos, para de esta manera

asegurar el éxito en la ejecución del mismo.

Comité de Cambios (CAB)

El CAB (Change Advisory Board o comité de cambios) es un grupo de especialistas

experimentados en la parte técnica, gestión, riesgos, con la autoridad suficiente para poder

revisar, aprobar o rechazar un RFC, basado en temas de negocio y/o técnicos.

En el comité de cambios se revisan los RFC que tienen un alto impacto dentro de la

organización o que los riesgos sean altos. Habitualmente el comité de cambios será

requerido para la valoración de cambios de alto impacto (Por ejemplo, los FRC tipo 1 y 2).

El CAB tiene un responsable de su ejecución que con frecuencia es el gestor de cambios

quien convoca y dirige dicha reunión. Debe asegurar la participación de los especialistas

adecuados para los tipos de cambio.

Responsable de cada torre de servicio (sistemas operativos, bases de datos,

infraestructura, aplicaciones, entre otros).

Responsables de la gestión de proyectos (gerente y jefe de proyecto)

Usuario o clientes impactados por el cambio.

Administradores y Especialistas Técnicos

En GabBot existen las torres de servicio o áreas técnicas, quienes tienen administradores

y personal técnico especializado (sistemas operativos, bases de datos, infraestructura,

aplicaciones, entre otros), en la ejecución de estos cambios.

Responsable del Servicio

Tiene como responsabilidad garantizar que los acuerdos de niveles de servicio se cumplan,

67

estos acuerdos o SLA´s deben estar formalizados contractualmente.

Matriz de Responsabilidades

La matriz de responsabilidades se presentar en la tabla siguiente, en el cual se identifican

claramente las actividades a desempeñar por cada rol en el procedimiento de la gestión

del cambio.

Tabla 14. Matriz RACI

Código Actividades de la gestión del cambio R

esponsa

ble

del

Cam

bio

Gesto

r del

Cam

bio

Com

ité d

e

Cam

bio

s

Pro

mo

tor

del

Cam

bio

Adm

inis

tradore

s

y E

specia

lista

s

Técnic

os

1 Hacer RFC (requerimiento de cambio) R R I

2 Evaluar, planificar y aprobar la implementación

A/R R R I C

3 Gestionar el desarrollo y pruebas A/R I R

4 Gestionar la implementación A/R I R

5 Validar y analizar implementación A/R I R

6 Gestionar el rollback en caso sea necesario

A/R I I I R

7 Asegurar que se asignen los estados del cambio en la herramienta de gestión de tickets.

A/ R A/ R I R

9 Supervisar y mantener la comunicación entre el equipo interno y el cliente

A R I I

10 Analizar las métricas y SLA´s A/R I

11 Evaluar y proponer mejoras del proceso

R I

R = responsable directo. A = responsable último o indirecto, puede delegar, debe supervisar. C = Consultar antes de hacer. I = Informar después de hacer


7. Métricas

Para evaluar la implementación de los cambios, es necesario tener métricas que nos den

una rápida evaluación del proceso de gestión de cambios, a continuación, se proponen

algunos indicadores.

Numero de RFC solicitados al mes.

Numero de cambios ejecutados con éxito al mes.

68

Numero de cambios no ejecutados o rechazados VS los solicitados al mes.

8. Descripción de las actividades

En esta sección se presentan la simbología a utilizar para los flujogramas de la propuesta

de gestión del cambio, así como los flujogramas de los procesos: gestión del cambio,

gestión del cambio excepcional, gestión del cambio normal y gestión del cambio de

emergencia.

Tabla 15. Descripción de la simbología de los flujogramas de proceso.

Símbolos Nombres del símbolo

Descripción

Inicio/Fin Indicadores de inicio y fin de proceso.

Actividad Representa ejecución dentro de un proceso.

Decisión Evaluar condición o alternativas dentro de un proceso.

Conector de actividades

Conectar dos actividades o puntos del mismo flujograma.

Conector de

página Conectar dos actividades o puntos de diferentes flujogramas.


Proceso de gestión del cambio

Usu

ario

Áre

a T

I

Fase

InicioRegistro de

cambio

Evaluación de la

solicitud de

cambio

Solicitud

aceptada

Rechazo solicitud

Tipo de cambio

No

Si

emergencia

Normal

Excepcional

Figura 11. Proceso de gestión del cambio.

69


Sub proceso Cambio Excepcional

Áre

a T

I

Fase

Registrar solicitudAsignar

especialista

Planificar

actividades y

fechas de cambio

Ejecutar cambio

Figura 12. Sub Proceso de cambio excepcional.


Sub proceso Cambio Normal

Áre

a T

I

Fase

Registrar solicitud¿Esta

conforme?

Planificar

actividades y

fechas de cambio

Evaluar solicitud

de cambio

No

Si

Asignar

especialista

Planificar

actividades y

fecha de cambio

¿Se aprueba?

No

Si

Aprobar el cambioImplementar el

cambio

Figura 13. Sub Proceso de cambio Normal.


70

Sub proceso Cambio EmergenciaÁ

rea T

I

Fase

Registrar solicitud

de cambio

Asignar

especialista

Planificar

actividades y

fechas de cambio

¿Se aprueba?

No

Aprueba el cambio

Si

Implementar el

cambio

Figura 14. Sub Proceso de cambio de emergencia.


7. Gestión de mejora continúa

La mejora continua está presente siempre en los procesos de ITIL de manera iterativa, con

la finalidad de identificar, planear y corregir las posibles brechas en el servicio de la

siguiente manera.

Registrar detalladamente los cambios a realizar.

Hacer el seguimiento de efectividad de los cambios realizados.

Informar el estado de los cambios, para saber los pendientes de ejecución.

En el comité de cambios realizara el feedback de los cambios implementados y

documentarlos para tenerlos como lecciones aprendidas para los próximos cambios

a ejecutar, los cuales formaran parte de la gestión del conocimiento.

Prueba piloto

Finalizada la fase de investigación, se procedió a implementar la prueba piloto de la gestión

del cambio en los servicios de TI que presentaron incidentes en el año 2018 para la

empresa, siendo un total de 7 servicios, como se muestra en la tabla 4.

El primer paso para esta prueba piloto, fue la capacitación del personal encargado de la

gestión de cambios (5 personas). Para lo cual se planificó una capacitación de 7 semanas

(9 horas de capacitación por semana), el cual incluida talleres de transformación cultural

organizacional, esta se estructuró de la siguiente manera: en la semana 1 se realizó la

primera etapa de la capacitación, en la semana 2 se desarrolló la primera prueba en el

71

sistema, así como la segunda sección de capacitación, en la semana 3 se llevó a cabo la

tercera sesión sobre transformación cultural organizacional, los cuatros últimas semanas

fueron de pruebas y acompañamiento (Ver Tabla 16).

Tabla 16. Cronograma de la capacitación para la implementación de la nueva gestión del

cambio de la empresa GabBot.

Meses/Semanas

Etapas abril-18 mayo-18

2 3 4 1 2 3 4

1 M 1 P1 P2 P3 Op

2 M 2 P1 P2 P3 Op

3 M 3 P1 P2 P3 Op


Una vez realizada la capacitación, del personal para la implementación de la gestión del

cambio, se procedió a la obtención de la data para la aplicación de la prueba piloto, en este

sentido se estableció como lapso para la obtención del registro de cambios e incidentes en

seis meses, a partir del mes de mayo del 2019. Los datos obtenidos se compraron obtenido

en el año 2018 como se presentan en la tabla 17.

Tabla 17. Comparación de la lista de servicios, incidentes de la empresa GabBot años 2018

y 2019.

Servicios

Semestre Año 2018 Semestre Año 2019

Incidentes Total de Cambios

aprobados Incidentes

Total de cambios aprobados

Aplicaciones SAP 79 102 7 28

CECOM 29 36 4 19

SO y aplicaciones 15 17 3 9

NOC 6 8 1 3

Back ups y restores 5 5 0 2

SOC 2 2 0 0

Monitoreo 1 1 0 0

Total 137 171 15 61


72

Figura 15. Número de incidentes atendidos por la empresa GabBot año 2018 y 2019.


Tabla 18. Valor porcentual de incidentes de la empresa GabBot para los años 2018 y 2019.

Incidentes 2018 (%) Incidentes 2019 (%)

80 25


Ahora bien, de acuerdo a los resultados obtenidos de la prueba piloto aplicada desde el

mes de mayo hasta el mes de octubre, se pudo recopilar la información de la métrica

propuesta y a partir de esta se realizó los cálculos para determinar la relación de la fase de

transición de ITIL (aprobación del cambio) y fase de operación (implementación del cambio)

con las incidencias generadas.

Para la determinación de la relación entre la gestión de cambios desde la fase de

transición de ITIL y los incidentes en la infraestructura de una empresa de servicios de

tecnología de información, se comparan los resultados obtenidos de los cambios

aprobados y los incidentes generados para los años 2018 y 2019 (ver tabla 19).

79

29

15

6 52 1

23

72 2 0 0 0

74 3 1 0 0 02 1 0 0 0 0 0

0

10

20

30

40

50

60

70

80

90

AplicacionesSAP

CECOM So yaplicaciones

NOC Back ups yrestores

SOC Monitoreo

Año 2018 Incidentes Año 2018 Eventos Año 2019 Incidentes Año 2019 Eventos

73

Tabla 19. Indicadores de cambios aprobados y realizados, y cambios rechazados para el

año 2018 y 2019.

Indicadores 2018 2019 Indicadores 2018 2019

Cambios aprobados 171 61 Numero de cambios solicitados

199 157

Cantidad de cambios realizados

83 61 Numero de cambios rechazados

15 96

Porcentaje de cambios realizados

49% 100% Porcentaje de cambios rechazados

8% 61%


Asimismo, se calculó la correlación entre las variables: cambios aprobados e incidentes,

a través, del método de Rho de Spearman, el cual se emplea para datos que no poseen

un comportamiento normal, estos resultados se presentan en la tabla 20.

Tabla 20. Relación de cambios aprobados e incidentes.

Cambios

aprobados Incidentes

Rho de Spearman Cambios

aprobados

Coeficiente de

correlación

1,000 -,873*

Sig. (bilateral) . ,010

N 7 7

Incidentes Coeficiente de

correlación

-,873* 1,000

Sig. (bilateral) ,010 .

N 7 7

*. La correlación es significativa en el nivel 0,05 (2 colas).


Como se puede observar, el coeficiente de correlación calculado para las variables

antes mencionadas fue de -0.873 con un valor de significancia de 0.010, lo que quiere

decir, que la correlación es inversa y elevada, mientras aumenta el número de cambios

aprobados disminuye el número de incidentes generados.

74

Para la determinación de la relación entre la gestión de cambios desde la fase de

operación de ITIL y los incidentes en la infraestructura se comprarán los resultados

obtenidos de los cambios realizados y los incidentes generados para los años 2018 y 2019

(ver tabla 18).

De igual forma, se calculó la correlación entre las variables: cambios realizados e

incidentes, a través, del método de Rho de Spearman, el cual se emplea para datos que

no poseen un comportamiento normal, estos resultados se presentan en la tabla 21.

Tabla 21. Relación de cambios realizados e incidentes.

Incidentes

Cambo

realizado

Rho de Spearman Incidentes Coeficiente de correlación 1,000 -,873*


N 7 7

Cambios realizados Coeficiente de correlación -,873* 1,000


N 7 7





decir, que la correlación es inversa y elevada, mientras aumenta el número de cambios

realizados disminuye el número de incidentes generados.

Ahora bien, para calcular el impacto que tiene la planificación de la gestión de cambios


información se comparan los resultados obtenidos de las actividades planificadas y los

incidentes generados para los años 2018 y 2019 (ver tabla 22).

Tabla 22. Cantidad de actividades aprobadas e incidentes para los años 2018 y 2019.

2018 2019

Actividades planificadas 199 157

Incidentes 137 15

Porcentaje de incidentes por actividades planificadas 69% 10%


75

Además, se calculó la correlación entre las variables: Actividades planificadas e

incidentes, a través, del método de Rho de Spearman, el cual se emplea para datos que

no poseen un comportamiento normal, estos resultados se presentan en la tabla 23.

Tabla 23. Relación de actividades planificadas e incidentes.

Incidentes

Actividades

planificadas

Rho de Spearman Incidentes Coeficiente de correlación 1,000 -,631


N 7 7

Actividades planificadas Coeficiente de correlación -,631 1,000


N 7 7





decir, que la correlación es inversa y moderadamente elevada, mientras aumenta el

número de cambios planificados disminuye el número de incidentes generados.

76

DISCUSIÓN

La nueva gestión del cambio propuesto y evaluado mediante la prueba piloto realizada,

arrojan varios resultados de notable mejora, además de evidenciar una relación inversa

entre las variables estudiadas.

En relación a los resultados obtenidos del número de incidentes por servicio TI, se pudo

observar una disminución importante en cada uno de los servicios evaluados,

principalmente en el servicio Core de negocio (ERP SAP Aplicaciones), en el caso de la

aplicación SAP, esta presentó 79 incidentes (69%) para el año 2018, antes de la aplicación

de la gestión del cambio basada en la metodología ITIL; mientras que después de la prueba

piloto realizada se pudo evidenciar una reducción, 7 incidentes (25%) en el año 2019 para

aplicaciones SAP, lo que quiere decir que, al trabajar bajo esta metodología, donde se

evalúa la solicitud del cambio y se revisa a profundidad su alcance y los riesgos que estos

representa, así como las actividades que se debe realizar para el logro de lo solicitado, se

minimiza el error, por lo cual el número de incidentes que se pueden encontrar durante el

cambio se reduce considerablemente.

Al comparar el resultado obtenido de reducción del número de incidentes con el

reportado por Gómez (2018) el cual fue de 27%, se puede evidenciar que el número de

incidentes tuvo una reducción mayor; por otra parte Morillo (2018), también logro disminuir

en un 32.29% el número de incidentes y en un 43% el número de reincidencias; lo que

demuestra la alta eficiencia de la buenas prácticas de ITIL aplicada en la gestión del cambio

propuesta.

Ahora bien, de la métrica propuesta para la implementación de la gestión del cambio,

se pudo observar una reducción muy marcada entre el número de cambio solicitados y

rechazados antes y después de la implementación, ya que, antes de la nueva gestión del

cambio, no existía una evaluación efectiva de los cambios solicitados, observándose un

número de solicitud igual a 199 y un número de rechazo de solo 15 solicitudes, mientras

que después de la implementación se observó una depuración de los casos, ya que de 157

solicitudes de cambio se rechazaron 96, por no contar con los requisitos completos para

ser evaluadas y determinar su factibilidad ejecución. Esto repercute directamente en el

número de incidentes, debido a que, al no suministrar toda la información del cambio y su

alcance, no se podrá evaluar correctamente y la probabilidad de que aumente el número

de incidentes es mayor.

En relación al porcentaje de incidentes con la cantidad de actividades planificadas, se

77

puede evidenciar una disminución del número de incidentes de 137 a 15, lo que quiere

decir, que la planificación es fundamental para la aprobación de los cambios a realizar,

debido a que esta se muestran todas las actividades: previas, en implementación,

posteriores y de retroceso (Roll Back), que se ejecutaran durante la implementación del

cambio.

Ahora bien, en relación a las hipótesis planteadas en el presente estudio, para la relación

entre la gestión de cambios desde, la fase de transición de ITIL y los incidentes en la

infraestructura, arrojó como resultado un valor de correlación de -0.873 con un valor de

sig., de 0.010, lo que quiere decir, que existe una relación inversa y elevada, mientras se

apruebe un número mayor de cambios aplicando esta metodología el número de incidentes

será menor, en comparación a lo observado para el año 2018.

De la misma manera, para la relación entre la gestión de cambios desde, la fase de

operación de ITIL y los incidentes en la infraestructura, se obtuvo un valor de correlación

de -0.873 con un valor de sig., de 0.010, lo que quiere decir, que existe una relación inversa

y elevada, mientras se realice un número mayor de cambios aplicando esta metodología el

número de incidentes será menor, en comparación a lo observado para el año 2018.

Finalmente, para el impacto que tiene la planificación de la gestión de cambios y los

incidentes en la infraestructura, se obtuvo un valor de correlación de -0.631 con un valor

de sig., de 0.029, lo que quiere decir, que existe una relación inversa y elevada, mientras

se realice una buena planificación de las solicitudes de cambios aplicando esta

metodología el número de incidentes será menor, en comparación a lo observado para el

año 2018.

78

CONCLUSIONES

1. Se pudo observar una reducción del número de incidentes de un total de 137 para el

año 2018 a un total de 15 en un lapso de seis meses de prueba piloto, lo que significa

que cuanto más apliquemos el proceso de gestión de cambios y la planificación de los

mismos, el porcentaje de incidentes disminuye logrando resultados eficaces, y ahorro

de costos en re trabajos, reprocesos y pagos de penalidades por indisponibilidad de

servicios de los clientes de GabBot.

2. El porcentaje de incidentes reportados para el año 2018 en relación a las solicitudes de

cambio fue de 80%, mientras que para el 2019 fue del 25%, observándose una

reducción considerable de los incidentes después de la implementación de la nueva

gestión del cambio.

3. De acuerdo a la métrica propuesta en la gestión del cambio, se pudo conocer que la

cantidad de cambio solicitados para el año 2018 fue 199 y para el 2019 fue de 157,

mientras que la cantidad de cambios realizados para el año 2018 fue de 83 y para el

2019 fue de 96 y los cambios solicitados rechazados para el año 2018 fue de 8% y para

el 2019 fue de 61%, eso significa que la fase de planificación de la gestión de cambios

ayuda a identificar los riesgos asociados y se puede hacer un adecuado plan de

mitigación de riesgos.

4. La hipótesis específica: La relación entre la gestión de cambios desde, la fase de

transición de ITIL y los incidentes en la infraestructura de una empresa de servicios de

tecnología de información, es inversa y elevada, fue aceptada.

5. La hipótesis específica: La relación entre la gestión de cambios desde, la fase de

operación de ITIL y los incidentes en la infraestructura de una empresa de servicios de

tecnología de información, es inversa y elevada, fue aceptada

6. La hipótesis específica: El impacto que tiene la planificación de la gestión de cambios


información, es inverso y elevado, fue aceptada.

7. Por lo tanto, la relación entre la gestión de cambios y los incidentes para minimizar su

impacto negativo en la empresa GabBot, es inversa y elevada.

79

RECOMENDACIONES

1. Se debe implementar la gestión de incidentes, con el propósito de que los clientes

internos se comprometan con los procesos ITIL v3 revisión 2011 y de esta manera se

puede realizar una gestión acorde a las buenas prácticas que presenta esta

metodología.

2. Se recomienda invertir en la implementación de la Gestión de Cambios, el cual ayudara

a disminuir los incidentes y por consiguiente los costos de operación, dicha inversión

se recupera en 5.5 meses de operación.

3. Se debe realizar entrenamiento en todas las áreas de la empresa GabBot, con el

objetivo de conocer y aplicar las buenas prácticas ITIL en sus procesos.

4. Se recomienda la implementación de otros procesos ITIL (por ejemplo, la gestión de

problemas, gestión de la configuración y gestión del conocimiento), mediante un

sistema de TI, que permita la agilidad y seguimiento a estos procesos.

5. Se debe aplicar hitos de control después de la implementación de los cambios

realizados a los servicios de TI, para dar cumplimiento con las buenas prácticas ITIL.

6. De igual manera se recomienda el mantenimiento adecuado de los indicadores del

proceso propuesto.

80

REFERENCIAS

Arias, F. (2012). El proyecto de investigación. (C. A. EDITORIAL EPISTEME, Ed.) (6ta

ed.). Caracas.

Blumberg, M., Cater-Steel, A., Rajaeian, M. M., & Soar, J. (2019). Effective organisational

change to achieve successful ITIL implementation: Lessons learned from a multiple

case study of large Australian firms. Journal of Enterprise Information Management,

32(3), 496–516. https://doi.org/10.1108/JEIM-06-2018-0117

Cifuentes, J. F. (2017). Propuesta de ajuste al modelo de gestión de incidentes de la

empresa Claro Colombia S.A. para el mejoramiento continúo de los tiempos de

respuesta basado en ITIL V3. (Tesis de pregrado). Universidad Santo Tomás,

Bogotá, Colombia.

Díaz, J. (2018). Formular un modelo de gestión de servicio para SAAS a través de ITIL:

caso Siempresoft E.I.R.L Chiclayo. (Tesis de maestría). Universidad Nacional “Pedro

Ruiz Gallo”, Lambayeque, Perú.

Eikebrokk, T. R., & Iden, J. (2017). Strategising IT service management through ITIL

implementation: model and empirical test. Total Quality Management and Business

Excellence, 28(3–4), 238–265. https://doi.org/10.1080/14783363.2015.1075872

Fernández, E. (2018). Implementar una aplicación en la web para mejorar la gestión de

requerimientos e incidencias en el Hospital General. (Tesis de pregrado).

Universidad San Ignacio de Loyola.

Gómez, S. (2012). Metodología de la investigación. (Red tecer Milenio, Ed.). Tlalnepantla.

Gómez, V. (2018). Mejora en la mesa de ayuda (help desk) de un organismo regulador en

el estado peruano utilizando ITIL. (Tesis de pregrado). Universidad San Ignacio de

Loyola, Lima, Perú.

Gonzales, J. (2015). Implementación del marco de trabajo ITIL V 3.0 para el proceso de

gestión de incidencias en el área del centro de sistema de información de la gerencia

regional de salud Lambayeque. (Tesis de pregrado). Universidad Católica Santo

Toribio de Mogrovejo, Chiclayo, Perú.

Hernández, R., Fernández, C., & Baptista, P. (2014). Metodología Investigación. (McGraw

Hill, Ed.) (6ta ed.). México D.F.

Informática para tu negocio. (2016). Aprendiendo acerca de la gestión del cambio ITIL.

Recuperado de https://www.informaticaparatunegocio.com/blog/aprendiendo-acerca-

la-gestion-del-cambio-itil/

ISO/IEC-27001. (2013). Sistema de Gestión de Seguridad de la Información.

81

ITIL® Foundation. (2011). Gestión de Cambios. Recuperado de

http://faquinones.com/gestiondeserviciosit/itilv3/transicion_servicios_TI/gestion_cam

bios/introduccion_objetivos.php

Jáuregui, K. (2016). Gestión del cambio: la receta peruana. Aptitus, 2(1), 56–57.

Recuperado de https://www.esan.edu.pe/sala-de

prensa/2016/11/23/estudio_esan_gestion_cambio_receta_peruana.pdf

Lazzati, S. (2014). La Toma de Decisiones. España: Granica.

Mariño, J. (2017). Qué es ITIL® V3. Recuperado de

http://itilv3fundamentos.blogspot.com/2017/11/que-es-itil.html

Morillo, M. (2018). Implementar un portal de conocimiento por lecciones aprendidas sobre

incidentes tecnológicos para incrementar la productividad en empresa aseguradora.

(Tesis de pregrado). Universidad San Ignacio de Loyola, Lima, Perú.

Pacheco, J. (2017). Gestión de cambios ITIL: utilice las mejores prácticas. Recuperado

de https://www.heflo.com/es/blog/itil/gestion-cambios-itil/

Palella, M., & Martins, F. (2012). Metodología de la investigación cuantitativa. (FEDUPEL,

Ed.) (1ra Reed). Caracas.

Pazmiño, C. (2017). Propuesta de implantación de una mesa de servicios utilizando como

modelo de gestión ITIL en el departamento de redes infraestructura y soporte técnico

en la defensoría pública de Quito (Matriz). (Tesis de maestia). Universidad de las

Américas, Quito, Ecuador.

Picard, M., Renault, A., & Barafort, B. (2015). A Maturity Model for ISO/IEC 20000-1

Based on the TIPA for ITIL Process Capability Assessment Model. Communications

in Computer and Information Science, 543, V–VII. https://doi.org/10.1007/978-3-319-

24647-5

Ramos, C. (2015). Los paradigmas de la investigación científica. Av.Psicol, 23(1), 2015.

Recuperado de

http://www.unife.edu.pe/publicaciones/revistas/psicologia/2015_1/Carlos_Ramos.pdf

Ruiz, M., Moreno, J., Dorronsoro, B., & Rodriguez, D. (2018). Using simulation-based

optimization in the context of IT service management change process. Decision

Support Systems, 112, 35–47. https://doi.org/10.1016/j.dss.2018.06.004

Sabino, C. (1992). El proceso de investigador. (Panapo, Ed.). Caracas, Venezuela.

Sáez, A. (2012). Apuntes de estadisticas para ingenieros. (Universidad de Jaén, Ed.).

Jaén.

ServiceTonic. (2019). ITIL V3. Gestión de incidentes. Recuperado de

https://www.servicetonic.com/es/itil/itil-v3-gestion-de-incidencias/

Tamayo, M. (2003). El proceso de la investigación científica. (S. A. D. V. EDITORIAL

82

LlMUSA, Ed.) (4ta edició). México D.F.

Villaverde, F. (2016). Modelo de gestión de cambios basados en la metodología ITIL en

corporación grupo Romero. (Tesis de pregrado). Universidad Tecnológica del Perú,

Lima, Perú.

Villegas, P. (2018). Propuesta de modelo de gestión de incidencias y peticiones de

servicios de TI para el banco desarrollo de los pueblos basado en ITIL V3:2011

como parte del plan estratégico. (Tesis de maestria). Universidad Internacional SEK ,

Quito, Ecuador.

83

ANEXOS

Anexo 1. Plan de trabajo para la ejecución de cambios.

SAP Basis

Item Actividad ClienteHostname /

Instancia / EquipoEntorno IP Address

Disponibilidad

de ServicioFecha Dia Duración Hora Inicio Hora Fin Estado Grupo Solucionador Nombre del Responsable Observaciones

01

02

03

04

05

06

07

08

09



Disponibilidad

de ServicioFecha Dia Duración Hora Inicio Hora Fin Estado Grupo Solucionador Responsable Observaciones

01

02

03

04

05

06

07

08

09

10

11

12

13

14

15



Disponibilidad


01

02

03

04

05

06

07



Disponibilidad


01

Tareas de Roll Back

Tareas Posteriores

Tareas en Implementación

Tareas Previas

Anexo 2. Comité de cambios.

El Comité de Cambios y Entregas está programado realizarse todos los días jueves a las

11:00hrs y la sala de reunión es reservada por el Analista de Cambios. El comité es

moderado por el Analista de Cambios y dirigido por una de las jefaturas o supervisiones de

los grupos solucionadores tomando un turno cada semana (Especialistas de cada área de

Tecnologia de Información).

Si en caso, el jueves es feriado entonces el miércoles se realizará y sino el martes.

Un día antes de la reunión de Comité de Cambios, el Analista de Cambios enviará una nota

recordatoria.

Cuando un Cambio de Excepción es aprobado puede pasar al Comité de Cambios, de

acuerdo a la fecha en la que sea solicitada su implementación (el Comité de Cambios se

da todos los jueves a las 11:00hrs.), para asegurar que el Plan de Trabajo y las

coordinaciones necesarias para implementarlo se han producido de manera satisfactoria.

Todos los Cambios Normales Riesgo 1, 2 y 3 pasan por Comité de Cambios.

Para los cambios de riesgo 1 y 2, se requiere de la asistencia del Gerente o Jefe de

Proyecto con el fin sustentar el plan de trabajo ante el Comité de Cambios.

Para los cambios de riesgo 1 y 2, deberán contar con plan de trabajo adjunto para

ser analizado en el comité.

En todos los casos, se requiere la presencia del Incident Manager.

Asistencia:

Consideraciones Normal Excepción

Riesgo 1 Riesgo 2 Riesgo 3 Riesgo 4 Todos

Sustentar Cambio

en Comité

JP o GP

+

Resolutor

JP o

Resolutor

Jefe o

Supervisor

de área

Jefe o

Supervisor

de área

JP o Resolutor + Jefe

o Supervisor de área

Nomenclatura:

JP: Jefe de Proyecto

GP: Gerente de Proyecto

86

Anexo 3. Condiciones indispensables durante un cambio.

Excepción Emergencia

Riesgo 1 Riesgo 2 Riesgo 3 Riesgo 4 Todos Todos

1Previamente debe contar con los respaldos (Backups)

correspondientesObligatorio Obligatorio Obligatorio Opcional Opcional Opcional

2

El Plan de Trabajo debe contrarse validado por los

responsables de las actividades y el Gestor de

Cambios

Obligatorio Obligatorio Obligatorio Opcional Obligatorio Opcional

3

La Encuensta de Riesgo debe ajustarse al cambio a

realizarse, para determinar de manera real el riesgo y

flijo de aprobación

Obligatorio Obligatorio Obligatorio Obligatorio Obligatorio Obligatorio

4 Pasa por comité de cambios Obligatorio Obligatorio Opcional Opcional Opcional Opcional

5 Contar con plan de trabajo adjunto para el comité Obligatorio Obligatorio Obligatorio Opcional Obligatorio Opcional

6 Asisenticia al comité JP + Resolutor

JP o Resolutor

+ Jefe o

Supervisor de

área

Jefe o

Supervisor de

área

Jefe o

Supervisor de

área

JP o Resolutor + Jefe o

Supervisor de áreaOpcional

7

Se debe ejecutar después de las 6:00pm (Si es de

lunes a viernes, en caso de fin de semana o feriado

se podrá hacer en cualquier horario)

Obligatorio Obligatorio Opcional Opcional Opcional Opcional

8Requiere Ingreso al DataCenter será después de las

6:00pm (De Lunes a Viernes)Obligatorio Obligatorio Opcional Opcional Opcional Opcional

9

Toda actividad de personal externo al Data Center

debe ser supervisada por GMD todo el tiempo que

tomen las acciones a realizar


10

Los Líderes de cambio deben brindar seguimiento

para Adjuntar el Plan de Trabajo debidamente

revisado y aprobado, a su vez hacer seguimineto a las

aprobaciones requeridas. En caso que la orden de

cambio no cuente con las aprobaciones respectivas,

automáticamente se procederá a cancelar.


NormalConsideracionesItem

87

Anexo 4. Funciones, habilidades y actividades a realizar de los responsables de la gestión

del cambio.

Gestor del cambio Funciones:

Recibe y procesa las Peticiones de Cambio.

Aprueba las Peticiones de Cambio dentro de su nivel de autorización.

Asigna prioridad y categoría a las peticiones de cambio, consultando en caso necesario

al Responsable del proceso.

Revisa las características de riesgo/impacto de las Peticiones.

Revisa el plan de trabajo y planifica los cambios menores.

Coordina la asignación de miembros con el perfil del proceso de Gestión de Cambios

Notifica el cambio a las partes implicadas.

Supervisa y coordina la operativa de tratamiento de los cambios.

Asesora e informa al Responsable del cambio

Actualiza el registro de cambios con cualquier progreso que tenga lugar,

incluyendo cualquier acción para corregir problemas y/o para mejorar la calidad del

servicio.

Es responsable de la revisión de todos los cambios implementados para

asegurarse de que han alcanzado sus objetivos, revisando cualquiera que haya

fracasado o haya tenido que deshacerse.

Informa de las desviaciones e incumplimiento de los ANS: Avisa y realiza el seguimiento

de la pérdida y degradación de servicios: avisos, seguimiento.

Habilidades:

Conocimiento del proceso de Gestión de Cambios y sus relaciones.

Capacidad de evaluación y priorización.

Buen planificador y negociador.

Conocimiento tecnológico.

Conocimiento de la organización TI.

Actividades a desarrollar:

Asegurar que todas las Peticiones de Cambio estén registradas y clasificadas.

Asegurar que los Técnicos especialistas de las Áreas Técnicas cumplan los

88

procedimientos de cambio establecidos.

Publicar y mantener la planificación de cambios (listado de cambios programados).

Proponer informes y métricas del proceso.

Participar en las revisiones técnicas.

Establecer y convocar el Comité de Cambios, y en su caso el Comité de Cambios de

Emergencia. Decidir los participantes y elaborar la agenda de cada reunión.

Asegurar la notificación y cierre de los cambios (cierre de RFC, actualización de estado

y cierre del registro de cambio).

Realizar un informe periódico del estado de los cambios: cerrados, en desarrollo y

pendientes.

Responsable del cambio

Funciones:

Es el responsable último de todas las actividades del proceso y se asegura de que se

realicen de forma eficiente.

Propone los recursos necesarios para el desarrollo del cambio.

Se asegura de que todos los implicados están suficientemente involucrados en el

cambio.

Se asegura de que se establecen unas buenas relaciones de trabajo con todas las

organizaciones implicadas, tanto internas como externas.

Se encarga de la revisión y mejora continua.

Autoriza o rechaza las peticiones de cambio.

Lleva a cabo la planificación de cambios mayores.

Genera órdenes de trabajo.

Supervisa que se actualiza la CMDB tras la ejecución de un cambio.

Lidera el cambio a desarrollar en el Comité de Cambios. En este sentido es responsable

del tratamiento en tales reuniones de todas las RFCs de alto impacto, emitiendo

anticipadamente una agenda de la reunión para facilitar su análisis previo a los

convocados.

Se relaciona con todas las partes necesarias para coordinar el desarrollo, prueba e

implantación del cambio, de acuerdo con el programa establecido.

Es responsable de monitorizar la eficacia y eficiencia de la Gestión de Cambios y hacer

recomendaciones sobre posibles mejoras.

Es responsable de analizar, proponer y verificar la revisión de la metodología de trabajo

89

en el tratamiento de cambios para su mejora.

Se encarga de la elaboración de información de gestión.

Habilidades:

Reconocimiento en la organización (autoridad y respeto).

Capacidad de decisión y ejecución.

Capacidad de negociación (político).

Buen comunicador y presentador.

Facilitador y motivador de equipos de trabajo.

Capacidad de planificación y gestión.

Conocimiento tecnológico.

Conocimiento del modelo de procesos.

Resultados clave:

Reducción del impacto negativo como consecuencia de cambios introducidos.

Lograr tiempos de implantación de cambios aceptables en función de la criticidad para

las operaciones de negocio.

Asegurar que los cambios se realizan de acuerdo a los estándares/procedimientos

establecidos.

Optimizar la utilización de los recursos.

Establecer el procedimiento de Petición de Cambio (formulario o documento RFC).

Asignar prioridad, con la colaboración del Gestor del proceso, y consensuada con el

promotor del cambio, para todas las RFCs.

Autorizar los cambios aceptables, en su caso, después de tener en cuenta el

asesoramiento del Comité de Cambios o de su Comité de Emergencia.

Rechazar cualquier RFC que se juzgue no adecuada.

Generar informes de gestión exactos de manera regular.

Comité de Cambios (CAB)

Funciones:

Evaluar y asesorar la aprobación de los cambios que lo requieran (complejos, de alto

impacto, etc.)

Asistir a la Gestión de Cambios en la asignación de la prioridad de los cambios.

Proponer el calendario de implantación de cambios.

90

Proponer modificaciones de procedimientos de cambio cuando se juzgue

adecuado.

Verificar que se cumple la planificación y los planes de calidad.

Evaluar el proceso de Gestión de Cambios, al objeto de corregir desviaciones y/o

proponer mejoras.

Habilidades:

Máximo nivel consultivo en cambios.

Capacidad de análisis de decisiones.

Capacidad de asesoramiento para la ejecución.

Entendimiento de las necesidades y prioridades del negocio.

Facilitador y motivador de equipos de trabajo.

Resultados Clave:

Dar alternativas en cambios mayores, macros.

Aprobar cambios mayores, macros, que afectan el negocio.

Resolver conflictos de cambios (planificación, prioridades, presupuestos).

Propuestas de mejora al proceso de Gestión de Cambios.

Principales obligaciones de un miembro del Comité de Cambios:

Revisar todas las RFCs recibidas. Cuando sea apropiado, concretar y proporcionar

detalles acerca de su impacto probable, los recursos necesarios para su

implementación, y el coste hasta la fecha de todos los cambios.

Asistir a las reuniones del Comité de Cambios o su Comité de Emergencia cuando sea

necesario. Estudiar todos los cambios en el programa y dar su opinión acerca de cuáles

debería recibir autorización. Participar en la programación de todos los cambios.

Estar disponible para responder a cualquier consulta si fuera necesario realizar un

cambio urgente (caso de Comité de Emergencia de Cambios).

Asesorar a la Gestión de Cambios sobre los aspectos de los cambios urgentes

propuestos.

91

Anexo 5. Costo y Beneficio

La presente, es una tesis de investigación la cual recomienda el uso del proceso de

gestión del cambio para lograr mejoras en nivel de calidad del servicio y eficiencias

económicas al evitar re trabajos, pagos de horas extras, y costos escondidos al

solucionar incidentes fuera de horario de oficina.

Costo de operación de la situación actual.

Costo de Operación propuesto aplicando la Gestión del Cambio.

Costo de Implementación de Gestión de Cambio.

92

En resumen tenemos:

Se concluye que con la implementación de la gestión del cambio los costos directos

asociados a los incidentes disminuyen en casi un 90%, lo cual es un buen indicador

económico a tomar en consideración como negocio.

Se concluye que el costo de implementación de la Gestión de cambios se recupera

dentro del primer año de Operación (5.5 meses).

93

Para reforzar la recomendación desde el punto de vista financiero hemos realizado el

cálculo de la viabilidad de la investigación utilizando VAN, TIR y ROI

Proyectando este análisis, podríamos considerar una inversión de S/ 59 500.00 para la

implementación de la gestión del cambio, el cual nos traería un ahorro en la operación

de los servicios de TI de S/ 129 845.45, calculando a una tasa de 5% (tasa promedio

del mercado en cajas para ahorro a plazo fijo, fuente

https://comparabien.com.pe/depositos-plazo).

Se tomó como ingresos proyectados a 1 año, porque es el tiempo de contratación entre

GabBot y sus nuevos clientes, después del cual se ejecutan renovaciones con plazos

mayores.

https://comparabien.com.pe/depositos-plazo

relaciÓn entre la gestiÓn de cambios y los incidentes para minimizar su impacto...

Documents