facultad de ingeniería de sistemas y...
TRANSCRIPT
Facultad de Ingeniería de Sistemas
y Electrónica
Carrera Profesional de Ingeniería de Sistemas e
Informática
Informe de Suficiencia Profesional para optar el
Título Profesional de Ingeniero de Sistemas e
Informática
“MODELO DE GESTIÓN DE CAMBIOS BASADOS EN
LA METODOLOGÍA ITIL EN CORPORACIÓN
GRUPO ROMERO”
Bachiller:
Frank Enrique Villaverde García
Lima – Perú
2016
Facultad de Ingeniería de Sistemas
y Electrónica
Carrera Profesional de Ingeniería de Sistemas e
Informática
Informe de Suficiencia Profesional para optar el
Título Profesional de Ingeniero de Sistemas e
Informática
“MODELO DE GESTIÓN DE CAMBIOS BASADOS EN
LA METODOLOGÍA ITIL EN CORPORACIÓN
GRUPO ROMERO”
Bachiller:
Frank Enrique Villaverde García
Lima – Perú
2016
Agradezco a Dios por brindarme bendiciones cada día. Gracias a mis padres por su apoyo en lo largo de mi carrera profesional y superarme cada día en la vida .Agradezco a mi esposa por su apoyo incondicional para lograr mis metas y por creer en mí.
i
INTRODUCCIÓN
En un mundo donde la competencia nos obliga a ser cada vez mejores, Corporación
Grupo Romero representa una empresa líder en el mercado teniendo como
empresas líderes Alicorp ,Ransa ,Palmas, Tramarsa, Sitel, Caña Brava, Fino,
Romero Trading, Pesquera Centinela, Tisur, Wigo . Rubro donde el cambio es
obligado para adaptarse y sobrevivir, plantear proyectos de cambios continuos en
diferentes frentes de TI es una constante necesaria.
Los proyectos de informática se encuentran, por su naturaleza, en el centro de la
innovación comercial y a través de su implementación provocan cambios en los
procesos y las prácticas comerciales. El factor humano es la principal causa de
fracaso en este tipo de proyectos.
La gestión de cambios incluye la anticipación de riesgos, la definición y el diseño de
un enfoque que permita la implementación de una solución bajo circunstancias
óptimas. Los enfoques de la gestión de cambios generalmente se basan en las tres
ideas que se indican a continuación:
Participación: involucrar a los equipo de trabajo y recursos desde el comienzo del
proyecto, con el objetivo principal de tener en cuenta sus consejos y lograr que el
resultado iguale las expectativas.
Comunicación: establecer un medio de comunicación durante todo el proyecto que
les permita a los equipos de trabajo de Corporación Grupo Romero comprender y
aceptar los futuros cambios, así como también informarles sobre el progreso del
proyecto.
Capacitación: asegurarse de que los equipos de trabajos tengan adquirido el
conocimiento práctico y teórico necesario.
CONTENIDO
INTRODUCCIÓN ..................................................................................................... I
RESUMEN .............................................................................................................. 1
1. CAPÍTULO I: ASPECTOS GENERALES ........................................................ 2
DEFINICIÓN DEL PROBLEMA ......................................................................... 2
1.1.1 Descripción del Problema ...................................................................... 2
1.1.2 Formulación del Problema ..................................................................... 4
DEFINICIÓN DE OBJETIVOS ........................................................................... 5
1.2.1 Objetivo General .................................................................................... 5
1.2.2 Objetivos Específicos ............................................................................ 5
1.2.3 Alcances y Limitaciones ........................................................................ 5
1.2.4 Justificación ........................................................................................... 6
1.2.5 Estado del Arte ...................................................................................... 7
2. CAPITULO II MARCO TEORICO .................................................................. 28
2.1 FUNDAMENTO TEÓRICO .................................................................................. 28
2.1.1 ITIL ...................................................................................................... 31
2.1.2 Antecedentes de ITIL .......................................................................... 31
2.1.3 Estructura de ITIL ................................................................................ 33
2.1.4 Ciclo de vida del servicio ..................................................................... 33
2.1.5 Fases del Ciclo de Vida del Servicio ................................................... 34
2.1.6 Estrategia del servicio ......................................................................... 35
2.1.7 Diseño del servicio .............................................................................. 35
2.1.8 Transición del servicio ......................................................................... 36
2.1.9 Operación del servicio ......................................................................... 37
2.1.10 Mejoramiento Continuo .................................................................... 37
3. CAPITULO III: DESARROLLO DE LA SOLUCION ...................................... 38
DEFINICIÓN DE CAMBIOS ............................................................................ 39
SOLICITUD DE REQUERIMIENTO DE CAMBIO: ................................................ 40
REGISTRO DE SOLICITUD DE CAMBIO ........................................................... 40
3.3.1 Ingreso al Formulario de Cambios....................................................... 40
3.3.2 Formulario de Cambios: ...................................................................... 40
PRIORIZACIÓN DE CAMBIOS ........................................................................ 45
CATEGORIZACIÓN CAMBIOS NORMALES ...................................................... 45
MÉTODO DE CATEGORIZACIÓN CAMBIO NORMALES: ..................................... 46
RIESGOS DE CAMBIO ................................................................................. 48
APROBACIÓN DE CAMBIOS ......................................................................... 50
APROBACIÓN/VALIDACIÓN DE CAMBIOS DE EMERGENCIA .............................. 51
APROBACIÓN CAMBIOS DE EXCEPCIÓN ........................................................ 53
APROBACIÓN DE CAMBIOS SOBRE APLICACIONES CRITICAS .......................... 54
COMITÉ TÉCNICO DE CAMBIO ..................................................................... 56
COMITÉ ASESOR DE CAMBIO ...................................................................... 57
EJECUCIÓN DE LOS CAMBIOS ...................................................................... 58
PROBLEMAS DURANTE IMPLEMENTACIÓN/ ROLLBACKS .................................. 59
NOTIFICACIÓN DE TÉRMINO DE IMPLEMENTACIÓN .......................................... 59
4. CAPITULO IV: RESULTADO ........................................................................ 63
RESULTADOS ............................................................................................ 63
CRONOGRAMA .......................................................................................... 66
CONCLUSIONES ................................................................................................. 68
RECOMENDACIONES ......................................................................................... 69
BIBLIOGRAFIA .................................................................................................... 70
INDICE DE ILUSTRACIONES
Ilustración 1.1 Arbol de Problemas .......................................................................... 4
Ilustración 3.1 Modelo de proceso de Cambio ...................................................... 38
Ilustración 3.2 Información del Solicitante ............................................................. 41
Ilustración 3.3 Detalles del Cambio ....................................................................... 42
Ilustración 3.4 Información Adicional ..................................................................... 44
Ilustración 4.1 Muestra del año tickets con Prioridades ........................................ 64
Ilustración 4.2 Indicadores de Gestión de Cambios .............................................. 65
Ilustración 4.3 RFC’s Aceptadas vs Rechazadas .................................................. 65
Ilustración 4.4 WBS ............................................................................................... 66
Ilustración 4.5 Cronograma ................................................................................... 67
INDICE DE TABLAS
Tabla 1.1 Árbol de Problemas ................................................................................. 3
Tabla 3.1 Detalle Registro ..................................................................................... 41
Tabla 3.2 Descripción Detalles del cambio ........................................................... 43
Tabla 3.3 Descripción de campos Información Adicional ...................................... 44
Tabla 3.4 Cuestionario Categorización Cambios Normales Fuente: Elaboración Propia .................................................................................................................... 47
Tabla 3.5 Resultados Fuente: Elaboración Propia ................................................ 48
Tabla 3.6 Evaluador de Riesgo ............................................................................. 49
Tabla 3.7 Resultados Criticidad ............................................................................. 49
Tabla 3.8 Requisitos de Aprobación ...................................................................... 50
Tabla 3.9 Formato Solicitud Emergencia .............................................................. 51
Tabla 3.10 Formato Solicitud Excepción ............................................................... 52
Tabla 3.11 Matriz de Aprobación ........................................................................... 53
Tabla 3.12 Matriz de Escalamiento Cambios Emergencia .................................... 53
Tabla 3.13 Matriz Escalamiento Cambios de Excepción ....................................... 54
Tabla 3.14 Aplicaciones ........................................................................................ 55
Tabla 3.15 Calendario Idea de Cambios ............................................................... 58
Tabla 3.16 Flujo Cambios Normales ..................................................................... 60
Tabla 3.17 Flujo Proceso de Cambios .................................................................. 61
Tabla 3.18 Flujo Cambio de Emergencia .............................................................. 62
Tabla 4.1 Porcentaje de Tickets de prioridades con una muestra de 01 año ........ 63
1
RESUMEN
El presente documento representa la memoria del proyecto “Modelo de gestión de
cambios basados en la metodología ITIL en Corporación Grupo Romero”, con el
objetivo de alcanzar el grado de ingeniero de sistemas e informática.
El presente documento contiene cuatro capítulos, los cuáles serán explicados
brevemente. EL tema principal, es modelar el proceso de cambios en corporación
grupo romero donde brinda servicios a las distintas empresas del grupo como
Tramarsa, Ransa, Alicorp, Palmas, Primax, Caña Brava, Wigo, Sitel.
El primer capítulo trata acerca de la descripción del problema que presenta
Corporacion Grupo Romero, se presentan los objetivos en relación al proyecto,
descripción y el alcance del proyecto.
El segundo capítulo trata acerca del marco teórico del que consiste todo el proyecto,
se basa fundamentalmente en elaborar los conceptos que servirán de sustento
durante el modelo del proyecto, todo en base al principal problema a resolver.
El tercer capítulo describe el Estado del Arte del tema del proyecto, se describen los
temas
Y casos de estudio en relación al proyecto en comparación con las metodologías
que servirán de guía en el desarrollo del mismo.
El cuarto capítulo trata acerca del desarrollo del proyecto, se describen los
resultados y conclusiones finales del proyecto.
El presente proyecto brindará como resultado final un modelo para la gestión de los
cambios de TI entre las empresas de Corporacion Grupo Romero.
2
1. CAPÍTULO I: ASPECTOS GENERALES
En este primer capítulo de este documento se abarcará la definición y formulación del
problema. Además los objetivos, alcance, limitaciones y justificación de la solución,
también se mostrará las principales metodologías y herramientas que se aplican a
este tipo de proyectos.
Definición Del Problema
A continuación se detalla una breve descripción de la empresa, área donde se
sitúa el problema y el problema en general, además de la formulación de la
problemática a tratar.
1.1.1 Descripción del Problema
En la empresa Corporación Grupo Romero, gestiona proyectos
tecnológicos. Tiene la administración tecnológica de empresas líderes
en el mercado como lo son: Alicorp, Ransa, Palmas, Tramarsa, Sitel,
Caña Brava, Fino, Romero Trading, Pesquera Centinela, Tisur, Wigo.
Son diversos los problemas que se presentan en los departamentos de
Infraestructura y Tecnología de Información (TI),en el área de
tecnología por los cambios que se realizan en la Infraestructura
Tecnológica y el no poseer información detallada, precisa y fiable de
Todos los elementos que configuran esta, es por esta razón que existe
la necesidad de implementar los procesos de Gestión de
Configuraciones y cambios en los ambientes productivos
complementando el desarrollo del proyecto “SISTEMA DE GESTIÓN
DE CAMBIOS EN TECNOLOGIA (SERVICE DESK) PARA EL AREA
DE PROCESOS Y CAMBIOS EN EL GRUPO ROMERO”, cubriendo así
varios de los procesos que propone ITIL V.3 para un correcto servicio
al cliente. Generalmente las empresas que no tienen una correcta
gestión de estos Procesos tienen las siguientes características:
3
No existen políticas, procedimientos, manuales de operación.
No existe documentación acerca de los cambios realizados o las
circunstancia en los cuales se han realizado.
A continuación en la tabla 1.0 se mencionan las causas y efectos del
problema y en la figura 1 el diagrama del árbol de problemas con las
mismas causas y efectos.
ARBOL DE PROBLEMAS
DESCRIPCION DEL PROBLEMA: CAMBIOS EN TI EN LA EMPRESA GRUPO ROMERO SE ESTÁN EJECUTANDO SIN CONTROL Y COORDINACIÓN DE INVOLUCRADOS.
CAUSAS EFECTOS
1.- NO EXISTE CONCIENCIA DE UN MAL CAMBIO QUE AFECTA AL NEGOCIO
1.- INDISPONIBILIDAD DE SERVICIOS
2.- PROCESOS MANUALES 2.- ERRORES INVOLUNTARIOS
3.- INFORMACION NO CONFIABLE
3.- NO HAY DEFINICIÓN CLARA DE LOS ACTIVOS DE TI
4.- DOCUMENTACIÓN DESACTUALIZADAS
5.- NO EXISTE UNA CULTURA DE CONTROL DE CAMBIOS
5.- FALTA DE COORDINACIÓN CON PROYECTOS.
6.- FALTA DE VÍAS DE COMUNICACIÓN ENTRE LAS ÁREAS.
6.- CRUCE DE CAMBIOS EN LA INFRAESTRUCTURA TECNOLÓGICA.
Tabla 1.1 Árbol de Problemas
Fuente: Elaboración Propia
4
1.1.2 Formulación del Problema
En Corporación Grupo Romero se tiene una inadecuada gestión de
cambios con respecto a las otras áreas de TI (funcional, arquitectura,
seguridad y comunicaciones). Explicación: La gestión de cambios
tiene relación con todas las áreas de TI por medio del CAB (Comisión
de cambios), que es una comisión de aprobación de cambios, donde
eventualmente puede participar un representante de una área de TI,
que sea responsable por algún atributo que pueda tener el servicio
después de haber hecho el cambio, además de interactuar
directamente con la Gestión de Incidencias y Gestión de Problemas,
adicionalmente cuando cualquier técnico de cualquier área y rol,
quiere registrar una petición de cambio. Actualmente no se lleva a
cabo una correcta coordinación con las otras gestiones de TI a pesar
de la fuerte relación que hemos explicado.
Implicancias: Un miembro del CAB ausente en la planificación del
cambio, puede significar que el cambio no cumple con sus
expectativas o redunde en una deficiencia en el servicio que era su
responsabilidad.
Ilustración 1.1 Árbol de Problemas
Fuente: Elaboración Propia
5
Definición de Objetivos
En la presente sección se define el objetivo general y los objetivos específicos
del Proyecto.
1.2.1 Objetivo General
Diseñar el proceso de gestión de cambios en la empresa Grupo Romero
utilizando las buenas prácticas de ITIL.
1.2.2 Objetivos Específicos
A continuación se define los siguientes objetivos específicos del
proyecto:
1. Definir roles y responsabilidades para el proceso de cambios para
estandarizar métodos y procedimientos dentro de la empresa Grupo
Romero.
2. Adaptar el flujo de atención de cambios a la empresa Grupo Romero
con el fin de reducir las indisponibilidades del sistema a causa de
cambios no gestionados.
3. Definir los indicadores y métricas para el proceso de gestión de
cambios del Grupo Romero para garantizar la evaluación del impacto
y riesgo.
1.2.3 Alcances y Limitaciones
Alcances
Elaboración del plan de implementación del modelo propuesto
orientado a ITIL v3.
Elaborar el modelo de los procesos de servicios de tecnología dela
información del Grupo Romero.
Realizar una descripción o inventario de los proceros de tecnología
de la información del Grupo Romero.
6
Limitaciones
No se cuenta con la suficiente información sobre los procesos.
Falta de cooperación de personal poco adaptable a los cambios.
No se considera al área de seguridad para el proceso de cambios.
1.2.4 Justificación
Las Tecnologías de la Información son tan antiguas como la historia
misma y han jugado un importante papel en la misma. Siguen siendo
una herramienta imprescindible y clave para las empresas e
instituciones.
La información es probablemente la fuente principal de negocio en el
primer mundo y ese negocio a su vez genera diferentes cantidades de
información. Su correcta gestión es de importancia estratégica y no
debe considerarse como una herramienta más entre muchas.
Hasta hace poco las infraestructuras informáticas se limitaban a dar
servicios de soporte y de alguna forma eran equiparables con otro
material de oficina: algo importante e indispensable para el correcto
funcionamiento de la organización pero poco más. Sin embargo, en la
actualidad esto ha cambiado y los servicios tecnología de información
representan generalmente una parte sustancial de los procesos de
negocio dentro de la organización.
Una vez planteado el problema y el desarrollo del modelo del uso de
ITIL. Traerá beneficios para Corporación Romero en la mejora de
procesos de la tecnología de información en:
Proporcionar una adecuada gestión de calidad.
Aumentar la eficiencia de los procesos.
Alinear los procesos de los negocios a la infraestructura de
tecnología de la información.
Reducir los riesgos asociados a los servicios de tecnología de
información.
El conocimiento de aplicar las mejores prácticas en tecnologías de la
información proporcionada las estrategias para la gestión operativa de
la infraestructura de tecnología de información
7
Justificación Económica:
Con la puesta en marcha del proyecto, el tiempo de respuesta para
atender las solicitudes de servicios TI por incidentes disminuirá debido
a que se investigará la causa raíz para que estas puedan prevenirse;
teniendo como resultado mayor disponibilidad de la infraestructura
tecnológica para que el negocio no deje de producir.
Justificación Operativa:
El proyecto permitirá diseñar e implementar procedimientos para dar
soporte, solución a los incidentes, problemas que se presenten en el
desarrollo de las actividades de la organización. Adicionalmente
permitirá gestionar el conocimiento durante la prestación de servicios TI
para brindar un soporte y gestión de servicios TI cumpliendo con
estándares de calidad.
Justificación Institucional:
Ampliar el portafolio de Servicios con soporte de primer nivel para
continuar consolidándonos como una empresa altamente competitiva.
1.2.5 Estado del Arte
En esta sección se describirán las principales herramientas donde se ha utilizado las buenas practicas ITL v3 con el fin de dar un mayor valor al negocio.
Antecedentes de Trabajos Similares
Título: Modelo para la implementación de ITIL en una institución universitaria
Definición del Problema
En el presente trabajo que tomamos como referencia de la
implementación de ITIL en una institución de Educación Superior, se ha
investigado acerca del crecimiento en número de estudiantes que tienen
en los últimos 10 años, pasando de 724.236 estudiantes en el año 2000
a 1.045.570 estudiantes en el año 2010, lo que genera la a necesidad
de contar con infraestructura, servicios y locaciones físicas que apoyen
el crecimiento, y esto a su vez genera un importante desarrollo en el
uso de las tecnologías de Información y Comunicación. (Lozano
Sandobal & Rodriguez Mejía, 2011)
8
Este cambio ha transformado la manera de realizar las actividades
académicas y administrativas, y por lo cual se hace necesario contar
con recursos, procesos y procedimientos que soporten los servicios
demandados por toda la población universitaria. Esta es una de las
razones que se hace importante gestionar dichos servicios de manera
eficiente, garantizando siempre la generación de beneficios y valor para
la institución, convirtiéndose lo anterior en un objetivo estratégico de un
área de TI de una institución Universitaria. Al identificarse el objetivo, se
identifica también el problema y se describe a la necesidad de poder
cubrir las necesidades de los clientes (la población estudiantil y
administrativa) con los recursos existentes, en el tiempo adecuado y de
manera que satisfaga las reglas del negocio.
Como solución del problema que se ha logrado identificar, la
instituciones universitarias han empezado a trabajar definiendo
objetivos, servicios, procesos, procedimiento acuerdos de niveles de
servicios, pero en la mayoría de los casos estos trabajos se realizan de
manera aislada y se hace necesario contar con un modelo que permita
integrar todo esos trabajos realizados de manera individual, y poder
generar valor a la Institución Universitaria. (Lozano Sandobal &
Rodriguez Mejía, 2011)
Objetivo
El objetivo identificado es el de definir las estrategias de estudio dentro
de la organización, así como los objetivos, el alcance, el cronograma,
los recursos necesarios y los entregables. Es importante que esta fase
se difundida y comunicada dentro del área de la organización. (Lozano
Sandobal & Rodriguez Mejía, 2011)
Definición
Mediante la información base obtenida, se va a determinar la manera
de trabajar en el área para el proceso de implementación de ITIL, es
una de las etapas más importantes ya que es donde se analiza y
determina cuál es el recorrido del proceso y los recursos que se deben
contar para la realización de la implementación. (Lozano Sandobal &
Rodriguez Mejía, 2011)
9
Herramientas
La herramienta que se está utilizando es un documento que será la carta de navegación de todo el proyecto y que va a contar con los siguientes puntos explicados a continuación:
La organización
Se va a documentar las características de la organización en la cual se realizará el estudio de procesos de ITIL. Se debe incluir temas estratégicos, historia, organigrama, estructuras de gobierno, establecimiento el marco de trabajo (en este caso ITIL).
Objetivo
Se debe establecer con claridad el objetivo del estudio de los procesos de ITIL para definir los procesos que se implementaran, esto permitirá no desviar las actividades y que el estudio de los procesos tenga una guía clara. (Lozano Sandobal & Rodriguez Mejía, 2011)
Alcance
Dentro del alcance se define y analiza donde serán aplicados el
estudio y las encuestas, estableciendo las áreas de tecnología o
áreas usuarias que serán involucradas en el estudio. Así mismo se
debe establecer los criterios de selección de cuáles serían los
procesos candidatos a ser implementados de acuerdo a los
resultados del estudio.
Para tener un mejor conocimiento del estado o madurez de ITIL se
sugiere evaluar todos los procesos de las fases del ciclo de vida del
servicio. Esto debe quedar definido en el estudio. (Lozano Sandobal
& Rodriguez Mejía, 2011)
A continuación se relacionan las fases de ciclo de vida del servicio
con sus procesos, los cuales van a ser evaluados.
10
A. Estrategia del servicio
Gestión de la cartera de servicios
Gestión Financiera
Gestión de la demanda
B. Diseño del servicio
Gestión de los niveles de servicio - SLM
Gestión Catálogo de servicios – SCM
Gestión de la disponibilidad
Gestión de la seguridad de la información
Gestión de los proveedores
Gestión de la capacidad
Gestión de la continuidad de los servicios de TI
C. Transición del servicio
Activos del Servicio y Gestión de la Configuración
Gestión de implementación y versión
Gestión del Cambio
Pruebas
D. Operación del servicio
Actividades
- Detección y Registro
- Clasificación y Soporte Inicial
- Investigación y Diagnóstico
- Resolver el incidente y recuperar el servicio
- Confirmación y Cierre
- Apropiamiento, Seguimiento y Comunicación
11
Organización
Métricas y Reportes
Relación entre procesos
- Service desk
- Change Management
- Configuration Management
- Problem Management
- Release Management
- Availability Management
- Capacity Management
- Continuity Management
- Financial Management
- Service level Management
- Security Management
Funciones de la operación de servicio
- Centro de servicio al usuario, Gestión Técnica, Gestión
de aplicaciones, Posición organizacional, Posición de
aplicaciones
E. Mejora continua del servicio
Objetivos
Enfoque de la mejora continua de Valor del negocio
Línea Base
Métricas y medidas
12
Equipo y recursos
En el apartado de equipo y recursos se va a establecer cual será el
equipo que estará involucrado dentro del estudio y análisis de los
procesos de ITIL. Estas personas son fundamentales para el suministro
de información de la Gestión de servicios de TI; dentro de este equipo
se definen las áreas de TI o áreas usuarias si en el alcance se incluye.
Estas áreas y cargos que formaran parte del estudio, suministraran a
través de una encuesta la información de la gestión de servicios de TI,
la percepción del servicio, entregaran información y evidencias de los
procesos existentes. (Lozano Sandobal & Rodriguez Mejía, 2011)
Factores críticos de éxito y restricciones
Para la aplicación del modelo se identificaron factores críticos de éxito
y restricciones entre los que se tienen: (Lozano Sandobal & Rodriguez
Mejía, 2011)
o Apoyo de la alta dirección.
o Disponibilidad de recursos para el proyecto (humano, financiero).
o Realizar un correcto análisis del entorno.
o Capacitación en ITIL.
o Involucrar a los stake holders.
o Realizar una implementación gradual.
o Llevar a cabo un sólido plan de comunicación.
o Habilidades y conocimiento del equipo de trabajo (nuevos
procesos).
o Promover el cambio cultural de la organización.
o Participación de todo el personal del área de tecnología
o Elegir correctamente al equipo implementador.
o Otros aspectos que se determinen en el análisis preliminar.
13
Entregables
o Plan de Proyecto: Documento en el cual se describe toda la
información obtenida en el ítem anterior es decir: objetivo, alcance,
equipo, recursos y factores críticos de éxito
o Plan de Trabajo: Cronograma en el cual se establece las
actividades, los responsables y el tiempo.
Objetivo
Se va a identificar el estado actual de los procesos ITIL basándose en
una revisión preliminar, con el fin de conocer el punto de partida para
lograr el objetivo de esta etapa.
Definición
En esta etapa se deberá llevar a cabo, un diagnóstico de la situación
actual del área de TI, con el fin de poder contar con una fotografía inicial
del área, y poder posteriormente hacer una comparación.
Sub-etapas
Evaluación procesos Actuales
Se debe identificar el punto de partida para iniciar la mejora de dichos
procesos con información más detallada del estado de cada proceso.
Esta evaluación del grado de madurez inicial permitirá determinar la
estrategia de implantación de procesos ITIL, alineada con las
necesidades más importantes de la organización con las TI.
Esta evaluación se puede llevar a cabo por medio de herramientas que
van a realizar la evaluación del grado de madurez para cada área del
proceso de ITIL y por medio de entrevistas que se apliquen al recurso
humano definido para el proyecto.
Las encuestas definidas se proponen mediante un cuestionario
estructurado y diseñado para obtener información específica del estatus
de los procesos de ITIL y de acuerdo al recurso humano elegido para la
implementación del modelo:
Como herramienta para evaluar la madurez de ITIL se propone la
entrevista y para la cual se preparó un cuestionario, esquematizándolo
de forma sencilla, estructurada, simple y práctica, permitiendo realizar
14
entrevistas rápidas y dinámicas, enfocándose en determinar el grado de
madurez, los puntos satisfactorios y a mejorar todas las áreas de
procesos de ITIL.
Para determinar el grado de madurez mediante la encuesta, consiste
en reunir información, interrogando a las personas que se van a
relacionar directamente con los servicios de TI de la organización, con
el fin de obtener así información a través de preguntas realizadas de
forma personal, telefónico y por correo electrónico.
La encuesta se elabora mediante un cuestionario estructurado,
diseñado para obtener información del estatus de los procesos de ITIL.
Definir los Recursos de la evaluación
Durante el proceso de preparación, definir las personas que serían
entrevistadas y así obtener un resultado más preciso de la evaluación
en base al grado de madurez de ITIL de la organización, se debe
seleccionar aquellas que ejecutan funciones de gestión de servicios y
los que tengan relación con los procesos de ITIL
Preparación de la encuesta
Para la preparación de la encuesta, teniendo presente los objetivos, el
enfoque de la evaluación, se debe definir las condiciones, encuestados,
los medios, el tiempo y la información disponible.
Además de los criterios para realizar un buen proceso de recolección
de información para obtener resultados claros e imparciales, teniendo
en cuenta los siguientes aspectos:
a. Honestidad: Se debe explicar detalladamente el propósito y alcance
del estudio a los entrevistados.
b. Confidencialidad: Se especifica quienes tendrían acceso a la
información recolectada, que manejo y uso se le dará a la
información
c. Control: En las encuestas y entrevistas se debe realizar el control de
la entrevistas, evitando las divagaciones y los comentarios al margen
de la cuestión.
15
d. Claridad: Se debe expresar las preguntas de manera clara (tono,
volumen y dicción adecuados), y en un lenguaje comprensible para
el entrevistado.
e. Objetividad: Evitar las preguntas tendenciosas, subjetivas o
interesadas. Durante la entrevista se debe evitar gestos o
comentarios de aprobación o rechazo ante las respuestas, o que
provoquen que el entrevistado se incline por ciertas respuestas.
f. Comunicación: Se debe escuchar atentamente y en silencio las
respuestas, evitando anticiparse a las respuestas, completarlas ni
comentarlas.
g. Pruebas: En la entrevista se deben aportar evidencias o pruebas
para justiciar las calificaciones de aquellas respuestas donde se
requerían.
Definición de Muestras
Para realizar la definición de muestras primero se hiso un estudio del
progreso y mejoras de los procesos de ITIL implementados y el impacto
sobre los demás procesos, mediante dos evaluaciones.
La primera como un elemento clave para determinar el grado de
madurez actual y determinar el punto de partida del plan de trabajo,
identificando los procesos de ITIL candidatos a implementar.
La segunda evaluación se debe realizar una vez se haya
implementados los principales procesos para conocer el avance del
proceso implementado y el efecto sobre los demás procesos.
Ambas deben quedar registradas en un cronograma. (Lozano Sandobal
& Rodriguez Mejía, 2011)
16
Definición del tiempo
Para definir los tiempos se va a elaborar un cronograma para tener
mayor atención y concentración de los encuestados en el proceso de
evaluación, se va a identificar el momento ideal para llevar a cabo la
evaluación, evitando coincidir con periodos de vacaciones de los
encuestados, procesos críticos de la organización, proyectos y
actividades especiales.
Herramientas
Escala de medición
Para calificar la evaluación del grado de madurez de ITIL, eligiendo la
metodología basada en el modelo CMMI y definiendo adicionalmente el
porcentaje de cumplimiento para cada nivel de madurez, de tal forma
que se pueda contar con información cuantitativa del grado de madurez,
tal como se presenta en la tabla 1 se estableció la siguiente escala de
medición:
Tabla 1. Escala de medición del grado de madurez de ITIL
Esta guía ayuda para realizar las entrevistas y expresar el grado de
madurez de los diferentes procesos de ITIL y los temas relacionados.
La escala anterior debe aparecer en el informe final del estudio, con el
fin que se obtenga un significado claro de los resultados.
Adicional a esta escala de medición de la encuesta, se incluye en el
cuestionario un campo de observaciones, orientado a registrar
comentarios como complemento a cada pregunta, con el fin de obtener
información sobre la puntuación. Algunos de estos comentarios pueden
ser: evidencias que soporten las calificaciones, detalles cualitativos
17
relacionados con la pregunta, herramientas usadas, detalles de
documentación registrada, frecuencia de la actividad, responsables,
etc.
Esta escala de medición de la encuesta permitirá establecer una
radiografía del grado de madurez de cada proceso, identificando
detalles cuantitativos y cualitativos, información de aspectos
satisfactorios, puntos a mejorar, pistas de mejora e información a tener
en cuenta en la implementación en los procesos.
Con los resultados de la encuesta también se podrá obtener
información tangible de aspectos técnicos de la operación de gestión
de servicios, detalles de los procesos existentes, aspectos de la gestión
financiera, organizacional, recursos, permitiendo así tener un soporte
importante para el análisis y definición del enfoque de los procesos a
implementar, basados en aspectos organizacionales y operativos
reales. (Lozano Sandobal & Rodriguez Mejía, 2011)
Calificación
La calificación de la evaluación incluye aspectos cualitativos y
cuantitativos que deben quedar debidamente registrados en la
encuesta así:
Calificación cuantitativa
La calificación cuantitativa es la que determinaría el grado de madurez
de los procesos y se obtiene usando la escala de medición definida en
la tabla 1.
Para obtener valores más reales en la calificación se le asigna a cada
pregunta un peso del proceso y subproceso evaluado basados en el
impacto e importancia que se tiene dentro del ciclo de vida del servicio
que se está evaluando.
Al obtener la calificación en cada ítem, se debe multiplicar por el peso,
obteniendo así un valor o calificación del ítem y del subproceso.
La calificación de los ítems se calculará promediando las calificaciones
dadas por los ítems y por los evaluados, posteriormente este promedio
se debe multiplicar por el peso dado al ítem, determinando de esta
forma la calificación a todos los ítems.
18
Calificación cualitativa:
La calificación cualitativa, proporciona información importante que
permite conocer detalles de la calificación cuantitativa dada al ítem
evaluado. Aunque esta información no da el valor real del grado de
madurez, ofrece información importante y complementaria para la
calificación y ofrece información valiosa a la hora de establecer la
estrategia de implementación del proceso evaluado.
Teniendo en cuenta lo anterior, dentro del formato del cuestionario se
dispuso de un campo para realizar observaciones complementarias a
las preguntas, donde se registrará información como evidencias,
responsables, descripción de informes, frecuencias, indicadores,
reportes, indicadores, etc.
Cuestionario de evaluación
A continuación se describe el detalle del cuestionario elaborado para
determinar el grado de madurez de los procesos ITIL de una
organización, detallando cada ítem a calificar y sus respectivos pesos
en los diferentes procesos.
19
Tabla 2. Cuestionario grado de madurez proceso Estrategia de Servicio
ITEM
ACTIVIDADES
Peso
(%)
1 Gestión de la cartera de servicios 50
1.1 Hay Relación entre los planes de negocio y las estrategias de los servicios de TI 5
1.2 Existe definición y documentación de la cartera de servicios 15
1.3
Se tienen definidos los objetivos y expectativas de desempeño hacia el servicio de los
15
Clientes
1.4 Se identifican, seleccionan y priorizan oportunidades de servicio 10
1.5 Se evalúan con frecuencia el cumplimiento de los objetivos de los servicios de TI 10
1.6 La cartera de servicios esta asociadas a las áreas funcionales del negocio 5
1.7 Existe clasificación de tipos de proveedores por servicio 10
1.7 Está definido el Portafolio de Servicios 20
1.8 Los retos, riesgos y factores críticos de éxito de los procesos están documentados 10
20
PUNTAJE 100
2 Gestión Financiera 25
2.1 Se realiza un adecuado manejo de costos y riesgos asociados a la cartera de
servicios 15
2.2 Existe planeación y control de presupuesto para la prestación de los servicios de TI 25
2.3
Existe centro de costos asignados a las áreas del negocio para la prestación de los
10
servicios o se realiza cobros por los servicios de TI (Asignación costo / incidente)
Dentro del servicio, hay clasificadores que designan el propósito final del costo
2.4 (Capital/operacional, Directo/indirecto, Fijo/variable, Unidades de coste, Recurso 20
humano/equipos)
2.5 Existe una implementación del procesos de gestión financiera de los servicios 30
PUNTAJE 100
3 Gestión de la demanda 25
3.1 Con frecuencia se evalúa el estado de la demanda de los servicios 15
21
3.2 Hay una definición clara de las áreas usuarias versus servicios prestados 20
3.3 Permanentemente se realiza análisis de patrones de actividades del negocio 10
3.4 Con frecuencia se identifican, seleccionan y priorizan oportunidades de servicios 15
3.5 Los servicios se priorizan de acuerdo al activos estratégico de la organización 20
3.5
Existe la definición del rol de atención al cliente que evalúa permanentemente la
20
satisfacción y necesidades de las áreas usuarias
PUNTAJE 100
Tabla 3. Cuestionario grado de madurez proceso Diseño de Servicio
ITEM
PROCESO, ACTIVIDAD, ASPECTO
Peso
(%)
5 Gestión de los proveedores 5
5.1 Existe una base de datos de proveedores y contratos 15%
5.2 Está definido el procesos de selección y contratación de servicios de TI 30%
22
5.3
Se realiza un procesos de seguimiento y medición del comportamiento de los
15%
proveedores basados en métricas de desempeño
5.4
Los proveedores se categorizan por valor de importancia contra riesgo e impacto
15%
(estratégicos, tácticos, mecánica, operacionales)
5.5.
El proceso de compras está alineado con la estrategia, procesos, términos estándar y
25%
condiciones de los abastecimientos corporativos
PUNTAJE 100
6 Gestión de la capacidad 10
6.1 Existen métricas definidas para medir la eficiencia de los procesos de servicio 20%
6.2 Se implementan medidas proactivas para mejorar el rendimiento de los servicios 15%
6.3 Se tiene definido un plan de capacidad que refleje las necesidades actuales y
futuras 15%
6.4
La planeación tecnológica se realiza basados en la capacidad actual y futura de los
30%
servicios de TI
Se lleva un registro y se realiza análisis del monitoreo del rendimiento de los servicios,
23
6.5 para asegurar una capacidad adecuada de TI para alcanzar los niveles de servicio 20%
satisfactorio de los clientes
6.6 Está definido y documentado la máxima capacidad actual de cada componente 20%
PUNTAJE 100
7 Gestión de la continuidad de los servicios de TI 15
7.1
Los planes de continuidad y recuperación de servicios de TI están documentados,
30%
actualizados y probados
7.2
Se realiza con frecuencia un análisis de riesgos e impacto del negocio para
asegurar que
20%
los planes de continuidad permitan mantener la operación del mismo
7.3
Se asesora a las demás áreas del negocio sobre gestión del riesgo y asuntos
relacionados
20%
con la continuidad y recuperación
7.4 Existe presupuesto asignado a los planes de continuidad 15%
7.5
Existe un plan de comunicación, educación, concientización y entrenamientos del
plan
15%
de continuidad hacia las áreas
24
PUNTAJE 100
Mejoras identificadas en Operación del servicio
Los resultado identificados dentro del progreso de la operación de
servicio en la universidad ICESI se observa que ya se cuenta con un
proceso de documentado de gestión de incidentes, para el caso de la
definición del rol de Incident manager, está en proceso de
implementación y divulgación. Se han definido las responsabilidades de
varios roles dentro de la dirección.
Dentro de la detección y registro se observa buena consistencia en las
actividades de gestión de incidencias y Service Desk, y mejoras en que
los registros de incidentes se incluyen información del ítem de
configuración y las inconsistencias son reportadas al Configuration
Manager. Se elaboró un formato para el reporte de incidentes que se
generan vía e-mail.
En la clasificación y soporte inicial se formalizó la categorización de
incidentes al momento del registro, así mismo el punto único de
contacto define la prioridad del incidente. Dentro de las mejoras se
registraron los diferentes grupos solucionadores en la herramienta.
Dentro de la investigación se estableció como norma de gestión de
incidentes realizar documentación del incidente y actualizar su estado,
de tal forma que se refleje la situación actual del incidente. La atención
de los incidentes se realiza por orden de prioridad, así como revisar los
errores conocidos para la solución de los incidentes.
Con respecto a la solución de los incidentes se observó mejor control
en el registro de fecha y hora de solución, el cual está acorde con la
solución de los caso.
El Incident manager detecta y escala las fallas del proceso de gestión
de incidencias, así como establecer métricas para medir el procesos, lo
que sirve para impulsar la mejora continua.
Se documentó la matriz de escalamiento funcional para IM, así como se
definieron los usuarios VIP dentro de la universidad.
25
El proceso Service Desk mantiene un buen nivel de madurez en la
mayoría de sus actividades y observa mejor comunicación con las áreas
usuarias al mantenerlos informados sobre el avance de los casos.
El proceso de Problem Manager también presentó una mejora
importante debida principalmente a la elaboración del proceso,
definición del rol, la documentación y tratamiento que se le dio a los
errores conocidos, lo cual agiliza la solución de incidencias. También se
identificó los escalamientos de problemas desde el incidente manager
al Problem Manager de incidentes con causa raíz desconocida, con lo
cual se logra obtener soluciones temporales. (Lozano Sandobal &
Rodriguez Mejía, 2011)
Mejoras identificadas en Mejora continua
El progreso obtenido en el grado de madurez de ITIL en la universidad ICESI en los diferentes ciclos de vida de servicio, se generan principalmente por las directrices de la dirección y el compromiso de todo el equipo de trabajo de la dirección SYRI. Diferentes iniciativas de implementación de mejoras en los procesos se originaron desde el área de proceso, y aportes importantes de los diferentes gestores de proceso definidos dentro del proyecto.
En el proceso de elaboración de los procesos y en la implementación de mejoras de otros procesos se aprendió de las lecciones aprendidas en todos los procesos, alineando los servicios de TI con las necesidades del negocio. En este proceso se evaluaron los logros obtenidos. El trabajo en equipo y las frecuentes reuniones del equipo de trabajo de SYRI, permitía revisar el cumplimiento de los objetivos para definir estrategias de mejora para la prestación de servicios de TI. Estas estrategias contaban con objetivos claros a los cuales se les hacía seguimiento con métricas bien definidas. Como línea base se contaba con evidencias y registros con los cuales se podía validar el progreso en el tiempo con iniciativas establecidas por el área de procesos. Para el procesamiento de los datos se tenía una clara definición de los ejecutores, formatos, frecuencias, precisión y herramientas utilizadas. Las estadísticas generadas de estos procesos se realizan un análisis de tendencias, objetivos alcanzados y acciones correctivas. (Lozano Sandobal & Rodriguez Mejía, 2011)
Recomendaciones
Mediante el proceso de mejoras que se realizó en la universidad ICESI
se identificaron diversos aspectos que no presentaron avances y que
deben ser incluidos en futuros planes de mejora, dado que puede llegar
26
afectar la gestión del servicio. A continuación se relacionan algunos
procesos y funciones que se deben mejorar:
Debe extenderse el proceso de Change Manager hacia el área de
Diseño y Desarrollo para tener un mejor control y evaluación de impacto
de los pasos a producción.
Es necesario implementar el proceso de Configuration Manager
elaborado en este proyecto y gestionar de forma prioritaria la
adquisición de una herramienta que permita descubrir automáticamente
ítems de configuración de la universidad para tener un mejor control de
activos, y relacionarlos con la gestión de incidentes y gestión de
cambios.
Es indispensable elaborar, implementar y divulgar a lo largo de la
universidad la política de seguridad y uso de los recursos informáticos
basados en la norma 27000. Este plan debe ir acompañado de la
elaboración de proceso básico de Security Management.
Para solucionar incidentes sin causa raíz identificada y reducir
incidentes reincidentes, la dirección SYRI requiere implementar el
proceso de Problem Manager elaborado en este proyecto.
Tomando en consideración que durante la interrupción imprevista de la
actividad de la universidad, originada por un incidente que puedan
afectar la operación académica y administrativa, se debe elaborar e
implementar un proceso de Continuity Management, en el cual deben
participar e involucrarse las áreas académicas y administrativas y contar
con todo el apoyo de la rectoría.
El procedimiento de Releasse Management debe ser cuidadosamente
documentado para que todas las partes conozcan sus tareas y
responsabilidades específicas. Se debe asegurar una clara relación
entre Releasse Management con Test Management, Change
Management y Configuration Management.
Para tener éxito en la ejecución del plan anterior, se requiere la
participación activa del equipo de trabajo la dirección SYRI, en la
elaboración e implementación de procesos importantes para y
mejoramiento de la cultura en ITIL.
Luego de la ejecución del plan anterior se debe realizar una nueva
evaluación del grado de madurez para analizar avances en los procesos
27
implementados y las mejoras reflejadas en otros procesos. Posterior a
la tercera evaluación se determinaran procesos candidatos que deben
ser sometidos a mejoras, con el fin de continuar con el proceso PHVA.
Con las recomendaciones mencionadas se puede alcanzar un grado de
madurez óptimo de acuerdo con las necesidades de la universidad
ICESI. (Lozano Sandobal & Rodriguez Mejía, 2011)
28
2. CAPITULO II MARCO TEORICO
2.1 Fundamento Teórico
La disponibilidad de los servicios que ofrecen y la atención oportuna a las
peticiones de los clientes o usuarios, para las empresas hoy en día es de vital
importancia; en relación a lo antes mencionado se encuentra la importancia que
han obtenido las Tecnologías de Información las cuales han dejado de ser
simples herramientas para convertirse en factores claves para el cumplimiento
de los objetivos estratégicos de las compañías, en consecuencia es necesario
alinear los objetivos de las áreas de TI en concordancia a los objetivos
organizacionales. (Helkyn Coello Blog, 2008)
En la década de los 70’s las tecnologías y sistemas de información estaban
orientados en su mayoría al desarrollo de aplicaciones de software, las cuales
eran implementaban con el fin de brindar soluciones para el negocio, que le
permitieran alcanzar ventajas competitivas; estas aplicaciones debían ser
administradas, convirtiéndose esta administración en un servicio que debía
brindarse al negocio adicional al del desarrollo de aplicaciones de software.
(Helkyn Coello Blog, 2008)
Si continuamos avanzando en el tiempo, en la década de los 80’s las pequeñas
y grandes empresas han utilizado las tecnologías de la información para
controlar y tener mayor gestión dentro de las aplicaciones que iban
desarrollando brindándoles mayores beneficios en el negocio de cada empresa.
(Helkyn Coello Blog, 2008)
En la misma década en el Reino Unido, nació la necesidad de incrementar la
eficiencia de los servicios prestados por empresas de TI internas y externas,
para buscar la solución a este requerimiento se estandariza y documenta las
mejores prácticas en cuanto a la gestión de servicios logrando que las
organizaciones tengan un mejor rendimiento y éxito en las organizaciones.
Con la documentación realizada sobre la gestión de servicios de TI, se
escribieron libros en los cuales se presentaba un pequeño acercamiento al
término. A esta documentación se le llamó Biblioteca de Infraestructura de
Tecnologías de Información, ITIL (Information Technology Infrastructure Library)
(Helkyn Coello Blog, 2008)
29
Existe en la actualidad diversos marcos de trabajo y mejores prácticas que se
busca ayudar a las empresas en su área de TI con su propia gestión, por lo que
las TI se conviertan en una ventaja para las organizaciones y son vistas como
inversiones con retorno a diferencia de ser gastos necesarios. (Helkyn Coello
Blog, 2008)
Su implementación se ha convertido en una necesidad ya que estas prácticas
son estándares de la industria y para las empresas que desean gestionar TI
adecuadamente y lograr ventajas de negocio su implementación es de
importancia.
Para los estándares de calidad en las empresas nos sirve las buenas practicas
TI como guía de buenas prácticas para llevar la mejora continua de los procesos
en los servicios TI. El tipo de guía que requiera cada organización varía en
función de su fase de desarrollo. (Bon, 2008)
Dependiendo de la fase en la que se encuentre la organización se clasifican las
metodologías en los siguientes grupos:
• Metodología para la Gestión de Proyectos
• Metodología para el Desarrollo de Software
• Metodología para la Gestión de Servicios TI
30
Metodología para la Gestión de Proyectos
La función de una metodología de gestión de proyectos es proporcionar una
serie de “buenas prácticas” que optimicen la ejecución de un proyecto. Se
entiende por “buenas prácticas para la gestión de proyectos” el conjunto de
herramientas, técnicas y habilidades que pueden aumentar las posibilidades de
éxito de un proyecto y sobre las que existe un acuerdo general en su utilidad
para cualquier tipo de proyecto que se desee llevar a cabo. (Bon, 2008)
Dentro de esta categoría existen metodologías Como PMBoK de PMI (Project
Management Institute), PRINCE2 de APM (Association for Project
Management), NCSPM de AIPM (Australian Institute for Project Management),
o ICB de IPMA (International Project Management Association). La más
reconocida de las anteriores tanto por su difusión como su uso es PMBoK. (J,
2006)
Metodología para el Desarrollo de Software
La metodología empleada para el desarrollo de software son procesos y procedimientos empleados con el fin de realizar una metodología que garantizar la eficacia y la eficiencia en el proceso de generación de software. (Bon, 2008)
31
Metodología para la Gestión de Servicios TI
El enfoque de la Gestión de Servicios de TI es en cómo llevar a cabo la entrega
de estos servicios, ya que el negocio se apoya en las TI para cumplir los
objetivos de la empresa.
Estas metodologías, tienen como objetivo asegurar que los servicios de TI
cubren las necesidades del negocio, para poder predecir tanto el impacto que
la Tecnología puede tener sobre el Negocio, como los cambios que el Negocio
exige a la Tecnología de cada organización. (Bon, 2008)
Muchas de estas metodologías se han consolidado en el mercado. Entre estas,
ITIL, en sus versiones 2 y 3, el estándar ISO 20000, que se creó a raíz de ITIL,
la ISO 27001 relacionada con la seguridad de la información, CMMI en su
totalidad (Development- Services-Adquisition), y COBIT como marco de gestión
más enfocado a alinear los objetivos del negocio con las tareas de los
departamentos TI. (Bon, 2008)
2.1.1 ITIL
El marco de referencia para la Gestión de los Servicios de TI es ITIL (Information
Tecnology Infraestructure Library), compuesto por un conjunto de documentos
donde se describen las mejores prácticas para tener una buena gestión con los
servicios TI en las empresas.
ITIL, es una guía que propone las buenas prácticas y procesos de TI
correctamente y de cómo se deben relacionar para que el flujo de la información
entre ellos fluya continuamente. (Integrated Technologies Limited, 2016)
2.1.2 Antecedentes de ITIL
La Biblioteca de la Infraestructura de Tecnología de la Información, surgió, cuando el gobierno británico solicito a la CCTA (Agencia Central de Telecomunicaciones y Computación) que en la actualidad es el Ministerio de Comercio, que desarrollara una metodología estándar que certifica una entrega eficiente de los servicios de TI y la solución del desarrollo y publicación de un conjunto de buenas prácticas se denomina ITIL, dado a finales de los años 80. (Gila, 2011)
32
La versión original de ITIL en sus inicios fue muy prolongada ya que constaba de 40 libros, y fue publicada en 1989 alcanzando gran popularidad a mediados de los 90, época en la cual se dio inicio a la segunda revisión, con el objetivo de hacer de ITIL más accesible y consolidar los libros en dos grupos que cubrieran los procesos relacionados, esta revisión se sostuvo por 10 años aproximadamente y se concluyó con una nueva versión 2 de ITIL en el año 2004, la cual constaba inicialmente de 7 libros y posteriormente se le agregaron 2 más quedando conformada por 9 libros (Gila, 2011) :
Gestión de Servicios de TI
1. Entrega de Servicios 2. Soporte a Servicios 3. Otras guías operacionales 4. Gestión de Infraestructuras ICT 5. Gestión de la Seguridad 6. La perspectiva de Negocio 6.Gestión de Aplicaciones 7. Gestión de Software 8. Planificando la Implementación de la Gestión de Servicios 9. Implementación de ITIL a pequeña escala
La publicación de la versión 3 de ITIL fue en mayo de 2007, esta versión está creada por 5 libros y la principal diferencia con la versión 2 está en la visión del ciclo de vida del servicio, que propone la versión 3. ITIL V2 se orienta en buenas prácticas de gestión sencillas y asociadas en Provisión, Soporte y Seguridad; ITIL V3 brindará un procedimiento para mantener el servicio TI en un ciclo óptimo para el negocio, mejorando diseño, transición y operación. Los procesos y los servicios son constantemente monitorizados, analizados y mejorados, de esta forma se logra una evolución lenta pero adecuadamente (Gila, 2011).
En relación con la versión 2 el contenido de esta versión es más amplio y complejo supone una fiabilidad y disponibilidad de los servicios, una mejor relación con los usuarios y permite agilizar los cambios en la organización, debido que todo planteamiento es consistente y esta normalizado (Gila, 2011).
33
2.1.3 Estructura de ITIL
La estructura propuesta por ITIL tiene como núcleo principal el ciclo de
vida del servicio y las relaciones entre los componentes de la gestión del
servicio. El ciclo de vida del servicio está compuesto de 5 fases, estas
fases las conforman la biblioteca oficial de ITIL junto con cuatro
publicaciones complementarias, cada una de las fases conforman un libro
compuesto por principios de servicio, procesos, roles y medidas de
desempeño; por lo tanto, las cinco publicaciones del Ciclo de Vida del
Servicio son:
Estrategia del servicio (SS).
Diseño del servicio (SD).
Transición del servicio (ST).
Operación del servicio (SO).
Mejora continua del servicio (CSI).
Y las publicaciones complementarias son:
Guía de introducción
Guía sobre elementos claves
Ayudas para cualificación
White Papers
2.1.4 Ciclo de vida del servicio
Los objetivos del negocio determinan la estrategia de TI, mediante el
diseño de soluciones basada en servicios, los cuales se testean e
implementan para soportar las necesidades del negocio. La efectividad y
rendimiento de estos servicios deben a su vez estar soportados por
niveles acordados con el negocio y por un ciclo de mejoramiento
continuo que busca asegurar la competitividad, efectividad y eficiencia.
Este ciclo de vida es un modelo de organización y ofrece información
sobre la estructura de gestión de servicio y los diferentes componentes.
Además describe las relaciones y cambios que se producen entre estos
componentes.
34
2.1.5 Fases del Ciclo de Vida del Servicio
El Ciclo de Vida del Servicio consta de cinco fases que se corresponden con los nuevos libros de ITIL
A continuación se describen las fases del ciclo de vida mostrada en la figura 2.
Figura 2. Fases ciclo de vida de los servicios (3 Digits.es, 2016)
35
2.1.6 Estrategia del servicio
Esta fase se encarga de la integración entre la estrategia del TI y la
estrategia de negocio; se determinan en la clase de servicios que tienen
que ofrecerse y los estándares y políticas que serán utilizados para
diseñar dichos servicios. Propone una guía de cómo diseñar, desarrollar
e implementar servicios como un activo estratégico (Bon, 2008)
La estrategia de servicios se basa en las 4 PS (Bon, 2008):
Perspectiva: La visión de la situación. Tener una visión y un enfoque claros.
Posición: adoptar una postura bien definida
Plan: formarse una idea clara de cómo debe desarrollarse la organización
Patrón: mantener la coherencia de decisiones y acciones
La estrategia de servicios abarca los siguientes procesos:
Gestión financiera
Generación de la estrategia
Gestión de la demanda
Gestión del portafolio de servicios
2.1.7 Diseño del servicio
En esta fase se establecen o cambian los servicios y arquitectura de infraestructura, combinándose aplicaciones, sistemas y procesos con proveedores y socios. Lo anterior se lleva a cabo teniendo en cuenta 5 aspecto principales: la administración del portafolio de servicios, la identificación de los requerimientos del negocio, descripción de los requerimientos del servicio y diseño de servicios, el diseño de la arquitectura tecnológica, el diseño de procesos y el diseño de medidas.
La fase de diseño de servicios abarca los siguientes procesos:
Gestión del catálogo de servicios
Gestión del nivel de servicios (SLM)
Gestión de la capacidad
Gestión de la disponibilidad Gestión de la continuidad del servicio (ITSCM)
36
Gestión de la seguridad
Gestión de proveedores
2.1.8 Transición del servicio
La fase de Transición del servicio incluye la gestión y coordinación de los
procesos, métodos y funciones necesarios para la construcción, pruebas
e implementación de un nuevo servicio o una nueva versión de un
servicio ya existente, según las especificaciones del cliente, con el
objetivo de llevar un control e información de los cambios realizados,
mejorar el impacto sobre el ambiente de producción y aumentar la
satisfacción del cliente durante el proceso de transición (Bon, 2008).
Transición del Servicio abarca los siguientes procesos:
Planificación y Soporte de la Transición
Gestión de Cambios
Gestión de Configuración y Activos del Servicio SACM
Gestión de versiones y Despliegues
Validación y pruebas del servicio
Evaluación
Gestión del Conocimiento
37
2.1.9 Operación del servicio
Esta es la fase de puesta en producción y operación de los servicios de TI en donde se busca entregar y soportar los servicios de una manera efectiva y eficiente, de forma que genere valor tanto a clientes como a los proveedores de servicios.
Debe garantizar una operación continua, efectiva y eficiente en la entrega y soporte, mantener estabilidad, además de proveer las guías y mejores prácticas en todos los aspectos de manejo de la operación diaria de los servicios de TI. (Bon, 2008)
La operación del servicio abarca los siguientes procesos:
Gestión de Eventos
Gestión de Incidencias
Gestión de Peticiones
Gestión de Problemas
Gestión de accesos
Y las siguientes Funciones:
Service Desk (Centro de Servicio al Usuario)
Gestión Técnica
Gestión de la Operación de TI
Gestión de Aplicaciones
2.1.10 Mejoramiento Continuo
En esta fase se identifican mejoras en la gestión de servicios de TI,
teniendo como premisa la creación del valor para el cliente enlazando
esfuerzos de mejora y resultados entre la estrategia, el diseño, la
transición y la operación del servicio, y de esta manera identificar las
oportunidades para trabajar en las debilidades o fallas dentro de
cualquiera de estas etapas. Son esenciales en esta tarea la medición y
el análisis, ya que con estos se puede identificar los servicios que son
rentables y aquellos que se pueden mejorar (Bon, 2008).
Mejoramiento continuo abarca los siguientes procesos
Medición del Servicio
Proceso de mejora de CSI
Informes de Servicio
38
3. CAPITULO III: DESARROLLO DE LA SOLUCION
A continuación se explicara el modelo para la implementación de gestión de
cambios utilizando buenas prácticas de ITIL, Donde se realiza el proceso propio
de corporación Grupo Romero, debido a que la complejidad y la flexibilidad como
se manejas las empresas corporativa es muy volátil ante el negocio y trabajo 24 x
7, se determinó que dicho modelo no es aplicable a cualquier organización es una
propuesta original diseñada y elaborada por los autores de este proyecto basados
en la experiencia propia en cada empresa de Corporacion Grupo Romero, el cual
hace un aporte importante al conocimiento en lo relacionado con la gestión de
servicios de TI.
El modelo y los Responsables han sido patrocinados por el Stakholder.
Se define los:
1. Responsabilidades
Responsable Actividad
Iniciador del Cambio
Persona autorizada para solicitar un requerimiento de
cambio detallando el alcance, el negocio afectado y la
justificación del mismo mediante formato.
Gestor del Cambio Único responsable del Proceso, dedicado a velar que
cada solicitud de cambio cumpla el flujo
Ilustración 3.1 Modelo de proceso de Cambio
Fuente: Elaboración Propia
39
correspondiente del proceso. Tiene como
responsabilidad principal evitar que se ejecuten
cambios sin la autorización necesaria, por ello se
apoya del Comité Asesor de Cambio (CAC) que él
mismo convoca y preside para el tema de
autorización.
Coordinador del Cambio
Persona que coordina la planificación, ejecución y
pruebas de los cambios. Se plantea tener un
coordinador por grupo de activos de cambio. Por
ejemplo un coordinador de cambios para SAP,
servidores, switches o enlaces.
Comité Asesor de Cambio
(CAC)
Grupo conformado para la revisión del análisis de
cambios a nivel de negocio y gerencial. Apoya en la
revisión del cumplimiento de flujo y la difusión de los
cambios.
Comité Técnico del
Cambio (CTC)
Grupo conformado para representar a las principales
áreas de la gestión de servicios de TI y que apoyan al
gestor de cambio en la revisión de los planes y análisis
de riesgo, en base al análisis se aprueban los
cambios.
Ejecutor del Cambio
Encargado de realizar las tareas e implementar el
cambio, elabora el plan de ejecución y rollback acorde
a sus tiempos para que estos sean validados por el
CAC.
Definición de Cambios
Se define el cambio como cualquier adición, modificación o eliminación de hardware, software, redes, aplicaciones, ambientes de tecnología de información y sistemas que formen parte del servicio brindado por CSGR a las demás empresas del Grupo.
40
Solicitud de Requerimiento de Cambio:
a. Los requerimientos de cambios pueden ser registrados desde el intranet corporativo ingresando a la siguiente dirección web: http://ws.gromero.com.pe/, se anexa una guía para el ingreso y registro de la solicitud de cambio. (Anexo 2 - Guía de Registro Solicitud de Cambio).
b. Tener en consideración que existe un mínimo de días de preparación para la ejecución de un cambio que corre a partir de la creación de la solicitud, por ello es importante la fecha en la cual se registra en el punto 4 se describen los tipos de cambio y los días de preparación mínima.
Registro de solicitud de Cambio
3.3.1 Ingreso al Formulario de Cambios
3.3.1.1 Formulario de Cambios:
1. El formulario de registro de solicitud de cambio agrupa los campos en
tres secciones:
a. Información del solicitante: información básica sobre el solicitante:
nombre, correo y área.
b. Detalles del cambio: Campos que sirven para identificar y tipificar el
cambio según su impacto y justificación.
c. Información adicional: Campos para la redacción más detallada de lo
que se va cambiar y porque se necesita cambiar.
El formulario contiene la información necesaria para evaluar el impacto
y la justificación de un cambio, además de brindar información
estadística y de asociación entre cambios.
41
1.1. Información del Solicitante:
Nro. Cambio Descripción
1 Nombre de Solicitante Pre-cargado el nombre del solicitante de la cuenta
de red.
2 E-mail de contacto Pre-cargado el correo del solicitante de la cuenta de
red.
3 Área Solicitante Se debe seleccionar el área del solicitante,
actualmente se tienen estas opciones: Aplicaciones (área de infraestructura), Colaboración, Dominios, Integración, Networking, Plataformas, Proyectos, Red Corporativa, Seguridad, Servicio al Usuario y Otros.
Tabla 3.1 Detalle Registro
Fuente: Elaboración Propia
1
2
3
Ilustración 3.2 Información del Solicitante
Fuente: Elaboración Propia
42
1.2. Detalles del Cambio
Ilustración 3.3 Detalles del Cambio
Fuente: Elaboración Propia
4 5
6 7
8 9
10 11
12 13
14 15
43
Nro. Cambio Descripción
4 Título del Cambio Breve descripción de no más 10 líneas sobre el cambio.
5 Razón del
Cambio
Razón por la cual se desea hacer el cambio.
6 Origen del
Cambio
Origen del cambio pudiendo ser algún proceso, por el
responsable del activo, proveedores o algún proyecto.
7 Código Asociado Código para asociar cambios con tickets de incidentes,
problemas, proyectos o con otros cambios.
8 Empresa(s) Empresa afectada por el cambio, en caso fuera más de una
empresa está la opción corporativa.
9 Sociedad Para describir mejor la sede o el país de afectación por el
cambio está la opción sociedad, donde para cada empresa
hay una sociedad genérica si no se está bien definido la
sociedad.
10 Fecha Propuesta
de Ejecución
Fecha sugerida para la ejecución del cambio, no
necesariamente se tome esa fecha.
11 Impacto Estimado Impacto del cambio entre: Menor, Medio y Mayor
12 Sistema Sistema o servicio afectado por el cambio.
13 Ambiente Ambiente afectado del cambio: desarrollo, calidad,
contingencia o producción
14 Prioridad
Propuesta
Prioridad de acuerdo a la necesidad de hacer el cambio:
Baja, Medio, Alta e Inmediata.
15 Genera
Indisponibilidad
Detallar si el cambio generará indisponibilidad en algún
servicio productivo.
Tabla 3.2 Descripción Detalles del cambio
Fuente: Elaboración Propia
44
Ilustración 3.4 Información Adicional
Fuente: Elaboración Propia
Nro. Cambio Descripción
16 Reunión Previa Se tuvo reuniones previas antes de la ejecución.
17 Áreas involucradas Áreas que deben participar o deben estar considerados en
el cambio.
18 Descripción del cambio.
Descripción detallada de lo que se quiere cambiar, cuando y donde.
19 Razón/Justificación del Cambio.
Descripción de la razón y justificación del cambio, detallando lo que sucedería al no realizar el cambio.
20 Criterios de aceptación del Cambio.
Descripción del activo de TI luego de la implementación del cambio de forma que se valide el cambio.
Tabla 3.3 Descripción de campos Información Adicional
Fuente: Elaboración Propia
16
17
18
19
20
45
Priorización de Cambios
Promover la priorización de cambios para una mejor atención de los
requerimientos de Cambios y Servicios. Por ello se distinguen 3 tipos
de cambios:
a. Cambio de Emergencia: Cambios de prioridad inmediata que son
utilizados para resolver un incidente o una necesidad de forma
urgente.
b. Cambio Normal: Son los cambios que siguen un flujo de trabajo
uniforme y esquematizado. Para estos cambios se diseñan
actividades que los mantendrán bajo control.
c. Cambio de Excepción: Cambios que por motivos particulares no
pueden cumplir el flujo normal de cambios a causa de una planeación
deficiente, se debe reportar y tratar de minimizar este tipo de
cambios. Al igual que los cambios de emergencia requiere un tipo de
autorización especial.
Categorización Cambios Normales
La categorización dentro de los cambios normales, se evalúa de acuerdo a la
complejidad del cambio y el impacto al negocio. Se tiene las siguientes
categorías:
a. Crítico: Son los cambios que tienen el más alto factor de riesgo así como el potencial de un impacto crítico sobre los servicios de TI. Estos cambios normalmente requieren un mayor tiempo de planeación pues suele ser necesario la intervención de múltiples áreas. Tiempo mínimo de Preparación: 14 días.
b. Mayor: Son cambio importantes que tiene una clasificación de riesgo alta y una probabilidad de impacto significativo en los servicios de TI. Tiempo mínimo de Preparación: 8 días.
c. Medio: Tienen una categoría media en el análisis de riesgo y un mínimo impacto en los Servicios de TI. Estos cambios requieren planificación, calendarización y actividades de coordinación entre equipos. Tiempo mínimo de Preparación: 2 días.
d. Menor: Cambios menores que no implican un riesgo mayor, potencialmente no tienen un impacto en los Servicios de TI. Generalmente implica Planificación, programación y coordinación de actividades dentro de un solo grupo. Tiempo mínimo de Preparación: 1 día.
46
e. Usual del Negocio: Procedimiento probado y documentado. Los cambios en esta categoría también puede ser parte de las actividades de mantenimiento en curso. Tiempo mínimo de Preparación: 0 día.
Método de Categorización Cambio Normales:
Para evaluar la categoría de un cambio normal se debe responder a una
encuesta de 6 preguntas que mide el impacto del cambio, los recursos y
esfuerzo requerido para realizar el cambio, y la dificultad para deshacer el
cambio.
47
Cuestionario para Categorización de Cambios Normales
Pregunta Respuesta Puntaje
1. Número de usuarios (impactos por la implementación o vuelta atrás)
Más de 150 usuarios 5
De 50 a 150 usuarios 4
De 2 a 49 usuarios 3
Un usuario 2
Ningún usuario 1
2. Empresas afectados (impactados por la implementación o vuelta atrás)
Corporativo 4
2 empresas 3
Una empresa 2
Sin impacto para las empresas 1
3. Recursos requeridos para preparar/implementación
3 o más grupos de soporte 4
2 grupos de soporte 3
Más de una persona del mismo grupo de soporte 2
Una persona 1
4. Esfuerzo de preparación
6 días o más 5
De 2 a 5 días 4
1 día 3
Menos de 1 día 2
1 hora o menos 1
5. Duración de la implementación
Más de 2 horas (con o sin ventana) 5
De 1 a 2 horas (con ventana) 4
Menos de 1 hora ( con ventana) 3
Menos de 1 hora 2
Implementación inmediata 1
6. Dificultad para volver atrás
Mayor a 2 horas 5
De 1 a 2 horas 4
Razonable ( 1 hora o menos) 3
Fácil de volver atrás ( 1 hora o menos) 2
Puede ser vuelto atrás inmediatamente 1 Tabla 3.4 Cuestionario Categorización Cambios Normales Fuente: Elaboración Propia
48
Resultado de Probabilidad de Falla Si el valor total es
1. Crítico Mayor a 22
2. Mayor De 18 – 21
3. Medio De 14 - 17
4. Menor De 10 – 13
5. Usual del Negocio De 6 - 9 Tabla 3.5 Resultados Fuente: Elaboración Propia
Riesgos de Cambio
El riesgo de un cambio contiene dos dimensiones: Impacto y Probabilidad de Falla
a. Impacto: el impacto varía de acuerdo al impacto que puede tener en la tecnología, en el negocio o en cualquier factor crítico. Se encuentra directamente proporcional al Activo de TI que va hacer afectado.
b. Probabilidad: El riesgo de que un evento pueda ocurrir, la probabilidad varía entre bajo, medio y alto.
Pregunta Respuesta Puntaje
1. Número de usuarios (impactos por la implementación o vuelta atrás)
Más de 150 usuarios 5
De 50 a 150 usuarios 4
De 2 a 49 usuarios 3
Un usuario 2
Ningún usuario 1
2. Empresas afectados (impactados por la implementación o vuelta atrás)
Corporativo 4
2 empresas 3
Una empresa 2
Sin impacto para las empresas 1
3. Recursos requeridos para preparar/implementación
3 o más grupos de soporte 4
2 grupos de soporte 3
Más de una persona del mismo grupo de soporte 2
49
Una persona 1
4. Esfuerzo de preparación
6 días o más 5
De 2 a 5 días 4
1 día 3
Menos de 1 día 2
1 hora o menos 1
5. Duración de la implementación
Más de 2 horas (con o sin ventana) 5
De 1 a 2 horas (con ventana) 4
Menos de 1 hora ( con ventana) 3
Menos de 1 hora 2
Implementación inmediata 1
6. Dificultad para volver atrás
Mayor a 2 horas 5
De 1 a 2 horas 4
Razonable ( 1 hora o menos) 3
Fácil de volver atrás ( 1 hora o menos) 2
Puede ser vuelto atrás inmediatamente 1
Tabla 3.6 Evaluador de Riesgo
Fuente: Elaboración Propia
Resultado de Probabilidad de Falla Si el valor total es
1. Crítico Mayor a 22
2. Mayor De 18 – 21
3. Medio De 14 - 17
4. Menor De 10 – 13
5. Usual del Negocio De 6 - 9 Tabla 3.7 Resultados Criticidad
Fuente: Elaboración Propia
50
Aprobación de Cambios
La autorización del cambio es requerida para todos los cambios a excepción
de los cambios que se encuentran pre-aprobados (Cambios Usuales de
Negocio). La matriz de aprobación se adjunta en el Anexo 5. Los requisitos de
Aprobación se anexan al final del documento
Requisitos de Aprobación
Usu
al
de
Neg
oc
io*
Me
no
res
Me
dio
Ma
yo
res
Cri
tic
o
Em
erg
en
cia
Ex
ce
pc
ión
Formato Solicitud Completo X X X X X X
Fecha de Inicio y Fin Programados
X X X X X X
Plan de Comunicaciones X X X X X X
Plan de Trabajo X X X X
Plan de Contingencia X X X X
Plan de Pruebas X X X X
Análisis de Riesgo X X X X X
Ventana Aprobada Negocio X X X
Formato Solicitud Emergencia/Excepción
X X
Tabla 3.8 Requisitos de Aprobación
Fuente Elaboración Propia
*Los Cambios Usuales de Negocio tiene pre-elaborados los planes de comunicación, plan de trabajo, contingencia y análisis de riesgo por ello no se incluye en la matriz como un requisito para su aprobación.
51
Aprobación/Validación de Cambios de Emergencia
Para solicitar la aprobación de emergencia es necesario enviar un correo al
Gestor de Cambios describiendo el incidente y las acciones a realizar
utilizando el Formato de solicitud de emergencia (Anexo 9). Teniendo en
cuenta que en el correo se debe copiar exclusivamente al jefe inmediato y a la
Gestión de Incidentes y Problemas; y se debe notificar mediante llamada al
gestor de cambio sobre él envió de la solicitud.
A. Formato de Solicitud de Emergencia
Descripción del Incidente
Área/Solicitante
Área/Coordinador:
Descripción del Incidente:
Impacto del Incidente:
Indisponibilidad (SI/NO):
Ticket de Incidente:
Inicio de Indisponibilidad a causa del incidente (Fecha y Hora)
Comunicación con GIP
¿Error Conocido?
Descripción del Cambio
Breve descripción del Cambio:
Empresa(s) Afectada:
Servicio(s) Afectado:
Fecha\Hora Inicio
Fecha\Hora Fin
Tiempo de Solución (Estimado)
Riesgos:
Propuesta de Mitigación de Riesgo:
Tabla 3.9 Formato Solicitud Emergencia
52
B. Formato de Solicitud de Excepción
Descripción del Cambio
Breve descripción del Cambio:
Causa de la Excepción:
Consecuencia de pasar el cambio por el flujo normal:
Empresa(s) Afectada:
Servicio(s) Afectado:
Fecha\Hora Inicio
Fecha\Hora Fin
Tiempo de Solución (Estimado)
Riesgos (de realizar el cambio)
Propuesta de Mitigación de Riesgo:
Tabla 3.10 Formato Solicitud Excepción
*En caso de que en primera instancia no se ubique al Gestor de Cambios para la
gestión de la aprobación en un plazo de 10 minutos (Llamada Telefónica), se
procederá a solicitar la gestión al jefe de Incidentes y Problemas. Si en el caso de
que pasado los 5 minutos no se ubiquen al Jefe de Incidentes y Problemas se
procederá a solicitar directamente la aprobación de la ejecución al Aprobador de
Emergencia.
53
Aprobación Cambios de Excepción
Para solicitar la aprobación de cambios de excepción, el solicitante deberá enviar un correo al gestor de cambios con el formato de solicitud de excepción adjunto en el documento, en el cual se detalla el cambio y la causa que origine su urgencia. El gestor de cambio validara los detalles del cambio de excepción, sirviendo como primer filtro, para luego solicitar la aprobación. En caso que el aprobador tenga alguna duda u observación se contactara directamente con el solicitante del cambio para validar esos detalles.
Matriz de Aprobación I. Matriz de Aprobación
Matriz de Aprobaciones
Aprobación de
Excepción
Aprobación de
Emergencia
Comité Asesor
De Cambio
Comité Técnico
de Cambios
Gestor del
Cambio
Emergencia X
Excepción X
Crítico X
Mayor X
Medio X
Menor X
Tabla 3.11 Matriz de Aprobación
II. Matriz de Escalamiento para Cambios de Emergencia
Escalamiento Aprobador de Emergencia
1 Gerente de Infraestructura
2 Gerente de Aplicaciones
3 Gerente de Demanda
Tabla 3.12 Matriz de Escalamiento Cambios Emergencia
54
II. Matriz de Escalamiento para Cambios de Excepción
Escalamiento Aprobador de Excepción
1 Ambiente Productivo: VP Ambientes No Productivo: Gerente de Infraestructura
2 Definido por VP
Tabla 3.13 Matriz Escalamiento Cambios de Excepción
Aprobación de Cambios sobre Aplicaciones Criticas
Los Cambios sobre las aplicaciones críticas adicionalmente requieren la
aprobación del Vicepresidente Corporativo Sistemas y Servicios
compartidos. La cual debe ser solicitada por los responsables funcionales
mediante correo y llamada telefónica en donde se detalle el sustento y la
descripción del cambio, es necesario utilizar la lista de distribución anexada
al documento para él envío del correo.
55
Nro Aplicación Nro. Puesto
1 SMP
1 Vicepresidente Corporativo Sist. Y Serv. Compartidos
2 Gerente Corporativo de Desarrollo y Mantenimiento de Aplicaciones
3 Gerente Corporativo de Arquitectura, Infraestructura, Comunicaciones y Servicio al Usuario
4 Gerente Corporativo de Demanda
5 Gerente de Infraestructura
6 Gerente de Dominio Logística y Comercial
7 Jefe de Incidentes y Problemas
8 Jefe de Equipo CRM, Ptos. de Venta y Distribución
9 Experto CRM, Ptos. de Venta y Distribución
10 Gestor de Cambios
2 DEX
1 Vicepresidente Corporativo Sist. Y Serv. Compartidos
2 Gerente Corporativo de Desarrollo y Mantenimiento de Aplicaciones
3 Gerente Corporativo de Arquitectura, Infraestructura, Comunicaciones y Servicio al Usuario
4 Gerente Corporativo de Demanda
5 Gerente de Infraestructura
6 Gerente de Dominio Logística y Comercial
7 Jefe de Incidentes y Problemas
8 Jefe de Equipo CRM, Ptos de Venta y Distribución
9 Experto CRM, Ptos de Venta y Distribución
10 Gestor de Cambios Tabla 3.14 Aplicaciones
56
Comité Técnico de Cambio
El Comité Técnico de Cambio tiene como objetivo la revisión de los cambios
medios, mayores y críticos, enfocándose en la revisión del análisis de
riesgos, plan de trabajo, de contingencias, pruebas y de comunicación, con
ello se podrá aprobar o desaprobar los cambios. El comité técnico deberá
estar conformado por las siguientes personas:
a. Gestor de Cambios
b. Representante área de Plataforma
c. Representante área de Aplicaciones – Infraestructura
d. Representante área de Comunicaciones WAN
e. Representante área de Networking
f. Representante área de Seguridad
g. Representante área de Integración
h. Representante Proveedor Plataforma
i. Representante Proveedor Comunicaciones (Opcional)
j. Representante de área Monitoreo (Opcional)
k. Representante de área de Sol. Colaboración (Opcional)
l. Representante de área de Servicio al Usuario (Opcional)
Los cambios que entran a la revisión del comité tienen como límite para
presentar la documentación respectiva el viernes al mediodía anterior a la
reunión del comité máximo a las 12:00 p.m.
57
Comité Asesor de Cambio
El Comité Asesor de Cambio tiene como objetivo revisar los cambios ya
aprobados previamente realizando un checklist con el cumplimiento de los
requisitos. Además de revisar los cambios de emergencia y excepción
realizados en la semana; los cambios cancelados o postergados; y los
cambios fallidos o cambios que han generado algún incidente o problema.
El Comité Asesor de Cambio deberá estar conformado por:
a. Gestor de Cambios
b. Gerente de Corporativo de Infraestructura, Comunicaciones y Servicio al Usuario
c. Gerente de Corporativo de Desarrollo y Mantenimiento de Aplicaciones
d. Gerente de Arquitectura y Seguridad
e. Gerente de Demanda
f. Gerente de Infraestructura
g. Gerente de Servicio al Usuario
h. Gerente de Comunicaciones
i. Jefe de Contrato y Niveles de Servicio
j. Jefe de Incidentes y Problemas
Si en caso algún participante se encuentre imposibilitado de asistir deberá delegar y empoderar a un representante de su dominio
58
Ejecución de los Cambios
Las fechas programadas para la ejecución de los cambios varían de acuerdo a la categorización que se les da:
i. Los cambios de emergencia y excepción pueden ser realizados en cualquier momento previa autorización, de acuerdo a la matriz de Autorizaciones.
ii. Los cambios menores pueden ser realizados un día después de la aprobación del Gestor de Cambio.
iii. Los cambios medios, mayores y críticos tienen la siguiente política de ejecución.
En resumen se tiene el siguiente calendario ideal para los cambios:
Tabla 3.15 Calendario Idea de Cambios
59
Problemas durante Implementación/ Rollbacks
Si durante la implementación del cambio, sucediera algún problema o error
que requiera que se ejecute el plan de rollback, es necesario notificar al
gestor de cambio de estos eventos para que realice las notificaciones
pertinentes y asegure el cumplimiento del flujo.
Notificación de término de implementación
Así mismo 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
ventanas de tiempo.
60
1. Flujo Cambios Normales
Tabla 3.16 Flujo Cambios Normales
61
Tabla 3.17 Flujo Proceso de Cambios
62
2. Flujo Cambios Emergencia
Tabla 3.18 Flujo Cambio de Emergencia
63
4. CAPITULO IV: RESULTADO
Resultados
En la presente sección se presentaran los resultados obtenidos con la puesta
en marcha del proyecto.
Análisis de Beneficios
Beneficios Intangibles
Con la implementación de ITIL para la gestión de cambios, se logró reducir de manera considerable, los tickets asignados a cambios con P1 las cuales no han sido planificadas correctamente. A continuación en la Figura 4.1
P1 % P2 % P3 %
Enero 68 28 4
Febrero 64 32 4
Marzo 53 40 7
Abril 50 40 10
Mayo 55 30 15
Junio 42 40 18
Julio 40 30 30
Agosto 32 20 48
Septiembre 60 40 30
Octubre 10 40 50
Noviembre 30 60 10
Diciembre 14 50 36
Tabla 4.1 Porcentaje de Tickets de prioridades con una muestra de 01 año
Fuente: Elaboración Propia
64
Ilustración 4.1 Muestra del año tickets con Prioridades
Fuente: Elaboración Propia
0
10
20
30
40
50
60
70
80
P1 %
P2 %
P3 %
65
Indicadores Gestión de Cambios
Cantidad de Cambios Registrados: 562 Cantidad de Cambios que Generan Indisponibilidad: 369 Cantidad de Cambios Urgentes (Emergencia y Excepción): 105 Cantidad de Reuniones de CAB: 56
Ilustración 4.2 Indicadores de Gestión de Cambios
Fuente: Elaboración Propia
RFC’s Acepatdas vs Rechazadas
Ilustración 4.3 RFC’s Aceptadas vs Rechazadas
Fuente: Elaboración Propia
66
Cronograma
A continuación se muestra el esquema de desglose de trabajo (EDT o WBS) en la figura 6 y el cronograma del proyecto donde están detalladas las tareas realizadas para lograr el objetivo (figura 7).
WBS
Modelo de gestión de cambios basados en la metodología ITIL en Corporación Grupo Romero
Planeación EjecuciónAnálisis e
Implementación
Definición de Objetivo,
alcance, equipo, factores
críticos de éxito.
Diagnóstico Inicial.
Inventario de
Entregables
Elaboraración de
Cuestionarios de los
procesos de ITIL para
evaluar el grado de
madurez
Primera evaluación grado de
madurez de los procesos ITIL
(entrevista)
Recopilación y tabulación de la
información levantada en las
entevistas
Analisis de resultados y grado
de madurez ITIL
Presentación de los resultados,
diagnostico y hallazgos
Diseño y Elaboración de proceso
de cambios
Presentación de los resultados
de la segunda evaluación del
grado de madurez
Análisis GAP procesos
ITIL (Primera y Segunda
Evaluación
Plabes de acciones
Futuras y
recomendaciones .
Conclusiones
Elaboración del
documento
Ilustración 4.4 WBS
Fuente: Elaboración Propia
67
Diagrama GANTT
Ilustración 4.5 Cronograma
Fuente: Elaboración Propia
68
CONCLUSIONES
Es importante tener claro las responsabilidades de cada rol dentro del
proceso ayuda en la transparencia y evita re trabajos en la organización.
Se visualizan de 03 frentes:
Persona: Las personas no adaptan el flujo de cambios fácilmente son
reacias al cambio, es muy importante educar al personal sobre el proceso de
cambios de las acciones correctivas.
Tecnología: Se necesita una herramienta que permita tener la trazabilidad
del origen de los cambios.
Proceso: Es importante realizar la mejora continua de los procesos con
apoyo de otro distintos equipos. El proceso según ITIL se pudo aplicar sin
muchas desviaciones, al implementar un proceso en una compañía se
necesita un Sponsor, Seguir el procedimiento de comité de cambios permite
mayor control y ayuda a la revisión de incidentes a causa de cambios.
Con los indicados y métricas ayuda a tomar decisiones a corregir proceso o
personas en Corporacion grupo romero.
69
RECOMENDACIONES
Deberá existir un calendario de ventanas predefinías para mantenimientos de cada empresa que forma Corporacion grupo romero.
Tener una herramienta que permite tener trazabilidad de incidentes requerimientos y cambios.
Se deberá aplicar más controles en las persones para el cumplimiento del proceso.
Deberá dar foco a la revisión post implementación del cambio.
Recomendación de un constante mantenimiento de indicadores del proceso.
70
BIBLIOGRAFIA
3 Digits.es. (16 de Junio de 2016). 3 Digits.es. Obtenido de http://www.3digits.es/sistemas/ITIL_-_Auditoria_Consultoria_Plan_de_Accion_en_Tecnologias_de_la_Informacion.html
Blanco Cuaresma, S. (Enero de 2016). Marble Station. Obtenido de http://www.marblestation.com/?p=644
Bon, J. V. (2008). Fundamentos de la gestión de servicios de TI: basada en ITIL®V3 ITSM library.
Gila, G. A. (Junio de 2011). Implementación de procedimientos ITIL v3.0 en la gestión de TI de la Universidad del Valle,2008-2011. Cali, Colombia.
Helkyn Coello Blog. (8 de Diciembre de 2008). Helkyn Coello Blog. Obtenido de http://helkyncoello.wordpress.com/2008/12/08/itil-cobit-cmmi-pmbok-como-integrar-y-adoptar-los-estandares-para-un-buen-gobierno-de-ti/
Integrated Technologies Limited. (2016). Integrated Technologies Limited. Obtenido de http://www.itl.co.uk/
J, G.-A. (2006). Gestión de Proyectos Tecnológicos, Universidad Antonio Nebrija. España.
Lozano Sandobal, F., & Rodriguez Mejía, K. (2011). Biblioteca Digital ICESI. Recuperado el 1 de Mayo de 2015, de https://bibliotecadigital.icesi.edu.co/biblioteca_digital/bitstream/10906/68000/1/modelo_implementacion_universitaria.pdf