Gestion Cambios

Universidad Austral de Chile
Facultad de Ciencias de la Ingeniera

Escuela de Ingeniera Civil en Informtica
Diseo de Procesos de Gestin de Cambios basados

en ITIL y de una Base de Datos de Configuracin en
Telsur.
Tesis para optar al ttulo de:
Ingeniero Civil en Informtica
Profesor Patrocinante:
Sr. Gabriel Morales Avendao
Ingeniero Civil en Informtica
Magister in Bussines Administration.
Profesor Co-Patrocinante:
Sr. Lus Hernn Vidal Vidal.
Ingeniero Civil en Informtica.
CHRISTIAN ANDRS MATUS RAMREZ

VALDIVIA - CHILE
2008
Dedicatoria.
A nadie podra dedicar este trabajo, ms que a ti, mam.
Agradecimientos.
A mi compaera de vida DAYI.
A los valiosos consejos de los profesores Lus Vidal, Martn Solar y Juan Pablo Salazar.
A mi patrocinante, Gabriel Morales, por todo lo que aprend trabajando con l y sobretodo por lo
enseado desinteresadamente.
Al rea de informtica de Telsur, por la paciencia al que est aprendiendo.
Resumen.
En la empresa local Telefnica del Sur S.A. existe una parcial implementacin
de ITIL. Siendo de carcter urgente y necesario, para el caso en particular, la
incorporacin de ms elementos de la metodologa en la organizacin, de
forma que aumente la eficacia de la administracin de la infraestructura TI y
por ende mayor beneficio al negocio.
De lo anterior es donde nace el foco de este proyecto, el disear procesos y
polticas que permitan dar calidad a la gestin de la infraestructura, basando en
algn modelo de conocimiento terico, como es ITL. Por calidad se entiende
en este caso que, las actividades de explotacin y creacin de nuevas
configuraciones a la infraestructura TI, no deteriore los servicios al cliente
final.
Hasta la fecha se han implementado procesos relacionados con Gestin de
Incidentes, los cuales estn orientados a mantener el servicio tecnolgico
disponible, minimizando principalmente las cadas del servicio final a los
clientes, sin posibilidad de planificar mejoras o evaluar impactos.
En este proceso de avance se han dejado fuera Gestin de Cambios y Gestin
de Configuracin, donde el primero est orientado a la administracin de la
infraestructura tecnolgica que la soporta, el segundo se encarga de la
construccin de un repositorio unificado y nico para toda la organizacin de
la configuracin de los componentes tecnolgicos, adems de los procesos de
actualizacin de la misma, que en ITIL se reconoce formalmente como Base
de Datos de Gestin de Configuracin o CMDB por sus siglas en ingls.
Los resultados esperados, en consecuencia con lo expuesto anteriormente,
estarn relacionados con reducir el riesgo por fallas en la infraestructura TI,
aumentar la eficiencia y la calidad del servicio, utilizando un estndar lder en
el mundo en el tema.
Abstract.
In Telefnica del Sur, a local corporation, it exists a partial implementation of
ITIL. The incorporation of more elements of this methodology into the
organization is urgent and necessary, in order to increase the effectiveness of
the administration on IT infrastructure and hence increase the benefits to
business.
The focus of this project arises from the above mentioned: the design of processes
and policies so as to provide quality infrastructure management, based on a model of
theoretical knowledge as ITL. Quality is defined in this case as the operation and
creation of new configurations in IT infrastructure, without deteriorating services to
final customers.
To date, management processes related to incidents have been implemented, which
are designed to keep technological service available, minimizing mainly the falls in
the service provided to final customers, without possibility of planning
improvements or assessing impacts.
In this process of implementation, the areas of Change Management and
Configuration Management have been left out. The first aims at managing the
technological infrastructure which supports the process, whereas the second is
responsible for building a unified and single repository for the entire organization of
the configuration of the technological components, in addition to the processes of
updating it. This concept is formally known in ITIL as "Database Management
Settings", or "CMDB", its English acronym.
The expected results, in accordance with the above mentioned, will be related to
reduce the risks of failure in IT infrastructure; increase the efficiency and quality of
the service, using a world class standard, leader within the industry.
Indice de Contenido.
CAPITULO 1. INTRODUCCION
1.1 Que es ITIL? ............................................................................................................. 5
1.2 Introduccin al Contexto del Proyecto. ................................................................... 5
1.3 Detalle de metas esperadas. ...................................................................................... 6
1.4 Objetivos del Proyecto .............................................................................................. 6
CAPITULO 2. ANALISIS MEJORES PRCTICAS ITIL........................................ 8
2.1 Visin/Misin general ITIL. ...................................................................................... 8
2.2 Arquitectura ITIL. ................................................................................................... 10
2.3 Gestin de Cambios. ................................................................................................ 14
2.4 Gestin de Configuracin ........................................................................................ 22
2.5 Planificacin de Implementacin. ........................................................................... 23
2.6 Consideraciones de Diseo. ..................................................................................... 24
2.7 Modelo Unificado. .................................................................................................... 25
CAPITULO 3. ANALISIS DE LA PROBLEMTICA. ............................................ 26
3.1 Anlisis del Entorno. ................................................................................................ 26
3.2 Anlisis del sistema computacional de gestin vigente ........................................ 30
CAPITULO 4. Diseo de la Solucin. .......................................................................... 41
4.1 Diseo de Proceso de Cambio ................................................................................. 41
4.2 Diseo de la CMDB ................................................................................................. 66
CAPITULO 5. Pruebas de la Solucin. ........................................................................ 73
5.1 Implementacin de Mdulos de la CMDB ............................................................. 73
5.2 Implementacin Pruebas del proceso de Cambio. ............................................... 81
CAPITULO 6. IDENTIFICACION DE LOGRO A TRAVEZ DE METRICAS. ... 86
6.1 Identificacin de Logro CMDB. ............................................................................. 86
6.2 Identificacin de Logro del Proceso de Gestin de Cambios. .............................. 88
6.3 Aplicabilidad del proceso. ....................................................................................... 90
CAPITULO 7. CONCLUSIONES................................................................................ 96
7.1 Mejoras, Factores Crticos de xito a Largo Plazo ............................................. 96
7.2 Beneficios en Telsur. ................................................................................................ 96
7.3 Conclusin General. ................................................................................................. 97
Indice de Figuras.
Figura 1: cinco focos de las buenas prcticas ITIL..................................................... 10
Figura 2: diagrama relaciones procesos ITIL ............................................................. 12
Figura 3: diagrama actividades de Gestin de Cambios. ........................................... 17
Figura 5: ejemplo diagrama de flujo proceso cambio ................................................ 21
Figura 6: que muestra los conceptos de Alcance y Profundidad unificados
en el ejemplo. ............................................................................................................... 25
Figura 7: esquema de relaciones de actores del entorno del problema..................... 27
Figura 8: interfaz para nuevo ticket ............................................................................. 31
Figura 9: bitcora de un ticket. ..................................................................................... 32
Figura 10: Interfaz Consulta General. ..................................................................... 32
Figura 11: interfaz con botones para modificar estado de un ticket ......................... 34
Figura 12: interfaz Servicios TI versus Grupos de Trabajo .................................... 35
Figura 13: interfaz Servicios TI versus Tiempo de Vida .......................................... 35
Figura 14: tablas que guardan configuracin de Servicios, Componentes y
Fallas, en Sistema de Tickets ..................................................................................... 36
Figura 15: Diagrama de Transicin de estados de un Ticket en el Sistema de
Tickets. ....................................................................................................................... 38
Figura 16: Diagrama Flujo de Gestin de Cambios de alto nivel ......................... 51
Figura 17: Diagrama de Flujo Funciones Cruzadas Fase Aceptacin. ................. 52
Figura 18: Diagrama de Flujo Funciones Cruzadas Fase Evaluacin .................. 53
Figura 19: Diagrama de Flujo Funciones Cruzadas Fase Aprobacin y
Evaluacin ................................................................................................................. 55
Figura 20: Diagrama de Flujo Funciones Cruzadas Fase Aprobacin y
Evaluacin ................................................................................................................. 56
Figura 21: Diagrama de Transicin de Estados de un Cambio ................................. 58
Figura 22: Formulario de Cambio, Seccin A: Informacin General ...................... 60
Figura 23: Diagrama Warnier-Orr de estructura de informacin en Tabla
Correlacin N 1. ......................................................................................................... 61
Figura 24: Diagrama Warnier-Orr de estructura de informacin de Tabla de
Correlacin N 2. ......................................................................................................... 63
Figura 25: Modelo Entidad Relacin. .......................................................................... 68
Figura 26: Modelo de Datos CMDB ............................................................................. 69
Figura 27: Diagrama Warnier-Orr, estructura de diccionario de datos para
tablas ............................................................................................................................ 70
Figura 28: Diagrama Warnier-Orr, estructura de diccionario de datos para
triggers ......................................................................................................................... 70
Figura 29: seccin 1, Navegador CMDB ..................................................................... 74
Figura 30: seccin 2, Navegador CMDB ...................................................................... 74
Figura 33: interfaz aplicacin Navegador CMDB .................................................... 76
Figura 34: configuracin Servicio Gua Nacional Web Atento ................................. 77
Figura 35: relaciones de entorno de un componente en Navegador CMDB,
antes para componente Gua Nacional Web .......................................................... 78

para componente Enlace GTD (Atento). .............................................................. 79
para componente Hulk (Servidor PW250 4U, Firewall Solaris 9 ........................ 79
para componente Apache (Conswins3) ................................................................. 79
Figura 39: datos ejemplo en ingreso de un ticket ........................................................ 81
Figura 40: ejemplo de ingreso de ticket de cambio ..................................................... 83
Figura 41: diagrama Warnier-Orr de plantilla formulario de actividades de
cambio .......................................................................................................................... 84
Figura 42: estados sistema ticket y proceso de cambio............................................... 84
Figura 43: diagrama de tickets creados para implementar con actividades que
involucren ms de un Grupo de Trabajo ................................................................. 85
Figura 44: grfico de mtricas del proceso de cambio................................................ 89
Indice de Tablas.
Tabla 1: niveles certificacin ITIL ................................................................................. 9
Tabla 2: hitos histricos ITIL. ...................................................................................... 10
Tabla 3: de cumplimiento de criterios de eleccin de herramienta y el
cumplimiento de estos del sistema de tickets ............................................................ 39
Tabla 4: recomendaciones mejores prctica, para el proceso de gestin de
cambios ........................................................................................................................ 43
Tabla 5: correlacin para fase de aceptacin del proceso de cambio. ...................... 62
Tabla 6: correlacin para fase de aceptacin del proceso de cambio ....................... 64
Tabla 7: diccionario de datos, ejemplo de tabla. ......................................................... 71
Tabla 8: diccionario de datos, ejemplo de trigger ....................................................... 71
Tabla 9: de recomendaciones de implementacin de procesos ITIL y situacin
en Telsur ...................................................................................................................... 82
Tabla 10: de Mtricas de logro para la CMDB implementada.................................. 87
Tabla 11: de Mtricas de logro para el Proceso de Gestin de Cambios .................. 88
Tabla 12: estados de cambio ms utilizados. ............................................................... 90
Tabla 13: de transiciones faltantes ............................................................................... 91
Tabla 14: estados de cambio menos utilizados. ........................................................... 91
Tabla 15: de actividades ms importante en el proceso de cambio. .......................... 93
Tabla 16: de secciones ms importantes del formulario de cambio. ......................... 95
CAPITULO 1. INTRODUCCION.
1.1 Que es ITIL?
ITIL son las siglas de una metodologa desarrollada a finales de los aos 80s por
iniciativa del gobierno del Reino Unido, especficamente por la OGC u Oficina
Gubernativa de Comercio Britnica (Office of Goverment Comerce). Las siglas de
ITIL significan (Information Technology Infrastructure Library) o Librera de
Infraestructura de Tecnologas de Informacin y fue creada exclusivamente para la
administracinde infraestructura tecnolgica de una corporacin.
Esta metodologa es la aproximacin ms globalmente aceptada para la gestin de
servicios de Tecnologas de Informacin, ya que es una recopilacin de las mejores
prcticas tanto del sector pblico como del sector privado, mejores prcticas, que se
dan en base a toda la experiencia adquirida con el tiempo en el rea.
1.2 Introduccin al Contexto del Proyecto.

En la empresa valdiviana Telefnica del Sur S.A. existe una parcial implementacin
de ITIL. Siendo de carcter urgente y necesario, para el caso en particular, la
incorporacin de ms elementos de la metodologa en la organizacin, de forma que
aumente la eficacia de la administracin de la infraestructura TI y por ende mayor
beneficio al negocio.
De lo anterior es donde nace el foco de este proyecto, el disear procesos y polticas
que permitan dar calidad a la gestin de la infraestructura, basando en algn modelo
de conocimiento terico, como es ITL. Por calidad se entiende en este caso que, las
actividades de explotacin y creacin de nuevas configuraciones a la infraestructura
TI, no deteriore los servicios al cliente final.
Hasta la fecha se han implementado procesos relacionados con Gestin de
Incidentes, los cuales estn orientados a mantener el servicio tecnolgico disponible,
minimizando principalmente las cadas del servicio final a los clientes, sin
posibilidad de planificar mejoras o evaluar impactos.
En este proceso de avance se han dejado fuera Gestin de Cambios y Gestin de
Configuracin, donde el primero est orientado a la administracin de la
infraestructura tecnolgica que la soporta, el segundo se encarga de la construccin
5
de un repositorio unificado y nico para toda la organizacin de la configuracin de

los componentes tecnolgicos, adems de los procesos de actualizacin de la misma,
que en ITIL se reconoce formalmente como Base de Datos de Gestin de
Configuracin o CMDB por sus siglas en ingls.
1.3 Detalle de metas esperadas.
La implementacin de procesos basados en ITIL debera afectar significativamente
la forma en la que se administra la tecnologa en la organizacin, con los siguientes
impactos esperados:
Consolidar el conocimiento de la configuracin de la infraestructura TI, por ende

mejorar el diagnostico de fallas, ante cadas del sistema.
Mejorar la estimacin del impacto, si es que se efecta para una modificacin a

la configuracin.
Coordinar de mejor forma los trabajos sobre la infraestructura tecnolgica, por

ejemplo, eliminar la duplicacin de trabajo.
1.4 Objetivos del Proyecto.

A. Objetivos Generales.
Disear de procesos de Gestin de Cambios e implementar de una Base de Datos
de Gestin de Configuracin, usando ITIL, para el Data Center de Telefnica del
Sur.
B. Objetivos Especficos.
Por objetivos especficos se identifican:
1. Describir el entorno del problema organizacional en el que se aplica ITIL.
2. Formalizar el marco terico ITIL, definiendo una base terica a aplicar en las
actividades del proyecto.
3. Diseo procedimientos y polticas, para Gestin de Configuracin.
4. Disear Base de Datos de Gestin de Configuracin.
5. Implementar Base de Datos de Gestin de Configuracin y los datos crticos
de operacin.
6. Implementar procesos y polticas, para Gestin de Configuracin.
7. Validar mtricas xito con mtricas en los servicios y Jefe Data Center &
Hardware.
2.- CAPITULO 2. ANALISIS MEJORES PRCTICAS ITIL.

2.1 Visin/Misin general ITIL.
Siendo un marco de buenas prcticas ITIL:
Describe los objetivos y metas principales en la administracin TI .
Actividades y fases generales.
Entradas/Salidas de mltiples procesos.
No pretende describir las operaciones del da a da.
Los elementos ITIL pueden ser incorporados evolutivamente a las organizaciones,

en coexistencia de otras formas de administracin anteriores.
La distribucin y release oficial de ITIL est a cargo de la ITSMF o IT Service
Managment Forum, organizacin internacional sin fines de lucro (libre de
compromisos con proveedores)
dirigida por sus miembros (Organizaciones,
Proveedores y Usuarios).
a. Certificaciones ITIL.Sin discusin, la certificacin es punto de inters dentro de cualquier especializacin
profesional, en ITIL, estas se enumeran por nivel (de menor a mayor) como sigue:
Certificacin.
Caracterstica.
Foundation Certificate
Acredita un conocimiento bsico de ITIL en gestin de

servicios de tecnologas de la informacin y la
comprensin de la terminologa propia de ITIL. Est
destinado a aquellas personas que deseen conocer las
buenas prcticas especificadas en ITIL. El examen para
conseguir este certificado se puede hacer en ingls,
francs, espaol, alemn, portugus, chino, japons y
ruso.
Practitioner's Certificate
Destinado a quienes tienen responsabilidad en el diseo

de procesos de administracin de departamentos de
tecnologas de la informacin y en la planificacin de las
actividades asociadas a los procesos. Este examen slo se

puede hacer en ingls.
Service
Manager's Garantiza que quien lo posee dispone de profundos
Certificate
conocimientos en todas las materias relacionadas con la

administracin de departamentos de tecnologas de la
informacin, y lo habilita para dirigir la implantacin de
soluciones basadas en ITIL. Este examen se puede hacer
en ingls, alemn y ruso.
Tabla 1: niveles certificacin ITIL
b. Hitos Histricos.
A continuacin en la tabla se describen los hitos histricos del desarrollo de ITIL.
Ao.
Hito.
Mediados de
La
institucin
gubernamental
Central
Computer
and
los aos 80s. Telecommunication Agency (CCTA), la que mas tarde ser
renombrada como Office of Goverment Commerce (OGC), inici el
trabajo de crear ITIL como apoyo en la administracin de Servicios TI
pblicos.
En 1992.
Solo estaba disponible la certificacin de IT Service Manager, la ms

alta en el escalafn de certificaciones ITIL hasta hoy.
En 1996 y
Se crean las certificaciones ITIL Foundations y ITIL Particioner,
1997.
respectivamente, creando los niveles bsicos y intermedio en los

niveles de certificacin ITIL.
Entre 1999 y
Del total de 44 libros, se condensan en 10 tomos, los cuales adoptan el
2006.
nombre de ITIL versin 1. En consecuencia de lo anterior, el foco de la

certificacin se centr en los procesos incluidos tomos: Service Suport
(enfoque operacional) y Service Delivery (enfoque tctico).
El 2005.
Se iniciaron los trabajos de lanzar una nueva versin de ITIL,

reuniendo ms de 6000 recomendaciones generadas por los usuarios y
grupos de discusin (Workshop).
El 30 de
Se lanza oficialmente ITIL versin 3.
mayo del
2007.
Tabla 2: hitos histricos ITIL.
2.2 Arquitectura ITIL.
El siguiente diagrama, elaborado por la OGC, ilustra los cinco elementos que son foco
del conjunto de las prcticas ITIL, estos son:
Figura 1: cinco focos de las buenas prcticas ITIL

Cada uno de estos tpicos est detallado en una serie de libros, los que se enumeran a
continuacin:
Business Perspective: Libro que cubre el rango de problemas concernientes al

entendimiento y mejoras de aprovisionamiento de Servicios TI.
Service Delivery: Libro que describe las principales consideraciones en la entrega

de un Servicio TI a clientes.
Services Support: Libro contiene las recomendaciones dirigidas al aseguramiento

de la continuidad del Servicio TI y el acceso de los clientes al mismo., los tpicos
discutidos son:
o Service Desk (Mesa de Ayuda).
o Incident Management (Gestin de Incidentes).
o Problem Management (Gestin de Problema).
o Change Management (Gestin de Cambios).
o Release Management (Gestin de Versiones).
Manage the Infrastructure: Incluye recomendaciones para operacionales sobre la

infraestructura.
Managing Applications: Libro que contiene recomendaciones que estn sujetas a

ciclos de vida de los procesos software y las etapas de pruebas de Servicio TI.
De toda esta bibliografa, los libros ms usados (y necesario para todos los niveles
de certificacin) son los de Service Delivery y Service Support. Y para esta
tesis, en particular, los tpicos de Services Support.
10
A. Arquitectura de Service Support.

El siguiente diagrama muestra como se relacionan los procesos ITIL.
Figura 2: diagrama relaciones procesos ITIL
Organizacin, Clientes y Usuarios: Son todos aquellos que utilizan Servicios TI

dentro de la Organizacin, a todo nivel.
o Clientes: Los que contratan de forma externa los Servicio TI.
o Usuarios: Son aquellos que utilizan los Servicios TI, como herramientas en
sus actividades, por ejemplo, Sistemas BSS, intranet corporativa o correo
corporativo.
o Organizacin: La propia organizacin se toma como una usuario/cliente de
los Servicios TI, ya que muchas de las estrategias organizacionales se llevan
a cabo a travs de TI, por ejemplo, Telefnica del Sur.
Service Desk: En general es la interfaz con cualquier usuario que utilice Servicios
TI de una organizacin. Lleva a cabo principalmente estas tareas.
11
o Sirviendo de punto nico de registro y escalamiento de incidentes (en

relacin a Gestin de Incidentes).
o Aplicando soluciones conocidas por los ejecutivos de 1 y 2 nivel de Mesa
de Ayuda, si existe algn error conocido y repetitivo, en alguna regla en base
de dato de conocimiento o KB (no necesariamente en una BD relacional),
por ejemplo, actualizacin diaria del antivirus, que provoca lentitud en
intranet. (en relacin con Gestin de Problemas).
o Colaborando con la Gestin de Configuracin de la CMDB, en particular
registrando eventos dentro del ciclo de vida de un Incidente.
o Gestionando cambios solicitados va RFC (Request For Change), de acuerdo
a procedimientos definidos en Gestin de Cambios y Gestin de Versiones,
por ejemplo reportando degradaciones del Servicio TI a los Grupos de
Expertos Tcnicos, asociado a un Cambio Implementado recientemente.
Gestin de Incidentes: Tiene por objetivo resolver cualquier incidente que cause
una interrupcin en los Servicios TI, de la forma mas rpida y eficaz posible,
muchas veces dejando las soluciones definitivas a Gestin de Problemas (el cual se
encarga de hacer seguimientos de incidentes y encontrando causas tcnicas
comprobables).
Gestin de Problemas: Se encarga de investigar causas subyacentes a cualquier

alteracin real o potencial de Servicio TI. Una vez echo esto ingresar una RFC, o
cambio en la configuracin de un Servicio TI, el cual debera solucionar el problema
y finalmente realizar una revisin post implementacin (PIR en ITIL), en
comunicacin con Gestin de Cambio.
Gestin de Cambios: Sus principales actividades son.

o Evaluar el impacto de los posibles cambios sobre la Infraestructura TI.
o Gestionar los cambios (RFC) mediante procesos y procedimientos
estandarizados y consistentes.
o Actualizar la CMDB o la documentacin disponible.
o Revisar junto a los usuarios (a travs de la Mesa de Ayuda) y los grupos de
expertos tcnicos que ejecutaron el cambio, los resultados postimplementacin.
12
Gestin de Versiones: Se encarga de:

o Implementar las actividades de los cambios.
o Desarrollar planes de roll-out (lanzamiento de nuevas versiones) y backout (recuperacin de versiones antiguas).
Gestin de Configuraciones: Sus actividades principales son.

o Llevar el registro de los principales elementos de configuracin o CI
(Configuration Item) de la infraestructura TI.
o Realizar auditorias peridicas de la configuracin.
o Proporcionar informacin oportuna y precisa sobre la configuracin TI a
todos los diferentes procesos de gestin, en particular a Gestin de Cambios,
como herramienta de evaluacin de impacto al Servicio TI, relacionada a una
RFC.
2.3 Gestin de Cambios.

a. Objetivos de la Gestin de Cambio.
La meta primordial de la Gestin de Cambios es que se realicen e implementen
adecuadamente todos los cambios necesarios en la infraestructura y servicios TI,
garantizando el seguimiento de procedimientos estndar. Abriendo canales de
comunicacin entre lo involucrados, para facilitar la toma de acuerdos en conjuntos.
13
Recomendacin ITIL.
Sin duda la definicin de procedimientos de cambios dentro de una organizacin
provoca puede provocar el escozor de algunas reas que pudieran ver sometida sus
tareas a lo definido en un procedimiento; por lo que es altamente recomendable
implementar Gestin de Cambios y Gestin de Configuracin simultneamente,
asegurando que el riesgo de evaluar mal el impacto del cambio se minimice. Adems se
deben considerar protocolos de actualizacin de la documentacin en la CMDB, segn
el proceso avance.
b. Conceptos Bsicos de Gestin de Cambios.
Cambio.Es todo proyecto o actividad que cambie la configuracin de la infraestructura

TI, en particular con los datos almacenados en la Base de Gestin de
Configuracin o CMDB.
Change Manager, Gestor de Cambios.Es el encargado de velar por las actividades propias del proceso de Gestin de
Cambio, ya sea lanzando notificaciones y como la actualizacin de la CMDB. Es
el rol que pone los antecedentes del flujo a disposicin de todos los involucrados
(CAB), muchas de sus tareas pueden ser automatizadas, sin embargo siempre
surgen excepciones tanto para el proceso como en el caso de urgencias, que
deben ser gestionadas incluso por vas mas expeditas, como telfono o fax.
Consejo Asesor de Cambios, Change Advisory Board o CAB.Es un rgano interno, presidido por el Gestor de Cambios, formado
principalmente por representantes de las principales reas de la gestin de
servicios TI. Sin embargo, en algunos casos tambin puede incorporar:
o Consultores externos.
o Representantes de los colectivos de usuarios.
o Representantes de los principales proveedores de software y hardware.
RFC, Request For Change o Formulario de Cambio.

Es un formulario nico para cualquier proceso de cambio, contiene tambin
todos los campos necesarios para el control del proceso de cambio, en particular
se recomiendan los siguientes campos para el registro inicial:
14
o Fecha de recepcin.
o Identificador nico de la RFC.
o Descripcin del cambio propuesto:
Motivacin.
Propsito.
CIs involucrados.
Estimacin de recursos necesarios para la

implementacin.
Tiempo estimado.
o Estado: que inicialmente ser el de "Registrado".

Y para efecto del control del resto del proceso.
o Estado actualizado: "aceptado", "rechazado", "implementado",...
o Fecha de aceptacin (denegacin) del RFC.
o Evaluacin preliminar de la Gestin del Cambio.
o Prioridad y categora.
o Planes de "back out".
o Recursos asignados.
o Fecha de implementacin.
o Plan de implementacin.
o Cronograma.
o Revisin post-implementacin.
o Evaluacin final.
o Fecha de cierre.
15
FSC, o Programa Adelantado de Cambio.

Es informacin acerca de los cambios futuros que se implementarn en la
infraestructura, debe publicarse en un medio asequible por cualquier miembro de
la organizacin.
c. Proceso de Gestin de Cambio.

El siguiente diagrama enumera las principales actividades del proceso.
Figura 3: diagrama actividades de Gestin de Cambios.

Estas etapas de detallan a continuacin.
d. Actividades de Gestin de Cambio.
1) Registro y Aceptacin.
El primer paso del proceso es el adecuado registro un RFC, el origen del cambio
puede ser muy variado, se recomienda considerar:
Gestin de Problema: Se pretende solucionar un problema a travs de un

cambio.
Nuevos Servicios TI: El cambio pretende la configurar la infraestructura con el

fin de Implementar un Nuevos Servicio TI.
Estrategia Empresarial.
Imperativo Legal.
Para Aceptar una RFC, se debe evaluar preliminar su pertinencia, junto con
comprobar que la informacin que se ingreso es vlida y suficiente para
implementar el cambio completo.
16
2) Clasificacin.
Despus aceptada la RFC, se procede a clasificar por categoras los RFC, categora
que indicar una ponderacin entre el esfuerzo y la necesidad de implementar el
cambio especificado en la RFC, en general se recomienda tener en cuenta estas
categoras por defecto:
Baja: puede ser conveniente realizar este cambio junto a otros cuando, por
ejemplo, se decidan actualizar ciertos paquetes de software o se compre nuevo
hardware, etc.
Normal: Es conveniente realizar el cambio pero siempre que ello no entorpezca

algn otro cambio de ms alta prioridad.
Alta: un cambio que debe realizarse sin demora pues esta asociado a errores
conocidos que deterioran apreciablemente la calidad del servicio. El CAB debe
evaluar este cambio en su prxima reunin y adoptar las medidas pertinentes
que permitan una pronta solucin.
Urgente: es necesario resolver un problema que esta provocando una

interrupcin o deterioro grave del servicio. Un cambio de prioridad urgente
desencadena un proceso denominado cambio de emergencia que trataremos de
forma independiente.
Estas categoras son datos que deben verse reflejada en la Gestin de los
Cambios, es decir debera afectar el encolamiento de las actividades y los
llamados a reunin del CAB (o EC, Emergency Change).
3) Aprobacin y Planificacin.
Es en esta actividad es donde el Change Manager tiene una alta participacin, es l
el encargado de llevar un control de sub-tareas necesarias para el cumplimiento los
objetivos de esta actividad, se pueden resumir en:
Convocar la participacin de grupos de expertos tcnicos: Los cuales deben

aportar con su pericia en las actividades sobre la infraestructura y definir los
pasos a seguir sobre la infraestructura.
17
Convocar las personas que responsables de los Servicios TI: Los que deben
asegurar que el cambio no afecte el rendimiento de los Servicios TI para
clientes.
Convocar a cualquier rea que pueda verse afectada por el cambio: Por ejemplo,
invitar al Jefe de Finanzas, si el cambio afectar los procedimientos
computacionales que facturan las cuentas de los clientes.
Por su parte, el Change Manager debe asegurar se realice la Evaluacin de

Impacto asociada al cambio y que adems sea registrada en la CMDB.
Finalmente, se deben determinar y aprobar las fechas en las que se va a proceder

a ejecutar las actividades de cambio y que deberamos hacer si el cambio resulta
mal (actividades BACK-OUT).
En general estas actividades deben ser apoyadas por herramientas de gestin

computacionales, que buscan acercar a los participantes del CAB y agilizar la tarea
de control del proceso. Adems la CMDB debera tener los datos precisos que
permitan encontrar la informacin a las siguientes preguntas: Quines son los
responsables de ste Servicio?, Quines nos dan soporte de esta tecnologa?, Si
bajamos este servidor, A que servicio afectamos?... todas preguntas que se
presentan a la hora de decidir a quien llamar a participar del CAB.
4) Implementacin.
El foco de inters de Gestin de Cambio, en esta actividad, esta dirigida a
monitorear las actividades de cambio.
Tambin es necesario comunicar a la organizacin cualquier informacin de inters
para los clientes y a todos los involucrados en el cambio.
Interactuar con Service Desk: Para escuchar e informar a los clientes de las
actividades de cambio realizadas en la infraestructura (las que sean de su inters
y pertinencia). Adems escuchar sugerencias, percepciones de funcionalidad, de
usabilidad y de accesibilidad de los nuevos sistemas implementados.
Informar a profesionales de la informtica y expertos tcnicos de los trabajos

sobre la infraestructura.
18
5) Evaluacin y cierre.
Antes de proceder al cierre del cambio es necesario realizar una evaluacin que
permita valorar realmente el impacto del mismo en la calidad del servicio y en la
productividad de la organizacin.
Los aspectos fundamentales a tener en cuenta son:
Se cumplieron los objetivos previstos?
En que medida se aparto el proceso de las previsiones realizadas por la Gestin

de Cambios.
Provoc el cambio problemas o interrupciones del servicio imprevistas?
Cul ha sido la percepcin de los usuarios respecto al cambio?
Se pusieron en marcha los planes de "back-out" en alguna fase del proceso?

Por qu?
Si la evaluacin final determina que el proceso y los resultados han sido

satisfactorios se proceder al cierre de la RFC.
19
e. Esquema unificado del proceso de Cambio.

El siguiente diagrama de flujo muestra a modo de ejemplo, un flujo de trabajo de
alto nivel, que unifica las actividades mencionadas anteriormente y la interaccin
con la CMDB (registrar eventos y nueva configuracin).
Figura 5: ejemplo diagrama de flujo proceso cambio
20
2.4 Gestin de Configuracin.

a. Objetivo.
Sus principales objetivos se pueden resumir en:
Llevar un registro adecuado de los CIs y de los eventos que ocurren sobre ella,
a travs de la CMDB, los que se resumen en:
o Identificacin e historial de los CIs que componen la infraestructura
tecnolgica.
o Las relaciones que existen entre los distintos CIs.
o Servicios TI que componen algunos CIs.
Se denomina Gestin de Cambios a los protocolos definidos para actualizar la

CMDB.
Proporcionar informacin a los otros procesos de ITIL.

o A Gestin de Incidentes: Para encontrar rpida solucin a problemas
conocidos.
o A Gestin de Problemas: Navegar por los registros histricos, de los
trabajos en la infraestructura, para determinar causales de dichos
problemas.
o A Gestin de Cambios: Para determinar el impacto del cambio sobre
algn componente, y adems es en este proceso donde se actualizan las
relaciones.
Generar auditorias peridicas, que contrasten lo que existe en la CMDB con el

ambiente de produccin.
Es importante considerar que la CMDB no es un registro de inventario o de stock,

sino ms bien debe representar una imagen global de la infraestructura TI de la
organizacin que permita tomar decisiones estratgicas, siendo el ncleo de
informacin de todos los procesos ITIL.
21
b. Conceptos Bsicos de Gestin de Configuracin.
CI, Configuration Item.

Atributo que modela un parmetro configurable de la infraestructura tecnolgica o
que define alguna caracterstica de ella, que por sobre todo aporta valor para la
Gestin de la Calidad de los Servicios TI de la organizacin. Pueden ser datos de
muy distinta naturaleza, desde el tamao del Disco en TeraBytes de un Servidor,
hasta el nombre del funcionario que usa un notebook.
CMDB, Configuration Managment Data Base.

Repositorio donde se almacenan todos los artculos de configuracin CIs junto a
sus datos, trazabilidad y relaciones. Herramienta tecnolgica que debe contener:
CIs y sus relaciones.
Historial de los procesos ITIL.
Documentacin
importante,
como
contratos,
declaracin
de
SLAs,
responsabilidades de personas o grupos etc.

2.5 Planificacin de Implementacin.
La implementacin de Gestin de Configuracin/CMDB requiere al menos de:
Un responsable: La descentralizacin puede generar descoordinacin y podra

estropear todo los esfuerzos.
Un directivo patrocinante: Que soporte el costo poltico en contra de la

resistencia a la implementacin.
Invertir en una herramienta software: El control y actualizacin de la CMDB de

forma manual es impracticable.
Se debe realizar un anlisis minucioso de los registros de inventario ya

existentes.
Respecto al Diseo de la CMDB Se debe establecer claramente:

o El objetivo y el alcance de la CMDB.
o Nivel de detalle: Entre mas detalle, ms riesgo de quedar desactualizado,
menos riesgo de encontrar informacin til y viceversa.
o Generar un plan de implementacin.
22
2.6 Consideraciones de Diseo.

La principal tarea de Gestin de Cambios es mantener la CMDB actualizada, es por
eso que es imprescindible que sta este diseada bajo objetivos realistas, ya que por
un lado, si no existe capacidad de actualizarla, la herramienta no prestar utilidad.
Por otra parte, el nivel de detalle debe ser adecuado, debe existir al menos registro
de los sistemas crticos. La ponderacin correcta de los anteriores, eleva las
posibilidades de xito.
Alcance.
Es necesario el alcance de los registros de la CMDB, es decir cuales son los CI que
van a ser incluidos en los registros. Se recomienda:
Registrar los CIs que forman los Servicios ms Crticos.
Dejar fuera los que estn en su etapa final de ciclo de vida (ya estn en desuso).
Es necesario incluir documentacin relacionada a los responsables, los niveles

de criticidad o SLAs.
Nivel de Detalle o Profundidad.

Es necesario cuales son los atributos que describen nuestros CIs y sus las relaciones
(lgicas y fsicas) que existen entre ellos.
23
2.7 Modelo Unificado.

En el siguiente diagrama se muestra, a modo de ejemplo, la combinacin de las
consideraciones de diseo para la CMDB (Profundidad, Relaciones y Atributos), si
deseamos modelar los equipos desktop que existen dentro de un laboratorio.
Figura 6: que muestra los conceptos de Alcance y Profundidad unificados en el

ejemplo.
Segn el diagrama, se define que:
La profundidad de los atributos CI incluye hasta Placa, para los desktop de

LAN y hasta el CI CPU de LAN2
Y que el alcance abarca hasta el CI (compuesto) LAN2.
Como se puede apreciar los atributos CI pueden variar incluso dentro de componentes
fsicas idnticas (desktop), lo que interesa incluir es la informacin que ayude a la
Gestin de la Calidad de Servicio TI. Por ejemplo, podra ser que en LAN se
encuentran las terminales de Facturacin y Cajas, que en LAN2 se encuentran
terminales de consultas de saldo para clientes y que en LAN3 no se encuentran
Servicios TI instalados bajo responsabilidad de la organizacin.
24
3.- CAPITULO 3. ANALISIS DE LA PROBLEMTICA.

3.1 Anlisis del Entorno.
Durante los ltimos aos la empresa local Telefnica del Sur, ha experimentado
varios cambios en su infraestructura y en la tecnologa que soporta los niveles
productivos de sus servicios finales, siendo el punto de rezago, la gestin de estos
componentes tecnolgicos.
Lo anterior queda puesto en evidencia con la creacin a principios del ao 2006, de
un cargo llamado Jefe de Data Center y Hardware, concerniente a la
administracin de la tecnologa en su uso para las funciones del negocio, desde las
estaciones de trabajo (PC escritorio y/o notebooks) hasta los servidores de
Produccin. Es justo con la insercin de este cargo, cuando nace la inquietud con
establecer una forma ms ordenada de trabajar en el rea, al implementar
procedimiento unificado y pblico, en vez de efectuar modificaciones a travs de
contactos internos o una simple llamada telefnica.
Los primeros pasos los dio el cargo, al crear un Sistema de ticket de Incidentes, de
modo de poder tener una herramienta software que registre los problemas que tienen
los usuarios de la organizacin y a la vez implementar procesos de Gestin de
Incidentes, adems dicho sistema esta pensado para hacer posible la implementacin
el resto de los procedimientos incluidos en el estndar ITIL
Actores del entorno del Proyecto.
Como principales actores que se relacionan con la implementacin del proyecto
podemos mencionar los siguientes:
Sistema de Ticket: Sistema Informtico, donde se registran los problemas y se

comentan las soluciones (tal como los foros abiertos de Internet). Este sistema
unifica a todos los actores del mbito del problema que se mencionan a
continuacin.
Usuarios no informticos: los que solicitan que le instalen algo en su estacin o

informan de un error en sus herramientas de trabajo. Generalmente este ingresa
sus solicitudes a travs de Mesa de Ayuda (Help Desk), propio de la mayora de
las empresas TI que operan actualmente.
Mesa de Ayuda: Punto nico de contacto para usuarios no informticos, tiene a

cargo de la resolucin de incidencias con los equipos de los usuarios y los
25
aplicativos que utilizan. Adems se encarga de reportar fallas masivas de

sistemas o servicios TI para su escalamiento a reas especializadas.
Jefe de Data Center y HW: Actor fundamental del entorno del proyecto, ya que
por el rol de su cargo debe coordinar y velar por explotar la infraestructura
tecnolgica de la mejor manera posible. ste rol toma las decisiones de procesos
requieren autorizacin.
Usuarios Informticos (Ing. De Sistemas): Son usuarios de alto conocimiento

de la infraestructura tecnolgica, los cuales solicitan cambios, que debern ser
evaluados, por los impactos que producen o informan problemas en los
componentes tecnolgicas que forman el servicio final. Estos tienen acceso
directo al sistema de registro de incidentes actual y atienden problemas que le
conciernen a travs del mismo.
La figura siguiente muestra como interactan las distintas reas o actores.
Jefe Data Center & HW.
Infraestructura Tecnolgica.
Usuarios
de Servicios.
Mesa de Ayuda.
Ing. de Sistemas
(desarrollo y
mantenimiento).
Ing. de Operaciones y
Figura 7: esquema de relaciones de actores del entorno del problema

Las reas de superposicin representan los puntos o lazos de comunicacin ms
estrechos, es importante notar que los Ing. de Sistemas, en la mayora de sus
actividades tienen acceso a cambiar la configuracin de la infraestructura (resaltado
en la figura por el cuadro rojo), esto es particularmente importante para el proyecto,
26
porque resalta la falta de implementacin de procesos de Gestin de Cambios,

originando un foco de riesgo para la estabilidad de los Servicios TI Telsur.
a. Procedimiento definido para Gestin de Incidentes Telsur.
A pesar que ste procedimiento es de carcter confidencial, podemos dar el
siguiente anlisis resumido del mismo, desde el documento redactado por el Jefe de
Data Center & Hardware, Gabriel Morales.
Objetivo: Definir el procedimiento de atencin y registro de informacin

asociada a la atencin y resolucin incidente de Servicios TI o equipamiento
tecnolgico que la Subgerencia de Informtica provee a Telefnica del Sur y sus
filiales.
Alcance: Cualquier falla de servicio percibida por cualquier usuario de

tecnologa, incluyendo la resolucin de cada caso. No aplica a cambios, ni a
fallas reportadas al rea de sistemas.
Polticas:
o Un incidente es cualquier respuesta no esperada del uso de Servicios TI.
o Las acciones de resolucin del incidente, estn orientadas nica y
exclusivamente a la restitucin o normalizacin del Servicio TI.
o Los incidentes se reportan formalmente en el Sistema de Tickets.
o Todas las actividades de resolucin de un incidente se registran como
bitcora de un Ticket.
o El rea resolutora del incidente debe registrar al menos su diagnstico,
las acciones tomadas, el responsable que define dichas acciones y una
indicacin si la solucin es transitoria o no.
Procedimiento por roles:

o Mesa de Ayuda: Punto nico de Contacto, el cual recibe todos los casos
y resuelve directamente problemas de Software de PCs y Notebooks, o
deriva a un rea especialista segn de acuerdo al chequeo bsico definido
por Telefnica del Sur.
o Operaciones TI: Rol cumplido por ACT Ingeniera, opera en modo
24x7, resuelve incidentes derivados por la mesa de ayuda y registra sus
acciones, diagnstico y resolucin en el Ticket respectivo, u
opcionalmente escalar a proveedores de segundo nivel a cargo de la
27
plataforma afectada por el incidente, generalmente proveedores de

productos adquiridos para la plataforma TI del Data Center de Telsur o
ingenieros de sistemas Telsur.
o Especialistas resolutotes: compuesto de diversos Grupos de Trabajo,
componen el segundo nivel en el escalamiento de incidentes a sistemas
Telsur, en particular esas reas son Lotus-NT, Networking, Sistemas,
IVR-Prepago, Web-Master, DBA entre otros.
o Jefe Data Center y HW: encargado de definir procedimientos de
atencin de incidentes, elaborar planes de soluciones definitivas, velar
por la explotacin de la infraestructura TI a su cargo y facilitar la
resolucin de incidentes complejos.
b. Gestin de la Configuracin por ACT Ingenera.
Existe un relativo seguimiento de la configuracin de la infraestructura TI de Telsur
en forma de planillas Excel, por parte de ACT, entidad encargada de las operaciones
sobre la misma, dichas planillas estn publicadas en la intranet corporativa y no
representan un enfoque unificado, tal como se espera de la CMDB, ya que los
atributos de configuracin estn agrupados para utilidad interna de ACT. Estas
planillas son de carcter confidencial, pero podemos distinguir los siguientes
enfoques.
Planilla de Servidores: incluye el nombre del servidor, ambiente

(produccin o desarrollo), su IP, ubicacin, el sistema operativo, marca,
modelo, nmero de serie, modelo de su CPU, nmero de CPUs, nmero de
discos internos,
espacio total en disco, disponible, memoria RAM
disponible.
Planilla de Instancias Oracle: incluye ambiente (produccin o desarrollo),

servidor donde esta instalada, SGA en GigaBytes, versin de motor Oracle,
nombre instancia, nombre listener, IP listener, usuario unix.
Distribucin de Servicios: incluye informacin mas orientada al Servicio

TI, como nombre del Servicio TI, criticidad del Servicio TI, Servidor que la
soporta, Responsable Telsur y Software instalado en cuatro niveles.
Como se mencion al principio, estos datos son de utilidad pero no son

actualizados al ritmo en que los cambios ocurren y obviamente no estn
integrados con los procesos de Telsur.
28
En resumen, hasta la fecha se ha implementado procesos relacionados con Gestin

de Incidentes, los cuales estn orientados a mantener el servicio tecnolgico
disponible a usuarios. Se han dejando fuera Gestin de Cambios y la creacin de
una CMDB, donde la primera se encarga de evaluar el impacto de un cambio en la
configuracin y coordinar su ejecucin, y la segunda esta enfocada a habilitar un
registro de la configuracin en una base de datos de gestin de configuracin
(CMDB en ingls), de donde se obtendrn todos los datos necesarios a todos los
procesos de Gestin ITIL. Por su parte ACT, empresa consultora lleva un registro de
la configuracin en planillas publicadas en la Intranet Corporativa Telsur, siendo
ste un mtodo poco efectivo y muchas veces muy lento de actualizar.
3.2 Anlisis del sistema computacional de gestin vigente.
El sistema computacional de gestin, para las polticas y procedimientos analizados
anteriormente es el Sistema de Tickets, en el cual se lleva la gestin de Tickets de
Incidentes, Requerimientos y Consultas. Todos los cuales estn orientados a la
Gestin de Incidentes en ITIL.
Este sistema es usado como punto nico de contacto con el Help Desk, el que est
encargado de resolver las incidencias, ya sea por sus propios ejecutivos de primer
nivel, o por escalamiento a Grupos de Trabajos especializados en alguna tecnologa
o Servicio TI en particular. Entre sus funcionalidades mas importantes estn:
a. Ingreso de un Ticket: el sistema permite ingresar un ticket, especificando que
usuario lo reporta, a que grupo de trabajo asignado, a que Servicio TI,
Componente de Servicio afecta y cual fue la falla, y adems permite adjuntar
archivos que puedan ser de utilidad para la resolucin del caso.
29
Figura 8: interfaz para nuevo ticket

b. Notificaciones va correo electrnico: el sistema es capas de enviar un correo
electrnico de notificacin para ciertos eventos ocurridos en un Ticket, por
ejemplo: al ingresar un Ticket le enva un correo al usuario que reporta el
incidente, que su caso ya ha sido reportado.
c. Grupos de Trabajo y Usuarios que aprueban: el sistema permite crear de
forma paramtrica Grupos de Trabajo y Usuarios que autoricen Tickets de
Requerimiento.
d. Bitcora de Ticket: el sistema permite llevar una Bitcora de Eventos ocurridos
en la gestin de la resolucin del incidente, en forma de glosa de texto.
30
Figura 9:, bitcora de un ticket.

e. Consultas: el sistema permite consultar los Tickets de acuerdo a:
Su estado.
Quien lo report.
Servicio TI afectado.
El Grupo de Trabajo responsable del Ticket.
Por tiempo de vida.

Esta funcionalidad est implementada en un mdulo llamado Consulta
General.
Figura 10: Interfaz Consulta General.
31
f. Cambios de Estados de un Ticket.

El sistema permite modificar el estado de un ticket de acuerdo a un flujo definido
(detallado ms adelante), esta funcionalidad esta restringida segn los integrantes de
un Grupo Resolutor al cual est asignado y a distintos niveles de accesos definidos a
los usuarios del sistema. La siguiente fotografa muestra las opciones que posee un
ticket asignado a un grupo donde est incluido el alumno tesista, se destacan en un
cuadro los botones que modifican el estado.
Figura 11: interfaz con botones para modificar estado de un ticket

g. Monitoreo de Tickets:
el sistema permite monitorear los Tickets
principalmente por dos vistas :
32
Servicios TI versus Grupos de Trabajo, filtrada por tipo de Ticket y su estado.
Figura 12: interfaz Servicios TI versus Grupos de Trabajo

Servicios TI versus Tiempo de vida, filtrada por tipo de Ticket y su estado.
Figura 13: interfaz Servicios TI versus Tiempo de Vida.

Estas funcionalidades estn implementadas en un mdulo llamado Panel de Control.
33
Base de Datos, Sistema de Ticket.

Dentro de las tablas del sistema, existen algunas que se acercan al concepto de base de
datos de configuracin, en particular es capaz de llevar el catlogo de Servicios TI, las
componentes que participan, y las fallas o actividades que le ocurren a
dichos
componentes. A continuacin se muestra una vista parcial del modelo de datos

entregado como documentacin del sistema.
Figura 14: tablas que guardan configuracin de Servicios, Componentes y Fallas, en

Sistema de Tickets
Ventajas
La principal ventaja de esto es que estos datos estn integrados con el sistema de ticket,
es decir si se modela una base de datos completa considerando estas tablas, sta quedar
automticamente integrada con la lgica de l sistema de ticket.
Desventajas.
Estas tablas no estn pobladas con datos que reflejen la configuracin de los Servicios
TI.
Flujo del Sistema de Ticket.
El sistema est construido para llevar el control de los Tickets de acuerdo con el
siguiente diagrama de transicin de estados.
34
Figura 15: Diagrama de Transicin de estados de un Ticket en el Sistema de Tickets.

Tal como lo muestra el DTE, un Ticket de Incidente (y de Consulta) al ser ingresado su
estado inicial ser Abierto, mientras que si se trata de un Ticket de Requerimiento su
estado inicial ser Pendiente Aprobacin, responsabilidad que recae en el Jefe de
Data Center y HW Telsur.
Limitaciones del Sistema de Tickets.
A pesar de ser un muy buena herramienta de Gestin de Incidentes, lo que cumple
satisfactoriamente, existen dos grandes limitaciones en este sistema.
1) Por un lado, el sistema est compuesto por paginas Web escritas en PHP, por lo que
gran cantidad de eventos y en general el flujo completo estn validadas por cdigo,
es decir el DTE. Mostrado anteriormente y muchas restricciones estn insertas en el
cdigo, por lo que su mantencin y modificacin estn completamente vinculadas al
creador del sistema, es decir no existe algo as como una consola de configuracin
de sistema.
2) Otra limitacin, es que utiliza una base de datos Mysql versin 4.2, la que no tiene
integridad referencial por claves forneas, todas las consultas y las validaciones de
integridad referencial estn insertos en el cdigo PHP de las pginas que lo
componen.
35
De todas formas la tecnologa usada inters de este proyecto, pero el anlisis de la

funcionalidad de los actuales procesos administrativos de la infraestructura TI, pasa
tambin por estudiar las herramientas de gestin existentes.
Recomendaciones de eleccin de herramienta software segn recomendaciones

ITIL
A continuacin se tabulan los criterios para definir la herramienta a utilizar en la
implementacin de procesos ITIL y el cumplimiento de estos criterios por el Sistema de
Tickets
Criterio
Observacin.
Cumplir con un 80% de requerimientos
El sistema permite efectuar la mayora de
operacionales.
las operaciones relacionadas a procesos

ITIL, ya sea notificar, asignar trabajo,
reasignar, tipificar un trabajo, enva correo
electrnico, permite llevar bitcoras de los
casos etc.
Ser implementable con pocas
El sistema esta parametrizado para
modificaciones.
cumplir este requerimiento.
Estructura de datos manejable y acorde a
Con un nuevo modelo de CMDB, el
nuestra realidad.
sistema queda completamente acorde a la

realidad de la organizacin.
Diseado a enfocado a los procesos, no
Fue concebido con enfoque a procesos
por la tecnologa.
ITIL de Incidentes.
Costos de mantencin y administracin
La mantencin y administracin ya est
dentro del presupuesto.
asumida por funcionarios de Telsur.
Tabla 3: de cumplimiento de criterios de eleccin de herramienta y el cumplimiento de

estos del sistema de tickets
Por lo que se decidi continuar la implementacin de ITIL, en particular con este
proyecto de Gestin de Configuracin y Gestin de Cambios, utilizando esta
herramienta.
36
4.- CAPITULO 4. DISEO DE LA SOLUCION.

4.1 Diseo de Proceso de Cambio.
A. Visin prctica del Proceso de Cambio.
De acuerdo al marco de buenas practicas ITIL, la meta de un proceso de Gestin de
Cambios es: Asegurar que se usen procedimientos y mtodos estandarizados en el
manejo de los cambios, y minimizar el impacto que este pudiese provocar. En
extensin de lo recomendado por ITIL, en la prctica, un proceso de gestin de cambio,
debe satisfaces las siguientes aristas:
Recomendacin
mejores
Descripcin
prcticas ITIL.
Es decir, no admitir peticiones de cambio o RFC, mal
Filtrar.
documentadas o que simplemente no pertenecen a la

categora de cambio.
Notificar y convocar en el proceso a todos aquellos que sean
necesarios para la ejecucin de un cambio e informar a
Coordinar y
Notificar.
aquellos a quienes pudiera afectar, en particular si se est

Evaluando el Impacto, que podra requerir la opinin de
reas no tcnicas de la organizacin, por ejemplo: Jefe de
Finanzas, Jefe de Ejecutivos Call Center, Jefe de Proyectos
Comerciales, etc.
Se refiere en particular a una etapa obligatoria dentro de un
proceso de cambio, en la cual se recogen las opiniones de
peritos (tcnicos o no tcnicos) para evaluar el impacto que
Evaluar
pudiera provocar un cambio tanto en los Servicio TI final a
Impacto.
clientes, como a la propia infraestructura tecnolgica.

NOTA: En un ambiente con una CMDB consolidada, sta
debera entregarnos la mayor parte de la respuesta a la
pregunta, A quien convocamos a evaluar este cambio?.
37
Actualizar
CMDB.
El proceso obligatoriamente debe procurar a travs del Change

Manager (o algn encargado) mantener la CMDB actualizada,
ya que es el punto de informacin estratgico en los procesos
ITIL.
El proceso debe controlar la aprobacin de un cambio, las
actividades que involucran, que las fechas de ejecucin se
Controlar.
cumplan, que las condiciones de aprobacin se cumplan, que

los informes de cierre se entreguen, que los manuales de
operacin se entreguen, etc.
El proceso de cambio no debe ser demasiado restrictivo, ms
Acordar.
bien debe crear instancias de acuerdo.

Un cambio no puede ejecutarse sin un plan de retirada (a la
configuracin antigua), el cual se ejecuta si en la
Plan de
Retirada.
implementacin del cambio se producen efectos no esperados,

tanto en Servicios TI, como en la infraestructura TI.
Finalmente el proceso debe tener un responsable ejecutivo, un
Responsable
Ejecutivo.
operador del proceso declarado en la documentacin ITIL

como Change Manager.
Este rol no tomar decisiones, solo se encargar de que el
proceso y sus condiciones se cumplan.
Tabla 4: recomendaciones mejores prctica, para el proceso de gestin de cambios

Aparte de consideraciones generales de implementacin y diseo, ITIL presenta un
marco estratgico que no acota las herramientas de diseo a utilizar en la especificacin
de los procesos, dejando esto al conocimiento y prcticas de procedimientos
organizacional administrativo, es decir, ITIL entrega la estrategia de diseo no el modo
de especificar el proceso.
38
B. Recomendaciones de Diseo de procesos ITIL, segn consultores.

Se encontr documentacin en Internet de consultoras que implementan procesos ITIL,
entre sus ms importantes y coincidentes recomendaciones se encontraban la de dividir
el diseo del proceso en Diseo de Alto Nivel y Diseo Detallado. Para el diseo de alto
nivel se decidi definir las mismas variables definidas para el procedimiento de Help
Desk, las cuales son:
a. Objetivo del proceso.
b. Alcance del proceso.
c. Polticas del proceso.
d. Roles Funcionales.
e. Flujo del proceso de alto nivel.
Para el diseo de alto nivel se consideraron las variables que se definen tpicamente para
un proceso administrativo.
a. Estados: del Cambio y sus Actividades.
b. Roles: que participan en el proceso.
c. Datos de Entrada/Salida: para las actividades.
d. Actividades Procedurales: y una descripcin de stas.
e. Actividades Desicionales: y sus condiciones.
f. Flujo: que determina el orden y ciclos del proceso.
g. Etapas: que pueden dividir el proceso, para hacerlo mas entendible.
C. Herramientas de Diseo de Alto Nivel para proceso de Gestin de Cambio.
Tal como se mencion anteriormente ITIL ofrece recomendaciones de tipo estratgica,
dejando en libertad de conocimiento y prctica los mtodos utilizados para especificar
os procesos administrativos. Para especificar de forma precisa los se utilizaron
herramientas de tipo grficas para e diseo del proceso, para posteriormente especificar
los detalles que no son relevantes mostrarlos grficamente se especificaron a travs de
tablas de consolidacin. A continuacin se precisan las herramientas que se utilizarn:
Diagrama Flujo Funciones Cruzadas: herramienta ampliamente utilizada para

definir procesos administrativos y de calidad (como ISO 9000), permite definir
procesos bajo su nomenclatura grfica.
39
DTE o Diagrama de Transicin de Estados: herramienta bajo el alero del anlisis

estructurado. Se utiliz para estipular los estados posibles del proceso de cambio y
de sus actividades.
Formulario de Cambio: herramienta no estandarizada utilizada para definir el

formato y los valores posibles de las entradas/salidas del proceso (a pesar de no ser
estandarizada es muy recurrente su uso).
Tablas de Consolidacin: Planillas que especifican todo lo que se dej fuera en los
diagramas, de forma que su lectura de estos sean ms ergonmica.
Este grupo de herramientas es ms bien uno propuesto por el alumno, acorde al

problema que se requiere solucionar y guiado de informacin publicada por consultoras
que implementan procesos de calidad.
D. Cuerpo de Diseo de Alto Nivel.
A continuacin se muestra el cuerpo del diseo de alto nivel del proceso de gestin de
cambio.
a. Objetivos.
El objetivo principal de este proceso es de formalizar las actividades y condiciones
asociadas a un cambio a la configuracin de la infraestructura tecnolgica de Telsur,
que permita velar todo momento la calidad y continuidad de los Servicios TI.
Abarcando todas las instancias de trabajo asociadas a un cambio, desde la solicitud de
cambio, hasta el cierre definitivo de las actividades sobre la configuracin de los
componentes tecnolgicos y la evaluacin final del proceso completo.
b. Alcance.
Un cambio se define como una la actividad planificada y ordenada de implementar en
produccin nuevas configuraciones a la infraestructura tecnolgica, y por transitividad,
a los Servicios TI Telsur, que adems afecte registros de la CMDB.
Este procedimiento se aplica a las solicitudes de cambio registradas por los
profesionales de la informtica los encargados de la explotacin de la plataforma
tecnolgica de Telsur y del buen funcionamiento de los Servicios TI provisionada por la
anterior.
El alcance del proceso incluye la coordinacin de los distintos eventuales implicados en
un cambio a la configuracin de la infraestructura tecnolgica de Telsur, es decir:
Para los expertos tcnicos que ejecutan los cambios a la configuracin.
40
Para los responsables directa o indirectamente de la operatividad de

componentes tecnolgicos de la infraestructura tecnolgica de Telsur.
A aquellos responsables de la continuidad de algn Servicio TI Telsur.
Adems definen en el presente proceso, condiciones y reglas decisionales, para

el flujo completo.
No aplica:
A incidentes aplicativos en produccin.
A requerimientos de instalacin o acceso a sistemas por parte usuarios

profesionales de la informtica.
A estudio de problemas recurrentes en la infraestructura tecnolgica de Telsur.
c. Polticas.
El punto de coordinacin ser el Sistema de Tickets, donde se deben registrar

todas las gestiones asociadas al cambio, ya sea los comentarios tcnicos y las
notificaciones de conformidad.
Una solicitud de cambio ingresada por el solicitante, debe especificar

claramente: Objetivo, Prioridad, Impacto, Origen del Cambio y las actividades
que el cambio requerir que deben incluir por cada una:
o Componente Afectado.
o Detalle tcnico de la actividad.
o Fecha/hora propuesta para la actividad.
o Duracin de la actividad.
o Plan de vuelta atrs.
Siendo los anteriores, los datos necesarios para implementar el cambio en su

totalidad, la falta de estos requisitos ser motivo de rechazo del Ticket de
Cambio.
El rechazo de un Ticket de Cambio, implica el ingreso de uno nuevo, si el

usuario corrige su requerimiento y persiste en ejecutar el cambio.
Las actividades de la solicitud de cambio sern ejecutadas por los Grupos de

Trabajo usando las fechas aprobadas por el consejo asesor de cambio.
Un cambio en la configuracin se debe registrar en la base de datos de gestin

de configuracin, tarea que realizar el Change Manager hasta que existan
41
herramientas computacionales, que lo automatice para los ejecutores de las

actividades.
Todo ticket de cambio debe permanecer abierto mientras las actividades

asociadas a este no hayan terminado. Adems el cierre de un Ticket de Cambio
debe ir asociado a la evaluacin final (xito, fracaso, xito con vuelta atrs, etc.).
Un cambio es de carcter urgente, cuando su postergacin pudiese afectar

severamente el negocio.
Dado un cambio de categora urgente, el Change Manager debe efectuar

gestiones de emergencia de forma telefnica, incidentndolas en el Sistema de
Tickets y registrando eventos en el Formulario de Cambio (cuando aplique).
Siendo las respuestas dadas por telfono por los notificados, sern consideradas
como alegaciones oficiales, bajo responsabilidad de quienes las emiten.
Ser responsabilidad Change Manager monitorear las actividades de cambio y

publicar un Programa Adelantado de Cambios, para el conocimiento del rea
de las actividades sobre la infraestructura, adems de informes de control acerca
de los cambios (exitosos, fallidos, aprobados, solicitados, etc.).
Los Grupos de Trabajo, deben mantener informado a los solicitantes de cambios,

a travs del Change Manager, sobretodo cuando una de las actividades de
cambio se ha terminado.
La falta de agilidad de respuesta a una notificacin a un experto responsable de

un Servicio TI o responsable de un Componente Tcnico, significar su posible
excusin de las alegaciones del Ticket de Cambio.
Bajo cualquier circunstancia actuar como arbitro Gabriel Morales, Jefe de Data
Center & Hardware.
d. Roles y Responsabilidades del Proceso.
Solicitante de Cambio.
o Debe ingresar todos los antecedentes requeridos en el Formulario de
Cambio y en el Sistema de Tickets.
Grupo de Trabajo, de expertos tcnicos.

o Actualmente este rol es ejecutado por
ACT DBA.
ACT Ingeniera.
42
ACT Operaciones.
Networking (Red Interna).
West Ingeniera.
Sistemas.
IVR & Prepago.
Lotus-NT.
Otro que se pueda definir a futuro.
o Son los encargados de entregar la evaluacin tcnica de alguna actividad

que afecte un componente tecnolgico bajo su responsabilidad.
o Ejecutar actividades que ya estn calendarizadas y autorizadas.
o Finalmente estos grupos deben incidentar cualquier informacin
relevante en el Ticket de Cambio y hacindola llegar tambin al Change
Manager.
Responsable(s) de Servicio(s) TI Telsur.

o Actualmente este rol es ejecutado por profesionales de la informtica, en
general funcionarios Telsur.
Jefe Data Center & Hardware Telsur.

o Encargado de autorizar los cambios, de acuerdo con la informacin
entregada por el Change Manager.
o En caso de discrepancias entre las partes debe participar como rbitro.
Change Manager.
o Debe coordinar a los involucrados a un cambio segn lo estipulado en
este documento.
o Actualizar la Base de Datos de Configuracin, segn los cambios que se
realicen o al surgimiento de nueva informacin en el proceso.
o Mantener un registro y seguimiento de todos los Tickets de Cambio,
confeccionando estadsticas de control de gestin, acerca de:
Cambios solicitados.
N de cambios segn su Solicitantes.
N de cambios segn Grupos de Trabajo.
43
N de cambios segn Componentes.
N cambios fallidos y exitosos.
o Tambin debe mantener informada al rea de Informtica, publicando

un Programa Adelantado de Cambios en el sitio de intranet TWIKY,
indicando:
N del Ticket de Cambio.
Grupo de Trabajo.
Fecha Inicio de Trabajos.
Descripcin.
Estado (terminado).
o Confeccionar cualquier informe requerido por Jefe de Data Center &

Hardware, Gabriel Morales.
Help Desk.
o Es responsable de mantener informados (si aplica) a los usuarios, segn
el Programa Adelantado de Cambios o directamente con el Change
Manager.
o Comunicar al Change Manager si existen percepciones negativas de los
usuarios derivadas del cambio.
e. Flujo Proceso de Cambio.

El proceso de cambio se resume en las siguientes etapas generales.
1. Aceptacin: se verifican que el cambio tenga los datos y las actividades
necesarias para ser implementado, sino se ofrece apoyo de gestin para hacerlo.
2. Evaluacin de Impacto: se convocan a entregar su opinin tcnica acerca del
cambio, tanto a Grupos de Trabajo, como a Responsables de Servicios TI Telsur.
3. Planificacin: se acuerdan las fechas de las actividades que implementan el
cambio.
4. Implementacin: se monitorean los avances y los errores que puedan existir en
ella.
5. Evaluacin de Cierre: se cierra el cambio y se evala si el objetivo del cambio
se ha cumplido.
A continuacin se muestra el flujo de las macro actividades a seguir y las principales
decisiones a tomar en el mismo.
44
Diagrama Flujo Proceso de Cambio.
Figura 16: Diagrama Flujo de Gestin de Cambios de alto nivel.
45
E. Artefactos de Diseo Detallado.

A continuacin se despliegan o describen los objetos de diseo del proceso de
cambio.
a) Diagrama Flujo Funciones Cruzadas.
Con la elaboracin de este diagrama se determinan las actividades, las decisiones, los
datos de entrada/salida ms importantes y los involucrados en el flujo de trabajo, a
continuacin se muestra en forma separada el diagrama dividido en las distintas fases
del proceso.
Fase de Aceptacin.
Figura 17: Diagrama de Flujo Funciones Cruzadas Fase Aceptacin.

En objetivo general de esta fase, es el de obtener los datos suficientes de entrada al
resto del proceso, que permitan efectuar todo el anlisis de impacto, de aprobacin y
planificacin.
46
Fase Evaluacin.
Figura 18: Diagrama de Flujo Funciones Cruzadas Fase Evaluacin

En esta fase se evala el impacto del cambio, es decir se renen las opiniones
tcnicas de todos los involucrados, de modo de tener informacin de calidad para las
siguientes fases de aprobacin y planificacin.
47
Fase Aprobacin y Planificacin.
Figura 19: Diagrama de Flujo Funciones Cruzadas Fase Aprobacin y Evaluacin

En esta s fases se audita la aprobacin del cambio, sus condiciones de aprobacin (si
aplica) y planificacin de las actividades.
48
Fases de Implementacin y Cierre.
Figura 20: Diagrama de Flujo Funciones Cruzadas Fase Aprobacin y Evaluacin
Finalmente en estas etapas se realiza un control de la implementacin de las

actividades del cambio y la calificacin del cierre del ticket de acuerdo a los
parmetros definidos en el proceso.
49
b) Diagrama transicin de estados.

A continuacin se muestra el diagrama de transicin de estados posibles para un cambio, estados que significan un atributo de
cualquier cambio, ayudando al entendimiento y comunicacin de los involucrados.
Figura 21: Diagrama de Transicin de Estados de un Cambio

50
Formularios de Datos.
Se utilizaron formularios para definir el formato y los valores posibles de las
entradas/salidas del proceso, estos estn separados por secciones etiquetadas por
letras.
Estructura de especificacin del formulario
Etiqueta de seccin que identifica el formulario.
Vista de los campos.
Tabla de descripcin: que incluye las columnas siguientes

o Nombre del Campo: el cual coincide con el nombre presente en
la vista del formulario.
o Descripcin: Especifica la descripcin o propsito del campo.
o Valores: Describe los valores posibles del campo.
Ejemplo.
Como ejemplo continuacin se muestra el formulario en la Seccin A:
Informacin General, el cual se utiliza para ingresar la informacin general del
cambio.
Figura 22: Formulario de Cambio, Seccin A: Informacin General
51
La especificacin completa es propiedad de la Telsur y por lo que no fue adjuntada

en este documento.
G. Tablas de Consolidacin.
Permiti tabular descripciones que se dejaron fuera en los diagramas anteriores,
de modo de facilitar su lectura, en particular se utiliz para estipular las
relaciones que existen entre:
1) Entradas/salidas formateadas segn secciones del formulario, versus
actividades del proceso.
2) Actividades del proceso, versus las transiciones del DTE de Cambio.
3) Describir las actividades procedurales del cambio y definir las condiciones
de las actividades de decisin del cambio.
Estructura de las Tablas de Correlacin N 1: de Actividad, Entrada/Salida por

Seccin de Formulario, Rol Ejecutante y la Descripcin de Actividades.
Se describe la estructura del contenido de esta tabla en el siguiente diagrama
Warnier-Orr.
INPUT
Nombre Actividad OUTPUT
Rol Ejecutante
Descripcin
Etapa del proceso
INPUT
Nombre Actividad Decicional Rol Ejecutante
Descripcin
Figura 23: Diagrama Warnier-Orr de estructura de informacin en Tabla Correlacin

N 1.
'RQGHORVFDPSRV,1387\287387VRQVHFFLRQHVGHOIRUPXODULRGHFDPELR$PRGR
GHHMHPSORVHPXHVWUDDFRQWLQXDFLyQXQIUDJPHQWRGHHVWDWDEODFRQVWUXLGRSDUDODIDVH
GHDFHSWDFLyQGHOSURFHVRGHFDPELR
5
Etapa del
Proceso
Nombre de Actividad
INPUT OUTPUT
DESCRIPCIN
Registro RFC
A.B.C A,D,E
Solicitante de
Cambio
Recibir RFC
A,D,E
Change Manager
El Change Manager debe dar una mirada inicial a los datos registrados
por el solicitante y cambia el estado del cambio a Recibido.
A,D,E M
Change Manager
El Change Manager registra los motivos por los cuales el cambio solicitado no trata de un cambio.
Change Manager
El Change Manager debe dar una mirada final a la cancelacin del cambio y registrar cualquier
antecedente final.
AE
Registrar Antecedentes de
Rechazo
Registrar Motivos y
Antecedentes
Reunir Informacin Faltante
Registrar Motivos de Pendiente
Aceptacin
Rol Ejecutante
Registrar Motivos de
Cancelacin
Notificar a solicitante por mas
Antecedentes
O
L
A,D,E AG
Solicitante de
Cambio
Solicitante de
Cambio
Solicitante de
Cambio
Change Manager
El solicitante debe registrar todos los datos solicitados en el formulario.
El solicitante retorna la informacin solicitante en forma de glosa o adjuntada en un archivo.

El solicitante debe registrar claramente el motivo de la postergacin del cambio solicitado por l.
El solicitante debe registrar claramente el motivo de la cancelacin del cambio solicitado por l.
El Change Manager comunica al solicitante que los antecedentes ingresados no son suficientes para
aceptar su cambio.
Nombre Actividad Decisional INPUT OUTPUT Rol Ejecutante
CONDICIN
Es un Cambio?
A,D,E
Cualquier RFC que provoque una modificacin en la CMDB.
Dejar Pendiente?
A,D,E
Retomar Cambio?
A,D,E
Cancelar Cambio?
A,D,E
Antecedentes Suficientes?
A,D,E
Change Manager
Solicitante de
Cambio
Solicitante de
Cambio
Solicitante de
Cambio
Change Manager
El solicitante puede dejar pendiente su cambio.

El solicitante decide cuando retomar el cambio.
El solicitante puede cancelar su cambio.
La suma de los antecedentes ingresados respecto al cambio son suficientes para ser evaluado.
Tabla 5: correlacin para fase de aceptacin del proceso de cambio.
5
Estructura Tabla de Correlacin N 2: Correlacin entre actividad de cambio y

estado del cambio, rol ejecutante.
Se describe la estructura del contenido de esta tabla en el siguiente diagrama
Warnier-Orr.
Rol Ejecutante
Nombre Actividad Estado Inicial

Estado Final
Etapa del proceso

Rol Ejecutante
Nombre Actividad Decicional Estado Inicial
Estado Final
Figura 24: Diagrama Warnier-Orr de estructura de informacin de Tabla de

Correlacin N 2.
Donde los estados son los aquellos definidos en el Diagrama de Transicin de
Estados, a su vez los roles son los definidos en el Diagrama de Flujo de Funciones
Cruzadas. A modo de ejemplo se muestra un fragmento de la tabla, construido para
la fase de aceptacin del proceso de cambio.
5
Etapa del Proceso
Aceptacin
Nombre de Actividad
Rol Ejecutante
Registro RFC
Solicitante de Cambio
Registrar Antecedentes de Rechazo
Change Manager
Registrar Motivos y Antecedentes
Change Manager
Reunir Informacin Faltante
Registrar Motivos de Pendiente
Registrar Motivos de Cancelacin
Estado Inicial
Estado Final
Requiere ms Informacin
Registrado
Cancelado por Usuario
Cancelado
Recibir RFC
Change Manager
Registrado
Recibido
Notificar a solicitante por mas Antecedentes
Change Manager
Nombre Actividad Decisional
Rol Ejecutante
Estado Inicial
Estado Final
Es un Cambio?
Change Manager
Recibido
No: Rechazado
Dejar Pendiente?
Si: Requiere ms informacin
Si: Pendiente por Usuario
Retomar Cambio?
Si: Pendiente por Usuario
Si: Registrado
Cancelar Cambio?
Si: Requiere ms informacin
Change Manager
Si: Recibido , No: Recibido
Si: Cancelado por Usuario

Si:: En Evaluacin , No: Requiere
mas Informacin
Antecedentes Suficientes?
Tabla 6: correlacin para fase de aceptacin del proceso de cambio
5
H. Inconvenientes Esperados.
Dentro de los inconvenientes o puntos a tener en consideracin estn:
Se deben asumir los costos de asumir y planificar los costos de implementar

procesos de Gestin de Cambios: en particular de personas (que participan en el
proceso) y de construccin de software de apoyo de gestin del proceso.
El proceso debe haber sido construido a medida de la organizacin, un proceso

muy burocrticos pueden producir cuellos de botella, procesos muy simples
pueden producir falta de control y por ende prdida de los beneficios esperados.
Los usuarios deben aceptar la nueva cultura de trabajo, y en particular para el

proceso de cambio, ya que est debera ser el acceso nico a cambiar la
configuracin de la infraestructura. Lo anterior se debera resolver con el
auspicio de un patrocinante que pueda asumir los costos polticos y con la
capacitacin de las reas que estarn involucradas en el proceso.
5
4.2 Diseo de la CMDB

A. Anlisis y definicin de datos de inters para la CMDB.
Tal como se ha expuesto en el CAPITULO 2, la base de datos de configuracin o

CMDB (por sus siglas en ingls) se encuentra en el ncleo de las buenas practicas
ITIL, ya que provee de informacin a todos los procesos ITIL sobre de la
configuracin de la infraestructura TI y los eventos ocurridos en ella.
De acuerdo a las mejores prcticas ITIL, para disear una base de datos de
configuracin se deben definir el nivel de profundidad y el alcance. Para el caso
particular de la problemtica, es indispensable contar con un modelo que permita un
buen alcance en torno a los Servicios TI y flexibilidad de nivel de profundidad de
atributos de configuracin, segn los datos que ingresen al modelo. Se determino
que el modelo deba manejar en un principio los datos ms generales, como en que
Servicios TI participa el Servidor X?, para luego continuar con datos mas
especficos de configuracin como Cual es la versin del sistema operativo del
Servidor X?.
De acuerdo al anlisis del entorno, los procedimientos estipulados para Gestin de
Incidentes y el anlisis del sistema computacional de gestin (CAPITULO III), los
siguientes conceptos o CI deberan estar incluidos en la CMDB.
1) Servicios TI: Concepto que representa una funcionalidad o facilidad tecnolgica
entregada a un cliente, en ITIL este concepto se identifica como Catlogo de

Servicios TI.
2) Componentes: que en conjunto conforman un Servicio TI. Estos pueden ser de
carcter tecnolgico o una virtualizacin creada para nombrar alguna capacidad

de un Servicio TI.
3) Relaciones Servicios/Componentes: representa como se agrupan los
Componentes, para crear un Servicio TI.

4) Categoras de Servicios TI y de Componentes: clasifica o agrupa de forma
excluyente a Componentes y a Servicios TI.

5) Atributos: representan atributos computables para un objeto Servicio TI o
Componente segn a la categora que pertenezca. La definicin de este concepto

GHDWULEXWRVGH6HUYLFLRV7,\DWULEXWRVGH&RPSRQHQWHVSHUPLWHODIOH[LELOLGDG
QHFHVDULDSDUDLQJUHVDUFXDOTXLHUGDWRTXHVHWHQJDGHODFRQILJXUDFLyQ\SODQLILFDU
GDWRVTXHVHQHFHVLWHQDIXWXUR

6) Personas y Grupos Responsables: este tem incluye
Grupo de Trabajo y sus integrantes: que son aquellos que operan

componentes tecnolgicos y son responsables por los mismos.
Responsable de Servicio y sus integrantes: son aquellos que son responsables

de la continuidad de Servicios TI.
Soporte a Componente: son aquellas instituciones que dan soporte de 2 o de

fabricante de algn componente tecnolgico.
7) Historial: en general de la configuracin de la infraestructura que aprovisiona
los Servicios TI, es decir el modelo debe considerar historial con respecto a:
Atributos de Servicios TI y Componentes.
Servicios TI, Componentes y sus relaciones.
A las relaciones de Cadenas de Servicios y Cadenas de Infraestructura.
Este concepto satisface la necesidad de conservar el registro histrico de la

configuracin.
8) Ventanas Tiempo: tanto de Disponibilidad de Servicio TI, como Ventanas de
Mantencin de algn componente, este concepto es importante para Gestin de

Cambios, ya que provee informacin para la planificacin de los cambios.
9) Fallas o Actividades de Componentes: especifica que actividades se pueden
efectuar sobre un Componente y cuales son las fallas que se pueden presentar en
el mismo. Esto resuelve una grave error de normalizacin del modelo utilizado
por los ticket, ya que se hasta la fecha se han definido repetidas veces las fallas
para componente, en cada servicio en que se encuentra y en cada tipo de ticket
que aparece la falla.
10) Cadenas de Componentes: representa las interrelaciones entre Componentes,
ya sea en el contexto de un Servicio TI o sea Cadenas de Servicio, o relaciones

que representan relaciones de infraestructura o sea Cadenas de Infraestructura.
Este fue uno de los conceptos ms complicado de definir, ya que un componente
adems participar en mas de un servicio, por ejemplo una base de datos Y y el
servidor Z, participan en el servicio X, tambin es necesario describir como esta
instalada dichos componentes en torno a otros componentes, por ejemplo la base
GHGDWRV;HVWDLQVWDODGDHQHOVHUYLGRU<VLQLPSRUWDUHOVHUYLFLRHQHOTXH
SDUWLFLSHQ

B. Artefactos de Diseo CMDB.

a. Modelo Conceptual.
Una vez determinados los conceptos claves del diseo de la CMDB, se construy el diagrama entidad-relacin.
Figura 25: Modelo Entidad Relacin.

b. Modelo de Datos.
De acuerdo al modelo conceptual de entidad-relacin se elabor un modelo de datos, para su implementacin computacional.
Figura 26: Modelo de Datos CMDB.
6
c. Diccionario de Datos.
Se construy el diccionario del modelo de datos, usando el siguiente formato,

ilustrado los siguientes diagramas Warnier-Orr, para las tablas como para los
triggers.
Nombre Tabla
Descripcin
Nombre
Dominio
SI
PK
NO
SI
Tabla
Campos FK
NO
SI
Not Null
NO
Default
Descripcin
Observacin
Figura 27: Diagrama Warnier-Orr, estructura de diccionario de datos para tablas

Nombre Trigger
Descripcin
Before
Tipo
After
Trigger
Insert
Evento Update
Delete
Accin
Figura 28: Diagrama Warnier-Orr, estructura de diccionario de datos para triggers
6
A continuacin se muestran fragmentos del diccionario de datos, de modo de ejemplificar lo sealado anteriormente, el diccionario
de datos es propiedad de Telsur por lo que no se adjunto en este documento.
ATRIBUTOS_SERVICIOS
Tabla
Campos
Nombre
codigo_atributo
codigo_categora servicio
valor
Observacin
Dominio
INTEGER
INTEGER
VARCHAR(100)
PK
SI
SI
FK
SI
SI
Descripcin
NOT NULL
SI
SI
SI
Default
Contiene los valores de los atributos de servicios
Descripcin
Fornea a tipos_atributos_servicios, identifica el tipo de atributo relacionada al registro.
Fornea a categora_servicio, identifica el tipo de categora relacionada al registro
Es el valor del atributo de la categora de servicio.
El trigger T_H_ATRIBUTOS_SERVICIO se encarga de registrar el historial de esta tabla en la tabla H_ATRIBUTOS_SERVICIO

El trigger T_ATRIBUTOS_SERVICIO se encarga de validar, que el atributo sea admisible, segn los atributos admisibles para la
categora que pertenece el servicio.
Tabla 7: diccionario de datos, ejemplo de tabla.
Trigger
T_H_CADENAS_INFRAESTRUCTURA
Tipo
before
Accin
Este procedimiento almacenado ingresa registros en la tabla H_CADENAS_INFRAESTRUCTURA, de la tabla CADENAS_INFRAESTRUCTURA, para efectos de
creacin de un nuevo registro, modificacin o eliminacin. Guardando los atributos histricos, la fecha y hora de la operacin, y un lan_operacin que
corresponde a I en el caso de la insercin de un registro, a U en el caso de la modificacin de un registro y a D en el caso de la eliminacin de un registro.
Evento
Descripcin
Se encarga de llevar el historial de las cadenas de infraestructura.
insert,update,delete tabla CADENAS_INFRAESTRUCTURA
Tabla 8: diccionario de datos, ejemplo de trigger

C. Protocolos de actualizacin de la CMDB.

En el marco de buenas prcticas ITIL, Gestin de Cambios y Gestin de
Configuracin colaboran y se comunican de manera muy estrecha, ya que, en la
implementacin de estos procesos se crean protocolos de actualizacin, es decir las
instancias en las cuales se actualizan y se auditan los registros de la CMDB, esto
queda estipulado y formateado en el flujo del proceso de Cambios.
D. Inconvenientes Esperados.
Dentro de los inconvenientes o puntos a tener en consideracin estn:
Establecer la amplitud y profundidad acorde al problema que se enfrenta, mucho

detalle podra resultar muy difcil de actualizar, poco detalle implica falta de
control.
Recolectar datos sobre la configuracin, que en general estn dispersos a travs

de la organizacin o simplemente no estn documentados.
Mantener los datos actualizados, sobretodo si no hay procesos de Gestin de

Cambios implementados en la organizacin.
Proyectos demasiado ambiciosos y con pocos recursos.
Apoyo de la gerencia insuficiente, en otras palabras e patrocinador debe poder

llevar el costo poltico del proyecto.
6
5.- CAPITULO 5. PRUEBAS DE LA SOLUCION.

5.1 Implementacin de Mdulos de la CMDB.
A. Carga de Datos de Mdulos en produccin.
Con el fin de comprobar que el modelo soporta datos de la configuracin actual de la
infraestructura TI y de los Servicios TI que esta aprovisiona, se levantaron los
siguientes mdulos del diseo en la base de datos de produccin.
a. Creacin de mdulos en BD sis_solinf, con datos crticos.

Para la carga de datos el las fuentes de datos fueron: las planillas (actualizadas) de la
configuracin que maneja ACT Ingeniera, documentacin entregada por algunos
Ingenieros de Sistema Telsur de los servicios a su responsabilidad y por visitas al los
distintos Data Center de Telsur, de forma de validar lo que descrito en la informacin
documentada. De acuerdo a esos datos se implementaron los siguientes mdulos de
tablas de la base de datos sis_solinf en MySql 4, del Servidor Lacar.
Catalogo de Servicios TI, Componentes y sus interrelaciones:

almacenados en las tablas SERVICIOS, COMPONENTES y
SERVICIOS_COMPONENTES.
Cadenas de Servicio: almacenadas en las tablas CADENAS_SERVICIOS y

TIPOS_RELACIONES.
Responsables de Servicios Telsur y Grupos de Trabajo: almacenados en

las tablas RESPONSABLES_SERV , GRUPO_NOTIFICACION_SERV y
GRUPOS.
Atributos de Componentes: almacenados en las tablas

CATEGORIAS_COMPONENTES, ATRIBUTOS_COMPONENTES,
ATRIBUTOS_CATEGORIA_COMPONENTE y
ATRIBUTOS_COMPONENTES.
Estos datos estn orientados a alimentar al proceso de Gestin de Cambios y

proveerle informacin de buena calidad al momento de Evaluar Impacto, que
en otras palabras la afectacin del cambio.

%'LVHxRGHLQWHUID]GHFRQVXOWDDOD&0'%
'HPRGRGHFRQVXOWDUORVGDWRVDQWHULRUHV\GHVSOHJDUORVGHPDQHUDHUJRQyPLFDSDUD
HOSURFHVRGHFDPELRVVHGLVHxyXQDFRQVXOWDEDXWL]DGDFRQHODOLDV1$9(*$'25
&0'%
6
Secciones de la Aplicacin Navegador CMDB.

Seccin 1: Relaciones de Servicios TI y sus Componentes.
Figura 29: seccin 1, Navegador CMDB

Aqu se despliegan los componentes que aprovisionan un Servicio TI seleccionado de la
lista, segn registros de la CMDB.Tambin da la posibilidad de ver todos los
componentes al marcar checkbox No Filtrar.
Seccin 2: Atributos de Componentes.
Figura 30: seccin 2, Navegador CMDB.

Despliega la categora del componente (Base de Datos) seleccionado de la lista en la
seccin 1 y los atributos registrados para dicho componente en la CMDB.

Seccin 3: Cadenas de Servicios y Cadenas de Infraestructura.

Copia el componente seleccionado en la seccin 1 en el centro de los dos paneles y al
presionar el botn Consultar despliega:
1) Si el checkbox Ver Distribucin de Servicios est marcado muestra (con fondo
rosado) las relaciones de entorno del componente en el contexto del Servicio,
seleccionado en la seccin 1.
2) Si el checkbox Ver Distribucin de Infraestructura est marcado muestra (con
fondo azul) las relaciones de entorno del componente en el contexto de la
infraestructura, es decir datos del componente en contexto real.
Todos estos datos se leen desde la CMDB.
Seccin 4: Participacin en otros Servicios del componente.

Muestra otros servicios donde el componente seleccionado en la seccin 1 tambin
participa.

Vista de la aplicacin NAVEGADOR CMDB.
Figura 33: interfaz aplicacin Navegador CMDB

C. Demostracin de uso, con datos de produccin.

Se tuvo la oportunidad de presenciar la instalacin del Servicio Gua Nacional Web
Atento, por lo que se tuvo informacin de su configuracin al momento de ser
instalado, estos datos pueden ser esquematizados como sigue:
Gua Nacional
Web Atento.
Enlace GTD
SERVICIO TI
Hulk (firewall)
PHP 4.4.2
Apache
(Conswins3)
Oracle client
9
COMPONENTES
TECNOLOGICAS
DEL SERVICIO
Oracnt
PSEG
Figura 34: configuracin Servicio Gua Nacional Web Atento

Donde los componentes del servicio son:
Enlace GTD: Enlace dedicado hasta Santiago.
Hulk: Firewall Red Interna Telsur.
Apache: Servidor Web.
PHP 4.4.2: Motor interpretador de pginas PHP.
Oracle Client 9: Software cliente de base de dato Oracle, el cual permite

conexiones directas a travs del servidor.
ORACNT: Base de datos Oracle Telsur, la ms importante de la compaa.

PSEG: Esquema Oracle, contiene informacin de los clientes.
Una vez ingresados estos datos a la CMDB, se pueden consultar en el Navegador

CMDB los datos como sigue:
Paso 1: Clic en el servicio deseado, se despliegan los componentes involucrados.
Paso 2: Clic en botn consultar, despliega las relaciones de entorno.
Paso 3: Clic consecutivo en los links de componentes de la cadena de servicio.

Se destaca con un cuadro, los vnculos presionados en la aplicacin Web.
Figura 35: relaciones de entorno de un componente en Navegador CMDB, antes

para componente Gua Nacional Web
6
Figura 36: relaciones de entorno de un componente en Navegador CMDB, para

componente Enlace GTD (Atento).

componente Hulk (Servidor PW250 4U, Firewall Solaris 9).

componente Apache (Conswins3)
7

componente Oracle Client 9 (Conswins3).

componente ORACNT (BD Oracle).
Estos datos estn integrados con el registro de Ticket en el Sistema de Tickets, es
decir dado el ingreso de estos datos (ms las fallas de los componentes), es posible
registrar Tickets utilizando los datos de configuracin ingresados en la CMDB, tal
como muestra la figura:
7
Figura 39: datos ejemplo en ingreso de un ticket

Esto en otras palabras, esto significa que la CMDB est integrada con el registro de
los Tickets y por ende con los procesos gestionados a travs de este sistema.
5.2 Implementacin Pruebas del proceso de Cambio.

A. Consideraciones de implementacin del procesos ITIL
La siguiente tabla enumera las consideraciones para la implementacin de los
procesos ITIL en la organizacin.
Recomendacin.
Situacin en Telsur.
Tamao de la
Las personas involucradas en los procesos ITIL en la
organizacin.
organizacin son aproximadamente cuarenta, incluyendo

staff de ACT y Help Desk.
Recursos disponibles.
Se disponen de recursos tanto para modificar el sistema de

ticket, como el contratado al alumno en trminos de anlisis,
diseo e implementacin. Tambin se cuenta con el respaldo
poltico del Jefe de Data Center & HW.
Nivel de madurez de
El nivel de capacitacin en ITIL del rea de informtica, es
Staff.
casi nulo, pero la mayora es Ing. Civil Informtico, por lo

que el entendimiento (y posterior cooperacin) de los
objetivos ITIL es muy posible. Por otro lado ACT y Help
Importancia de TI en
Desk cuentan con supervisores capacitados en ITIL.

Telsur corresponde a la categora de empresas TELCO o
la organizacin.
sea empresa de telecomunicaciones, por lo que est

altamente integrada a los sistemas informticos.

El factor cultural.
Como se seal anteriormente hay un alto nivel de

capacitacin profesional en el rea informtica, lo que
sopesa los pocos antecedentes de experiencia en procesos de
calidad.
Tabla 9: de recomendaciones de implementacin de procesos ITIL y situacin en

Telsur.
Adems la literatura ITIL recomienda comenzar la implementacin de forma simple
para los usuarios, eso si, apegndose a lo diseado, de modo de obtener beneficios
LQPHGLDWRVVREUHWRGRSDUDORVTXHVHLQWHJUDQDHVWHQXHYRPRGRGHWUDEDMRGHDFXHUGR
DHVWRVHSURFHGLyFRPRVLJXH
B. Ejecucin del Proceso en Sistema de Tickets.

De modo de implementar en produccin el proceso de cambio, se habilit un nuevo
tipo de ticket, en el Sistema de Ticket, el Ticket de Cambio. A pesar de no contar con
todas las funcionalidades para automatizar el flujo de datos del proceso diseado, se
ejecutarn cambios siguiendo el proceso de cambio, llevando el control de los datos
ms importantes en glosas. Para esto se capacit al rea de informtica de Telsur y a
ACT de modo de minimizar la resistencia al cambio de metodologa.
Puesta en marcha sobre Sistema de Tickets.

Se defini que el ticket debe traer como informacin, adems de los datos
obligatorios de registro, los siguientes campos:
Objetivo del Cambio.
Riesgo: ya sea Menor, Significativo o Mayor.
N Ticket Referencia: Que pudiera aportar con ms antecedentes.
Ventana Propuesta: Si se conoce alguna (opcional).
Adjuntar Planilla de actividades: de acuerdo con una plantilla creada para esto.
A continuacin se muestra un ejemplo del ingreso de dichos cambios.

Figura 40: ejemplo de ingreso de ticket de cambio

A continuacin se muestra el diagrama Warnier-Orr de los campos de la plantilla de
actividades de cambio.
N Actividad
Descripcin
Componente Afectado
Planificacin de Implementacin Detalle Tcnico Actividad
Fecha
Hora
Tiempo Estimado
Grupo de Trabajo
Formulario de Cambio
N Actividad
Descripcin
Componente Afectado
Detalle Tcnico Actividad

Planificacin de Vuelta Atrs
Fecha
Hora
Tiempo Estimado
Grupo de Trabajo
Figura 41: diagrama Warnier-Orr de plantilla formulario de actividades de cambio.

Dicho ticket se procesar utilizando los estados definidos en el Sistema de Ticket en
las distintas fases del proceso tal como muestra la figura.

4)
1)
2)
3)
IMPLEMENTACION
ACEPTACION.
EVALUACION IMPACTO.
APROBACION.
5)
CIERRE
Figura 42: estados sistema ticket y proceso de cambio.

Si se da el caso que el ticket tiene ms de un involucrado en su implementacin,
segn el plan de actividades, se crean y aprueban inmediatamente los cambios
asignados a los distintos Grupos de Trabajo, similar a ordenes de trabajo. Tal como
muestra a figura.
Ticket Cambio.
Plan
actividades.
Ticket Cambio.
Ticket Cambio.
Plan
actividades.
Ticket Cambio.
Plan
actividades.
Plan
actividades.
Figura 43: diagrama de tickets creados para implementar con actividades que
involucren ms de un Grupo de Trabajo.
De esta forma se lanz el proceso en el rea de informtica, con lo que se puso a
prueba la efectividad del diseo elaborado.

6.- CAPITULO 6. IDENTIFICACION DE LOGRO A TRAVEZ DE

METRICAS.
6.1 Identificacin de Logro CMDB.
A continuacin se muestran mtricas extradas de los objetivos sealados en la
documentacin de mejores prcticas ITIL acerca de la Base de Datos de
Configuracin o CMDB.
Mtrica.
Logro
Observacin.
Porcentual.
Integracin con procesos
75%
ITIL.
Gestin de Cambios est completamente

integrada a la CMDB, el resto de los procesos
se alimenta de ella para el lanzamiento de los
flujos.
Alimentar a los procesos
100%
La CMDB est disponible para consultas Ad-
ITIL de informacin de
Hoc sobre la configuracin de los Servicios
la configuracin.
Telsur.
Capacidad de representar
100%
la configuracin.
El modelo est diseado para representar la

configuracin segn los datos encontrados
tanto en el desarrollo del proyecto, como en
los datos proyectados a futuro.
Capacidad para estar
25%
actualizada.
Se especificaron los programas mantenedores,

los cuales no estuvieron disponibles dentro
del desarrollo del proyecto, en su reemplazo
se utilizaron interfaces provisorias.
Conectividad
No Aplica.
Este parmetro no aplica, ya que ste es el
automatizada con
nico repositorio de configuracin de
repositorios de
implementado la organizacin para la
configuracin.
infraestructura TI.
Capacidad de llevar el
100%
La CMDB es el registro de los sucesos sobre
historial de los sucesos
de los componentes de la infraestructura
en la infraestructura.
registrados a travs de los tickets, bondad

heredada del trabajo del diseo computacional
de el Sistema de Tickets.
Logro Total.
75%

Tal como muestra el ndice de logro total, el diseo de la CMDB es altamente

efectivo, siendo un punto a considerar a futuro la conectividad con algn repositorio
que monitoree la configuracin de la infraestructura TI actualice los datos en lnea.
6.2 Identificacin de Logro del Proceso de Gestin de Cambios.

Las mtricas desplegadas a continuacin fueron tomadas directamente de la
ejecucin del proceso en Telsur, siendo el parmetro ms importante el resultado
final del proceso, calificado en el mismo como Exitoso, Falla Menor o Falla
Mayor. A continuacin se despliegan los datos tabulados.
Mtrica.
Cantidad.
Observacin.
Cambios Exitosos.
22
Se cumple el objetivo del cambio y no se

afectaron de forma inesperada la disponibilidad
de los servicios.
Cambios Falla Menor.
El objetivo no se satisfizo completamente, hubo

falla en procesos computacionales o corte
parcial de procesos no crticos
Cambios Falla Mayor.
El objetivo no se cumpli e incluso hubo

afectacin de otros Servicios TI.
Tabla 11: de Mtricas de logro para el Proceso de Gestin de Cambios

Grfico de Mtricas del Proceso de Cambio.
24
21
18
15
Cantidad. 12
9
6
3
0
Cambio Exitoso. Cambio con Falla

Menor.
Cambio Falla
Mayor.
Figura 44: grfico de mtricas del proceso de cambio.

El logro del proceso, tal como muestra la figura es alto, esto es sin duda porque no
exista un proceso de control de este tipo, es decir como es el primer medio de
control de cambio implementado, sus resultados son absolutamente positivos y
resalta la necesidad de un procedimiento de control. De estas estadsticas podran
estar deviadas (de forma mnima) por los siguientes factores:
Pocas Falla Mayor: el Jefe de Data Center & Hardware, no aprob cambios
que considero muy arriesgados e innecesarios.
Altas Falla Menor: misma inexperiencia del ejecutor de este proyecto,

puede haber provocado dejar de lado detalles en la planificacin de los
cambios, que una persona con ms experiencia podra haber cubierto.
6.3 Aplicabilidad del proceso.

Una vez ejecutado el proceso en la organizacin se efectu un anlisis crtico de su
aplicabilidad, a travs sus tres grandes aristas de diseo.
a. Aplicabilidad de Estados de un Cambio.

Se pudo comprobar que los estados definidos permiten llevar el control del flujo de
los cambios, las deficiencias se observaron por parte de transiciones de estados que
no se haban considerado, tambin se dio el caso de que algunos estados nunca
fueron utilizados. A continuacin se tabulan los estados ms utilizados, las
transiciones faltantes y los estados menos utilizados.
Estado
Registrado.
Recibido.
En evaluacin.
Pendiente Aprobacin.
Aprobado sin Planificacin.
En Implementacin.
En Evaluacin Cierre.
Cerrado.
Tabla 12: estados de cambio ms utilizados.

Estado Inicial.
Estado Final
Recibido.
Pendiente por Usuario.
En Evaluacin.
En Evaluacin.
Tabla 13: de transiciones faltantes
Estado
Observacin.
Cancelado por Usuario.
En general los cambios solicitados son

cambios necesarios y su vigencia no caduca.
Cancelado.
Este estado es a continuacin del nombrado

anteriormente, por lo que la razn de su poca
utilizacin fue la misma.
Rechazado.
Para estar acorde con la orientacin de

servicio a cliente los cambios ingresados que
no eran tal, fueron reingresados en el sistema
de manera correcta, por otro lado, se
ejecutaron las gestiones para que los cambios
corrigiera sus razones de posible rechazo
(falta de informacin o parmetros
requeridos).
Aprobacin Agendada.
Este estado no fue utilizado principalmente

porque los casos de cambio fueron analizados
con prontitud, haciendo innecesaria la
agendacin de la aprobacin, lo ms probable
que con la consolidacin de un CAB este
estado tome un gran valor.
En Implementacin de
Este estado se hizo innecesario en cuanto se
9
Roll-Back.
defini con operador que el plan de vuelta a

atrs es efectivo para cualquier caso en donde
durante la implementacin exista un error.
Tabla 14: estados de cambio menos utilizados.
En general los estados diseados ajustan a lo que debe controlar el cambio, incluso el
diseo consider que alguno de estos, por no decir todos, deberan estar como flujo
del computacional en un sistema ms automatizado de lo que se encuentra hoy en el
Sistema de Tickets.
b. Aplicabilidad de Actividades.
A continuacin se tabula el anlisis de las actividades ms importantes, o sea,
aquellas que agregan ms valor a la gestin de un cambio y se describen las
actividades que se proponen agregar, siempre desde el punto de vista de lo
recopilado de las pruebas del proceso de cambio en la organizacin.
Fase
Actividad
Observacin
Es un cambio?
Es importante canalizar de forma correcta,

que
requerimiento
corresponde
efectivamente a un cambio.
Aceptacin.
Antecedentes
Importante para alimentar de informacin de
suficientes?
calidad al resto del flujo.
Reunir informacin Actividad que el usuario solicitante debe

faltante.
efectuar con celeridad y correctamente, para

evitar ciclos en el flujo.
Evaluacin
Evaluacin.
Es esta actividad en donde los responsables
Impacto Servicios de
TI Telsur.
servicios
responsabilidad
Telsur
para
toman
la
parte
ejecucin
y
del
cambio.

Evolucin Impacto Es en esta actividad donde el administrador

Componentes
de infraestructura tecnolgica o los expertos
especificados en la
Existen
otros
planificacin.
involucrados aparte
en TI toman parte y responsabilidad para la

Es en esta actividad donde se consultan datos
ejecucin del cambio.
a la CMDB, es decir aqu quedar en
del CAB?
evidencia el valor y veracidad dichos datos.
Entregar
Proporciona informacin que se solicita
antecedentes
segn reunin del CAB.
faltantes.

Aprobacin
del Decide implementar el cambio o rechazarlo.
Cambio?
Aprobado
Aprobacin
con Discrimina el hecho de condicionar la
condiciones?
Aprobado
implementacin de un cambio.
con Discrimina el hecho de que no existe
planificacin?
planificacin en un cambio, siendo este un

cambio necesario.
Planificacin.
Planificar
El xito de un cambio depende en buena
Actividades.
manera de la fecha en que sus actividades se

implementarn.
Registrar Trmino Importante para llevar un control efectivo

de Actividades.
del progreso del cambio.
Es necesario re- Esta actividad obliga la necesidad de

planificar?
respetar
las
ventanas
dispuestas
para
implementar el cambio, sino se debe re-
Implementacin
planificar.
Hubo degradacin Es importante mantener el contacto con los
de
Servicios usuarios de los servicios, a travs del Help
Telsur?
Desk.
Actualizar CMDB.
Esta actividad es clave para mantener la

CMDB actualizada, a travs de los cambios.
Cierre.
Evaluacin
Segn el resultado de esta actividad se
Positiva?
califican los cambios como Exitosos, con

Falla Menor o Falla Mayor.
Tabla 15: de actividades ms importante en el proceso de cambio.

Se propone agregar las siguientes actividades generales en fase de Aceptacin:

Definir antes de la aceptacin de un cambio, si este requiere la entrega inmediata

del Manual de Operacin, con el propsito de que ACT haga efectivo el
soporte tcnico de alguna instalacin de un nuevo servicio.
Si el usuario no conoce las actividades que son necesarias para implementar el

cambio, al menos debera proponer una ventana de implementacin de lo
solicitado en su cambio, adems los Grupos de Trabajo deben soportar la
creacin del plan de implementacin tcnico.
Dadas estas actividades, el proceso de cambio contiene informacin que permite

tramitar las dems fases del proceso de manera clara.
c. Aplicabilidad de Formularios.
A pesar de que en las pruebas echas en Telsur, no se llev seguimiento de todos los
datos diseados en los formulario por un tema de volumen de datos, se destaca la
importancia y efectividad de las siguientes secciones del formulario.
Seccin.
Observacin.
Seccin A: Informacin
Da formato al ingreso de la informacin general del
General.
cambio.
Seccin B: Ingreso de
Da formato a los campos requeridos para el ingreso de
Actividades de
una actividad de cambio.
Implementacin.
Seccin C: Ingreso de
Da formato a los campos requeridos para el ingreso de
Actividades Back-Out.
una actividad de cambio.
Seccin D: Resumen
Entrega una visin general de las tareas del cambio.
Actividades de Cambio.
8
Seccin E: Resumen
Entrega una visin general de las tareas de Back-Out de
actividades de Back-Out
un cambio.
de Cambio.
Seccin J: Evaluacin de
Da formato a los campos necesarios en una evaluacin
Impacto a Servicios TI.
de Impacto a Servicios TI.
Seccin K: Evaluacin de
Da formato a los campos necesarios en una evaluacin
Impacto a Componentes
de impacto a Componentes TI.
TI.
Seccin Q: Evaluacin de
Cierre.
Da formato a los campos que califican el cierre de un

cambio.
Seccin R. FSC de
Entrega una visin general de los cambios planificados,
Cambios.
a modo de tener informado al rea de informticas y

otros interesados.
Seccin T: Resumen
Entrega una visin general de las opiniones tcnica de
Evaluacin de Servicio y
los convocados a entregar su evaluacin de impacto.
Componentes TI,
involucrados en el
cambio.
Seccin V: Resumen de
Muestra las condiciones de aprobacin del cambio
condiciones de
Aprobacin de Cambio.
Seccin AD: Resumen
Permite tener un resumen de las personas involucradas
notificados para la
en un cambio.
evaluacin del cambio.

Tabla 16: de secciones ms importantes del formulario de cambio.
La interpretacin final de estos datos sugiere que:
Se integren los datos al sistema computacional los datos definidos en el diseo
elaborado por el proyecto.

Se reduzca el volumen de los datos manejados, de acuerdo al anlisis de

aplicabilidad del proceso anterior.

7.- CAPITULO 7. CONCLUSIONES.

7.1
Mejoras, Factores Crticos de xito a Largo Plazo.
Entre las recomendaciones a largo plazo para el xito duradero en la organizacin del
diseo:
Planificar carga de datos masiva CMDB y un responsable de la CMDB:

es necesario planificar una carga masiva de datos, con el porosito de que la
CMDB proporcione datos (an mas) orientados a la Gestin Servicios TI.
Responsable de proceso de cambio Telsur: se hace absolutamente

necesario dejar la responsabilidad a un cargo que pueda asumir el costo
poltico en la organizacin del proceso de cambio.
Invertir en SW de Gestin de Cambio: Es necesario invertir en una

herramienta que apoye el flujo y los datos generados por el proceso de
cambio.
7.2 Beneficios en Telsur.

Primer paso en cambio cultural, verificacin de necesidad de un responsable de
cambio, base de datos bien planificado e integrado con Sistema de Tickets,
definicin detallada del proceso.
Ente los beneficios observados para Telsur son:
Primeros pasos hacia un cambio cultural: desde el inicio del proyecto se

dio a entender a los funcionarios del rea de informtica de la importancia
que la subgerencia tiene en temas relacionados con la implementacin de
mejores prcticas ITIL a sus funciones.
Verificacin de necesidad de un responsable de cambio: durante el trabajo

realizado en las pruebas, qued en evidencia la necesidad de crear una
funcin que se encargue de velar por el cumplimiento del proceso.
Base de Datos de Configuracin bien planificada e integrada con sistema

de tickets: el diseo permite ingresar datos de configuracin de muy distinta
naturaleza durante mucho tiempo, datos que al mismo tiempo son utilizados
en el registro de nuevos casos en los tickets y para consultas por casos
antiguos.
'HILQLFLyQGHWDOODGDGHOSURFHVRHOSURFHVRHVWDGHWDOODGRDXQQLYHOTXHHV
IiFLOGLVWLQJXLUFXDOHVVHFFLRQHVGHOPLVPRVRQFDQGLGDWRVDVHUDXWRPDWL]DGRV
FRPSXWDFLRQDOPHQWH

7.3 Conclusin General.

La implementacin de ITIL es un foco relativamente nuevo para las empresas
chilenas, su implementacin requiere la experiencia necesaria para generar un diseo
a medida y para lidiar con las coyunturas que surgen cuando a los funcionarios del
rea se someten a procesos de calidad como los recomendados por ITIL. Es
necesario contar con los recursos polticos, humanos y tecnolgicos para intentar
obtener beneficios rpidamente, de modo de eliminar la resistencia de la
organizacin al cambio.
Es muy recomendable, para el que disea, estudiar o incluso involucrarse en la
problemtica de la organizacin, antes de trazar cualquier diseo y adems estar
altamente capacitado en modelamiento de procesos administrativos.
Sin duda ITIL ser la base para cualquier organizacin que pretenda profesionalizar
la administracin de la infraestructura tecnolgica, de todas formas sta representa el
perfil de una meta, otra cosa muy distinta es como las empresas se organizan para
llegar a esta meta, por supuesto, las nombradas anteriormente representa las formas
mas importantes apreciadas en este proyecto.

REFERENCIA
[PRO04] Prometric, pgina oficial ITIL Latinoamrica. Disponible en
http://www.itil.com.ar/intro_chi.html. Consultada en agosto 2007.
[JHO07] Shane Johnson, artculo web, ITIL no longer the awkward adolescent.
Disponible http://infoage.idg.com.au/index.php/id;449018606;fp;16;fpid;0. Consultada
en agosto 2007.
[BOO01] Glenn Booker, JCALS Quality Management Organization, artculo web,
Process Definition Overview. Dsiponible en
http://users.snip.net/~gbooker/ISYS205/process_definition.pdf. Consultado en
septiembre 2007.
[SAL06], Jaime Salas, LYNX IT Service Managment, artculo Tecnologas de
Informacin para Soporte de Sistemas. Disponible en
http://www.inlac.org/documentos/28-4.pdf. Consultado en octubre 2007.
[SHU] Ferry Schurter, Smartdraw Software, artculo web Best Practices in Business
Graphics. Disponible en
http://www.smartdraw.com/solutions/whitepapers/Business_Processes_SmartDraw_Wh
ite_Paper.pdf. Consultado en septiembre 2007.
[TUR07] Ken Turbita, BMC Software Inc., white paper Es possible utilizar solucin
ITIL Out of the Box. Disponible en
http://documents.bmc.com/products/documents/08/30/70830/70830.pdf. Consultado en
octubre 2007.
[EVE07] Evergreen Systems Inc., artculo Developing the Business Case for Change
and Configuration Management and the CMDB. Disponible en
http://www.evergreensys.com/resources/buscasecmdb/. Consultado en agosto 2007.
[PAR07] Parity Group, artculo Where is ITIL now,Where next?. Disponible en
http://www.parity.net/documents/pdf/whitepaper/ParityWhere_is_ITIL_now_whitepaper.pdf.
Consultado septiembre 2007.
[MAR07] Hank Marquis, itSM Solutions, artculo ITIL Version 3.0 What It Means to
You. Diponible en
http://images.globalknowledge.com/wwwimages/whitepaperpdf/WP_ITILv3.pdf.
Consultado agosto 2007.

[ASS05] Assenti, Consultora de TI para Negocios, artculo Descubriendo ITIL.

Disponible en http://www.cepra.com.mx/itil.pdf. Consultado septiembre 2007.
[OSI07] Osiatis, consultora multinacional, articulo Curso ITIL. Disponible en
http://www.osiatis.es/index.php. Consultado en junio 2007.
[TSC03] Documentacin oficial ITIL version 2.0, Service support versin 2.0,
publicado por TSC para OGC en CD-Rom. Consultado en septiembre 2007.
[EMA05] Enterprise Management Associates Inc., artculo Planning for CMDB Design
and Adoption: An Industry Colloquium. Disponible en
http://whitepapers.zdnet.co.uk/0,1000000651,260166364p,00.htm. Consultado en agosto
2007.
[SER07] Service Now Wiki, foro abierto y soportado por empresa consultora ITIL,
artculo ITIL Change Management, request of change examples. Disponible en
http://wiki.service-now.com. Consultada en noviembre 2007.
[BMC07] BMC Software Inc.., artculo modelo conceptual de datos CMDB Atrium.
Disponible en http://documents.bmc.com/supportu/documents/00/86/70086/70086.pdf.
Consultada en octubre 2007.
[PRES05] Presuman, Roger S., Ingeniera del Software, publicado por Editorial
McGraw-Hill en 2005. Consultado en septiembre 2007.
[SEN02] Senn, James. Analisis y Diseo de Sistemas de Informacin, publicado por
Editorial McGraw-Hill en 1992. Consultado en septiembre 2007.

Gestion Cambios

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Gestion Cambios

Uploaded by

Copyright:

Available Formats

Universidad Austral de Chile

Facultad de Ciencias de la Ingeniera

Diseo de Procesos de Gestin de Cambios basados

CHRISTIAN ANDRS MATUS RAMREZ

Figura 36: relaciones de entorno de un componente en Navegador CMDB,

1.2 Introduccin al Contexto del Proyecto.

de un repositorio unificado y nico para toda la organizacin de la configuracin de

Consolidar el conocimiento de la configuracin de la infraestructura TI, por ende

Mejorar la estimacin del impacto, si es que se efecta para una modificacin a

Coordinar de mejor forma los trabajos sobre la infraestructura tecnolgica, por

1.4 Objetivos del Proyecto.

2.- CAPITULO 2. ANALISIS MEJORES PRCTICAS ITIL.

Describe los objetivos y metas principales en la administracin TI .

Actividades y fases generales.

Entradas/Salidas de mltiples procesos.

No pretende describir las operaciones del da a da.

Los elementos ITIL pueden ser incorporados evolutivamente a las organizaciones,

dirigida por sus miembros (Organizaciones,

Acredita un conocimiento bsico de ITIL en gestin de

Destinado a quienes tienen responsabilidad en el diseo

actividades asociadas a los procesos. Este examen slo se

Manager's Garantiza que quien lo posee dispone de profundos

conocimientos en todas las materias relacionadas con la

Solo estaba disponible la certificacin de IT Service Manager, la ms

Se crean las certificaciones ITIL Foundations y ITIL Particioner,

respectivamente, creando los niveles bsicos y intermedio en los

Del total de 44 libros, se condensan en 10 tomos, los cuales adoptan el

nombre de ITIL versin 1. En consecuencia de lo anterior, el foco de la

Se iniciaron los trabajos de lanzar una nueva versin de ITIL,

Se lanza oficialmente ITIL versin 3.

Figura 1: cinco focos de las buenas prcticas ITIL

Business Perspective: Libro que cubre el rango de problemas concernientes al

Service Delivery: Libro que describe las principales consideraciones en la entrega

Services Support: Libro contiene las recomendaciones dirigidas al aseguramiento

Manage the Infrastructure: Incluye recomendaciones para operacionales sobre la

Managing Applications: Libro que contiene recomendaciones que estn sujetas a

A. Arquitectura de Service Support.

Figura 2: diagrama relaciones procesos ITIL

Organizacin, Clientes y Usuarios: Son todos aquellos que utilizan Servicios TI

o Sirviendo de punto nico de registro y escalamiento de incidentes (en

Gestin de Problemas: Se encarga de investigar causas subyacentes a cualquier

Gestin de Cambios: Sus principales actividades son.

Gestin de Versiones: Se encarga de:

Gestin de Configuraciones: Sus actividades principales son.

2.3 Gestin de Cambios.

Cambio.Es todo proyecto o actividad que cambie la configuracin de la infraestructura

RFC, Request For Change o Formulario de Cambio.

Estimacin de recursos necesarios para la

o Estado: que inicialmente ser el de "Registrado".

FSC, o Programa Adelantado de Cambio.

c. Proceso de Gestin de Cambio.

Figura 3: diagrama actividades de Gestin de Cambios.

Gestin de Problema: Se pretende solucionar un problema a travs de un

Nuevos Servicios TI: El cambio pretende la configurar la infraestructura con el

Normal: Es conveniente realizar el cambio pero siempre que ello no entorpezca

Urgente: es necesario resolver un problema que esta provocando una

Convocar la participacin de grupos de expertos tcnicos: Los cuales deben

Por su parte, el Change Manager debe asegurar se realice la Evaluacin de

Finalmente, se deben determinar y aprobar las fechas en las que se va a proceder

En general estas actividades deben ser apoyadas por herramientas de gestin

Informar a profesionales de la informtica y expertos tcnicos de los trabajos

Se cumplieron los objetivos previstos?

En que medida se aparto el proceso de las previsiones realizadas por la Gestin