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
Objetivo específico 2 41
Objetivo específico 3 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
Hipótesis específica 2 44
Hipótesis específica 3 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
Fuente: Elaboración propia.
Figura 3. Gráfico de Pareto.
Fuente: Elaboración propia.
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
y los incidentes en la infraestructura de una empresa de servicios de tecnología de
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?
Fuente: Elaboración propia.
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.
Fuente: Elaboración propia.
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.
Objetivo específico 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.
Objetivo específico 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.
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.
Hipótesis específica 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.
Hipótesis específica 3
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
Fuente: Elaboración propia.
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
Fuente: Elaboración propia.
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
Fuente: Elaboración propia.
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
Fuente: Elaboración propia.
Tabla 7. Descripción de los datos del cambio en la empresa GabBot.
N° Ítems Descripción
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
Fuente: Elaboración propia
54
Tabla 8. Descripción de los detalles del cambio en la empresa GabBot.
N° Ítems Descripción
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.
Fuente: Elaboración propia.
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
Fuente: Elaboración propia.
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
Fuente: Elaboración propia.
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.
Fuente: Elaboración propia.
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
Fuente: Elaboración propia.
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)
Fuente: Elaboración propia.
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
Fuente: Elaboración propia.
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
Fuente: Elaboración propia.
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.
Fuente: Elaboración propia.
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
Fuente: Elaboración propia.
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.
Fuente: Elaboración propia.
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.
Fuente: Elaboración propia.
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.
Fuente: Elaboración propia
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
Fuente: Elaboración propia.
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
Fuente: Elaboración propia.
72
Figura 15. Número de incidentes atendidos por la empresa GabBot año 2018 y 2019.
Fuente: Elaboración propia.
Tabla 18. Valor porcentual de incidentes de la empresa GabBot para los años 2018 y 2019.
Incidentes 2018 (%) Incidentes 2019 (%)
80 25
Fuente: Elaboración propia.
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%
Fuente: Elaboración propia.
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).
Fuente: Elaboración propia.
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*
Sig. (bilateral) . ,010
N 7 7
Cambios realizados 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).
Fuente: Elaboración propia.
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
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
y los incidentes en la infraestructura de una empresa de servicios de tecnología de
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%
Fuente: Elaboración propia.
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
Sig. (bilateral) . ,029
N 7 7
Actividades planificadas Coeficiente de correlación -,631 1,000
Sig. (bilateral) ,029 .
N 7 7
*. La correlación es significativa en el nivel 0,05 (2 colas).
Fuente: Elaboración propia.
Como se puede observar, el coeficiente de correlación calculado para las variables
antes mencionadas fue de -0.631 con un valor de significancia de 0.029, lo que quiere
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
y los incidentes en la infraestructura de una empresa de servicios de tecnología de
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
Item Actividad ClienteHostname /
Instancia / EquipoEntorno IP Address
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
Item Actividad ClienteHostname /
Instancia / EquipoEntorno IP Address
Disponibilidad
de ServicioFecha Dia Duración Hora Inicio Hora Fin Estado Grupo Solucionador Responsable Observaciones
01
02
03
04
05
06
07
Item Actividad ClienteHostname /
Instancia / EquipoEntorno IP Address
Disponibilidad
de ServicioFecha Dia Duración Hora Inicio Hora Fin Estado Grupo Solucionador Responsable Observaciones
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
Obligatorio Obligatorio Obligatorio Obligatorio Obligatorio Obligatorio
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.
Obligatorio Obligatorio Obligatorio Obligatorio Obligatorio Obligatorio
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.