gestion_cambios

8/17/2019 GESTION_CAMBIOS

1/97

Universidad Austral de Chile Facultad de Ciencias de la IngenieríaEscuela de Ingeniería Civil en Informática

CHRISTIAN ANDRÉS MATUS RAMÍR VALDIVIA - CHILE

2008

“Diseño de Procesos de Gestión de Cambios basa

en ITIL y de una Base de Datos de ConfiguraciónTelsur ”

Profesor Patrocinante:Sr. Gabriel Morales AvendañoIngeniero Civil en InformáticaMagister in Bussines Administration.

Profesor Co-Patrocinante:Sr. Luís Hernán Vidal Vidal.Ingeniero Civil en Informática.

Tesis para optar al título de:Ingeniero Civil en Informática


2/97


3/97


4/97


5/97


6/97


7/97

Dedicatoria.A nadie podría dedicar este trabajo, más que a ti, mamá.

Agradecimientos.A mi compañera de vida DAYI.

A los valiosos consejos de los profesores Luís Vidal, Martín Solar y Juan Pablo Salazar.

A mi patrocinante, Gabriel Morales, por todo lo que aprendí trabajando con él y sobretodoenseñado desinteresadamente.

Al área de informática de Telsur, por la paciencia al que está aprendiendo.


8/97

Resumen.

En la empresa local Telefónica del Sur S.A. existe una parcial implementaciónde ITIL. Siendo de carácter urgente y necesario, para el caso en particular, laincorporación de más elementos de la metodología en la organización, deforma que aumente la eficacia de la administración de la infraestructura TI y por ende mayor beneficio al negocio.

De lo anterior es donde nace el foco de este proyecto, el diseñar procesos y políticas que permitan dar calidad a la gestión de la infraestructura, basando enalgún modelo de conocimiento teórico, como es ITL. Por calidad se entiendeen este caso que, las actividades de explotación y creación de nuevasconfiguraciones a la infraestructura TI, no deteriore los servicios al clientefinal.

Hasta la fecha se han implementado procesos relacionados con Gestión deIncidentes, los cuales están orientados a mantener el servicio tecnológicodisponible, minimizando principalmente las caídas del servicio final a losclientes, sin posibilidad de planificar mejoras o evaluar impactos.

En este proceso de avance se han dejado fuera Gestión de Cambios y Gestiónde Configuración, donde el primero está orientado a la administración de lainfraestructura tecnológica que la soporta, el segundo se encarga de laconstrucción de un repositorio unificado y único para toda la organización dela configuración de los componentes tecnológicos, además de los procesos deactualización de la misma, que en ITIL se reconoce formalmente como “ Basede Datos de Gestión de Configuración” o “CMDB ” por sus siglas en inglés.

Los resultados esperados, en consecuencia con lo expuesto anteriormente,estarán relacionados con reducir el riesgo por fallas en la infraestructura TI,aumentar la eficiencia y la calidad del servicio, utilizando un estándar líder enel mundo en el tema.


9/97

Abstract.

In Telefónica del Sur, a local corporation, it exists a partial implementation ofITIL. The incorporation of more elements of this methodology into theorganization is urgent and necessary, in order to increase the effectiveness ofthe administration on IT infrastructure and hence increase the benefits to business.

The focus of this project arises from the above mentioned: the design of processesand policies so as to provide quality infrastructure management, based on a model oftheoretical knowledge as ITL. Quality is defined in this case as the operation andcreation of new configurations in IT infrastructure, without deteriorating services tofinal customers.

To date, management processes related to incidents have been implemented, whichare designed to keep technological service available, minimizing mainly the falls inthe service provided to final customers, without possibility of planningimprovements or assessing impacts.

In this process of implementation, the areas of Change Management andConfiguration Management have been left out. The first aims at managing thetechnological infrastructure which supports the process, whereas the second isresponsible for building a unified and single repository for the entire organization ofthe configuration of the technological components, in addition to the processes ofupdating it. This concept is formally known in ITIL as "Database ManagementSettings", or "CMDB", its English acronym.

The expected results, in accordance with the above mentioned, will be related toreduce the risks of failure in IT infrastructure; increase the efficiency and quality ofthe service, using a world class standard, leader within the industry.


10/97

Indice de Contenido.

CAPITULO 1. INTRODUCCION1.1 ¿Que es ITIL? ............................................................................................................. 51.2 Introducción al Contexto del Proyecto. ................................................................... 51.3 Detalle de metas esperadas. ...................................................................................... 61.4 Objetivos del Proyecto .............................................................................................. 6

CAPITULO 2. ANALISIS MEJORES PRÁCTICAS ITIL. ....................................... 82.1 Visión/Misión general ITIL. ...................................................................................... 82.2 Arquitectura ITIL. ................................................................................................... 102.3 Gestión de Cambios. ................................................................................................ 142.4 Gestión de Configuración ........................................................................................ 22

2.5 Planificación de Implementación. ........................................................................... 232.6 Consideraciones de Diseño. ..................................................................................... 242.7 Modelo Unificado. .................................................................................................... 25

CAPITULO 3. ANALISIS DE LA PROBLEMÁTICA. ............................................ 263.1 Análisis del Entorno. ................................................................................................ 263.2 Análisis del sistema computacional de gestión vigente ........................................ 30

CAPITULO 4. Diseño de la Solución. .......................................................................... 414.1 Diseño de Proceso de Cambio ................................................................................. 41

4.2 Diseño de la CMDB ................................................................................................. 66

CAPITULO 5. Pruebas de la Solución. ........................................................................ 735.1 Implementación de Módulos de la CMDB ............................................................. 735.2 Implementación Pruebas del proceso de Cambio. ............................................... 81

CAPITULO 6. IDENTIFICACION DE LOGRO A TRAVEZ DE METRICAS. ... 866.1 Identificación de Logro CMDB. ............................................................................. 866.2 Identificación de Logro del Proceso de Gestión de Cambios. .............................. 886.3 Aplicabilidad del proceso. ....................................................................................... 90

CAPITULO 7. CONCLUSIONES. ............................................................................... 967.1 Mejoras, Factores Críticos de Éxito a Largo Plazo ............................................. 967.2 Beneficios en Telsur. ................................................................................................ 967.3 Conclusión General. ................................................................................................. 97


11/97

Indice de Figuras.

Figura 1: cinco focos de las buenas prácticas ITIL ..................................................... 10Figura 2: diagrama relaciones procesos ITIL ............................................................. 12Figura 3: diagrama actividades de Gestión de Cambios. ........................................... 17Figura 5: ejemplo diagrama de flujo proceso cambio ................................................ 21Figura 6: que muestra los conceptos de “Alcance” y “Profundidad” unificados

en el ejemplo. ............................................................................................................... 25Figura 7: esquema de relaciones de actores del entorno del problema ..................... 27Figura 8: interfaz para nuevo ticket ............................................................................. 31Figura 9: bitácora de un ticket. ..................................................................................... 32Figura 10: Interfaz “Consulta General”. ..................................................................... 32Figura 11: interfaz con botones para modificar estado de un ticket ......................... 34Figura 12: interfaz “Servicios TI versus Grupos de Trabajo .................................... 35Figura 13: interfaz “Servicios TI versus Tiempo de Vida .......................................... 35Figura 14: tablas que guardan configuración de Servicios, Componentes y

Fallas, en Sistema de Tickets ..................................................................................... 36Figura 15: Diagrama de Transición de estados de un Ticket en el “Sistema de

Tickets”. ....................................................................................................................... 38Figura 16: Diagrama Flujo de “Gestión de Cambios” de alto nivel ......................... 51Figura 17: Diagrama de Flujo Funciones Cruzadas “Fase Aceptación”. ................. 52Figura 18: Diagrama de Flujo Funciones Cruzadas “Fase Evaluación” .................. 53Figura 19: Diagrama de Flujo Funciones Cruzadas “Fase Aprobación y

Evaluación” ................................................................................................................. 55Figura 20: Diagrama de Flujo Funciones Cruzadas “Fase Aprobación y

Evaluación” ................................................................................................................. 56Figura 21: Diagrama de Transición de Estados de un Cambio ................................. 58Figura 22: Formulario de Cambio, Sección A: Información General ...................... 60Figura 23: Diagrama Warnier-Orr de estructura de información en Tabla

Correlación Nº 1. ......................................................................................................... 61Figura 24: Diagrama Warnier-Orr de estructura de información de Tabla de

Correlación Nº 2. ......................................................................................................... 63Figura 25: Modelo Entidad Relación. .......................................................................... 68Figura 26: Modelo de Datos CMDB ............................................................................. 69Figura 27: Diagrama Warnier-Orr, estructura de diccionario de datos para

tablas ............................................................................................................................ 70Figura 28: Diagrama Warnier-Orr, estructura de diccionario de datos para

triggers ......................................................................................................................... 70

Figura 29: sección 1, Navegador CMDB ..................................................................... 74Figura 30: sección 2, Navegador CMDB ...................................................................... 74Figura 31: sección 3, Navegador CMDB ...................................................................... 75Figura 32: sección 4, Navegador CMDB ...................................................................... 75Figura 33: interfaz aplicación “Navegador CMDB .................................................... 76Figura 34: configuración Servicio Guía Nacional Web Atento ................................. 77Figura 35: relaciones de entorno de un componente en “Navegador CMDB”,

antes para componente “Guía Nacional Web .......................................................... 78


12/97

Figura 36: relaciones de entorno de un componente en “Navegador CMDB”,para componente “Enlace GTD (Atento)”. .............................................................. 79

Figura 37: relaciones de entorno de un componente en “Navegador CMDB”,para componente “Hulk (Servidor PW250 4U, Firewall Solaris 9 ........................ 79Figura 38: relaciones de entorno de un componente en “Navegador CMDB”,para componente “Apache (Conswins3)” ................................................................. 79

Figura 39: datos ejemplo en ingreso de un ticket ........................................................ 81Figura 40: ejemplo de ingreso de ticket de cambio ..................................................... 83Figura 41: diagrama Warnier-Orr de plantilla formulario de actividades de

cambio .......................................................................................................................... 84Figura 42: estados sistema ticket y proceso de cambio. .............................................. 84Figura 43: diagrama de tickets creados para implementar con actividades que

involucren más de un Grupo de Trabajo ................................................................. 85Figura 44: gráfico de métricas del proceso de cambio................................................ 89


13/97

Indice de Tablas.

Tabla 1: niveles certificación ITIL ................................................................................. 9Tabla 2: hitos históricos ITIL. ...................................................................................... 10Tabla 3: de cumplimiento de criterios de elección de herramienta y el

cumplimiento de estos del sistema de tickets ............................................................ 39Tabla 4: recomendaciones mejores práctica, para el proceso de gestión de

cambios ........................................................................................................................ 43Tabla 5: correlación para fase de aceptación del proceso de cambio. ...................... 62Tabla 6: correlación para fase de aceptación del proceso de cambio ....................... 64Tabla 7: diccionario de datos, ejemplo de tabla. ......................................................... 71Tabla 8: diccionario de datos, ejemplo de trigger ....................................................... 71Tabla 9: de recomendaciones de implementación de procesos ITIL y situación

en Telsur ...................................................................................................................... 82Tabla 10: de Métricas de logro para la CMDB implementada .................................. 87Tabla 11: de Métricas de logro para el Proceso de Gestión de Cambios .................. 88Tabla 12: estados de cambio más utilizados. ............................................................... 90Tabla 13: de transiciones faltantes ............................................................................... 91Tabla 14: estados de cambio menos utilizados. ........................................................... 91Tabla 15: de actividades más importante en el proceso de cambio. .......................... 93Tabla 16: de secciones más importantes del formulario de cambio. ......................... 95


14/97

5

CAPITULO 1. INTRODUCCION.

1.1 ¿Que es ITIL?

ITIL son las siglas de una metodología desarrollada a finales de los años 80’s por

iniciativa del gobierno del Reino Unido, específicamente por la OGC u OficinaGubernativa de Comercio Británica (Office of Goverment Comerce). Las siglas deITIL significan (Information Technology Infrastructure Library) o Librería deInfraestructura de Tecnologías de Información y fue creada exclusivamente para laadministraciónde infraestructura tecnológica de una corporación.

Esta metodología es la aproximación más globalmente aceptada para la gestión deservicios de Tecnologías de Información, ya que es una recopilación de las mejores

prácticas tanto del sector público como del sector privado, mejores prácticas, que sedan en base a toda la experiencia adquirida con el tiempo en el área.

1.2 Introducción al Contexto del Proyecto.

En la empresa valdiviana Telefónica del Sur S.A. existe una parcial implementaciónde ITIL. Siendo de carácter urgente y necesario, para el caso en particular, laincorporación de más elementos de la metodología en la organización, de forma que

aumente la eficacia de la administración de la infraestructura TI y por ende mayor beneficio al negocio.De lo anterior es donde nace el foco de este proyecto, el diseñar procesos y políticasque permitan dar calidad a la gestión de la infraestructura, basando en algún modelode conocimiento teórico, como es ITL. Por calidad se entiende en este caso que, lasactividades de explotación y creación de nuevas configuraciones a la infraestructuraTI, no deteriore los servicios al cliente final.Hasta la fecha se han implementado procesos relacionados con Gestión de

Incidentes, los cuales están orientados a mantener el servicio tecnológico disponible,minimizando principalmente las caídas del servicio final a los clientes, sin posibilidad de planificar mejoras o evaluar impactos.En este proceso de avance se han dejado fuera Gestión de Cambios y Gestión deConfiguración, donde el primero está orientado a la administración de lainfraestructura tecnológica que la soporta, el segundo se encarga de la construcción


15/97

6

de un repositorio unificado y único para toda la organización de la configuración delos componentes tecnológicos, además de los procesos de actualización de la misma,que en ITIL se reconoce formalmente como “ Base de Datos de Gestión deConfiguración” o “CMDB ” por sus siglas en inglés.

1.3 Detalle de metas esperadas.La implementación de procesos basados en ITIL debería afectar significativamentela forma en la que se administra la tecnología en la organización, con los siguientesimpactos esperados:

Consolidar el conocimiento de la configuración de la infraestructura TI, por endemejorar el diagnostico de fallas, ante caídas del sistema.

Mejorar la estimación del impacto, si es que se efectúa para una modificación a

la configuración. Coordinar de mejor forma los trabajos sobre la infraestructura tecnológica, por

ejemplo, eliminar la duplicación de trabajo.

1.4 Objetivos del Proyecto.A. Objetivos Generales.

Diseñar de procesos de Gestión de Cambios e implementar de una Base de Datosde Gestión de Configuración, usando ITIL, para el Data Center de Telefónica delSur.

B. Objetivos Específicos.Por objetivos específicos se identifican:1. Describir el entorno del problema organizacional en el que se aplica ITIL.2. Formalizar el marco teórico ITIL, definiendo una base teórica a aplicar en las

actividades del proyecto.3. Diseño procedimientos y políticas, para Gestión de Configuración.4. Diseñar Base de Datos de Gestión de Configuración.5. Implementar Base de Datos de Gestión de Configuración y los datos críticos

de operación.6. Implementar procesos y políticas, para Gestión de Configuración.7. Validar métricas éxito con métricas en los servicios y Jefe Data Center &

Hardware.


16/97

7

2.- CAPITULO 2. ANALISIS MEJORES PRÁCTICAS ITIL.

2.1 Visión/Misión general ITIL.

Siendo un marco de buenas prácticas ITIL: Describe los objetivos y metas principales en la administración TI.

Actividades y fases generales.

Entradas/Salidas de múltiples procesos.

No pretende describir las operaciones del día a día.

Los elementos ITIL pueden ser incorporados evolutivamente a las organizaciones,en coexistencia de otras formas de administración anteriores.

La distribución y release oficial de ITIL está a cargo de la ITSMF o IT ServiceManagment Forum, organización internacional sin fines de lucro (libre decompromisos con proveedores) dirigida por sus miembros (Organizaciones,Proveedores y Usuarios).

a. Certificaciones ITIL.-

Sin discusión, la certificación es punto de interés dentro de cualquier especialización

profesional, en ITIL, estas se enumeran por nivel (de menor a mayor) como sigue:

Certificación. Característica.

Foundation Certificate Acredita un conocimiento básico de ITIL en gestión deservicios de tecnologías de la información y lacomprensión de la terminología propia de ITIL. Estádestinado a aquellas personas que deseen conocer las buenas prácticas especificadas en ITIL. El examen para

conseguir este certificado se puede hacer en inglés,francés, español, alemán, portugués, chino, japonés yruso.

Practitioner's Certificate Destinado a quienes tienen responsabilidad en el diseñode procesos de administración de departamentos detecnologías de la información y en la planificación de las


17/97

8

actividades asociadas a los procesos. Este examen sólo se puede hacer en inglés.

Service Manager'sCertificate

Garantiza que quien lo posee dispone de profundosconocimientos en todas las materias relacionadas con la

administración de departamentos de tecnologías de lainformación, y lo habilita para dirigir la implantación desoluciones basadas en ITIL. Este examen se puede haceren inglés, alemán y ruso.

Tabla 1: niveles certificación ITIL

b. Hitos Históricos.A continuación en la tabla se describen los hitos históricos del desarrollo de ITIL.

Año. Hito.Mediados delos años 80’s.

La institución gubernamental “Central Computer andTelecommunication Agency” (CCTA), la que mas tarde serárenombrada como “Office of Goverment Commerce” (OGC), inició eltrabajo de crear ITIL como apoyo en la administración de Servicios TI públicos.

En 1992. Solo estaba disponible la certificación de “IT Service Manager”, la másalta en el escalafón de certificaciones ITIL hasta hoy.

En 1996 y1997.

Se crean las certificaciones “ITIL Foundations” y “ITIL Particioner”,respectivamente, creando los niveles básicos y intermedio en losniveles de certificación ITIL.

Entre 1999 y2006.

Del total de 44 libros, se condensan en 10 tomos, los cuales adoptan elnombre de ITIL versión 1. En consecuencia de lo anterior, el foco de lacertificación se centró en los procesos incluidos tomos: Service Suport(enfoque operacional) y Service Delivery (enfoque táctico).


18/97


19/97

10

Services Support: Libro contiene las recomendaciones dirigidas al aseguramientode la continuidad del Servicio TI y el acceso de los clientes al mismo., los tópicosdiscutidos son:

o Service Desk (Mesa de Ayuda).

o Incident Management (Gestión de Incidentes).o Problem Management (Gestión de Problema).o Change Management (Gestión de Cambios).o Release Management (Gestión de Versiones).

Manage the Infrastructure: Incluye recomendaciones para operacionales sobre lainfraestructura.

Managing Applications: Libro que contiene recomendaciones que están sujetas aciclos de vida de los procesos software y las etapas de pruebas de Servicio TI.

De toda esta bibliografía, los libros más usados (y necesario para todos los nivelesde certificación) son los de “ Service Delivery” y “Service Support” . Y para estatesis, en particular, los tópicos de“Services Support” .


20/97

11

A. Arquitectura de Service Support .

El siguiente diagrama muestra como se relacionan los procesos ITIL.

Figura 2: diagrama relaciones procesos ITIL

Organización, Clientes y Usuarios: Son todos aquellos que utilizan Servicios TIdentro de la Organización, 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 correocorporativo.

o Organización: La propia organización se toma como una usuario/cliente delos Servicios TI, ya que muchas de las estrategias organizacionales se llevana cabo a través de TI, por ejemplo, Telefónica del Sur.

Service Desk: En general es la interfaz con cualquier usuario que utilice ServiciosTI de una organización. Lleva a cabo principalmente estas tareas.


21/97

12

o Sirviendo de punto único de registro y escalamiento de incidentes (enrelación a Gestión de Incidentes).

o Aplicando soluciones conocidas por los ejecutivos de 1º y 2º nivel de Mesade Ayuda, si existe algún error conocido y repetitivo, en alguna regla en base

de dato de conocimiento o KB (no necesariamente en una BD relacional), por ejemplo, actualización diaria del antivirus, que provoca lentitud enintranet. (en relación con Gestión de Problemas).

o Colaborando con la Gestión de Configuración de la CMDB, en particularregistrando eventos dentro del ciclo de vida de un Incidente.

o Gestionando cambios solicitados vía RFC (Request For Change), de acuerdoa procedimientos definidos en Gestión de Cambios y Gestión de Versiones, por ejemplo reportando degradaciones del Servicio TI a los Grupos de

Expertos Técnicos, asociado a un Cambio Implementado recientemente.

Gestión de Incidentes: Tiene por objetivo resolver cualquier incidente que causeuna interrupción en los Servicios TI, de la forma mas rápida y eficaz posible,muchas veces dejando las soluciones definitivas a Gestión de Problemas (el cual seencarga de hacer seguimientos de incidentes y encontrando causas técnicascomprobables).

Gestión de Problemas: Se encarga de investigar causas subyacentes a cualquieralteración real o potencial de Servicio TI. Una vez echo esto ingresará una RFC, ocambio en la configuración de un Servicio TI, el cual debería solucionar el problemay finalmente realizar una revisión post implementación (PIR en ITIL), encomunicación con Gestión de Cambio.

Gestión 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 documentación disponible.o Revisar junto a los usuarios (a través de la Mesa de Ayuda) y los grupos de

expertos técnicos que ejecutaron el cambio, los resultados post-implementación.


22/97

13

Gestión de Versiones: Se encarga de:o Implementar las actividades de los cambios.o Desarrollar planes de “roll-out” (lanzamiento de nuevas versiones) y “back-

out” (recuperación de versiones antiguas).

Gestión de Configuraciones: Sus actividades principales son.o Llevar el registro de los principales elementos de configuración o CI

(Configuration Item) de la infraestructura TI.o Realizar auditorias periódicas de la configuración.o Proporcionar información oportuna y precisa sobre la configuración TI a

todos los diferentes procesos de gestión, en particular a Gestión de Cambios,

como herramienta de evaluación de impacto al Servicio TI, relacionada a unaRFC.

2.3 Gestión de Cambios.

a. Objetivos de la Gestión de Cambio.La meta primordial de laGestión de Cambios es que se realicen e implementenadecuadamente todos los cambios necesarios en la infraestructura y servicios TI,garantizando el seguimiento de procedimientos estándar. Abriendo canales decomunicación entre lo involucrados, para facilitar la toma de acuerdos en conjuntos.


23/97

14

Recomendación ITIL.Sin duda la definición de procedimientos de cambios dentro de una organización provoca puede provocar el escozor de algunas áreas que pudieran ver sometida sustareas a lo definido en un procedimiento; por lo que es altamente recomendable

implementar Gestión de Cambios y Gestión de Configuración simultáneamente,asegurando que el riesgo de evaluar mal el impacto del cambio se minimice. Además sedeben considerar protocolos de actualización de la documentación en la CMDB, segúnel proceso avance.

b. Conceptos Básicos de Gestión de Cambios.

Cambio.-Es todo proyecto o actividad que cambie la configuración de la infraestructura

TI, en particular con los datos almacenados en la Base de Gestión deConfiguración o CMDB.

Change Manager, Gestor de Cambios.-Es el encargado de velar por las actividades propias del proceso de Gestión deCambio, ya sea lanzando notificaciones y como la actualización de la CMDB. Esel rol que pone los antecedentes del flujo a disposición de todos los involucrados(CAB), muchas de sus tareas pueden ser automatizadas, sin embargo siempresurgen excepciones tanto para el proceso como en el caso de urgencias, quedeben ser gestionadas incluso por vías mas expeditas, como teléfono o fax.

Consejo Asesor de Cambios, Change Advisory Board o CAB.-Es un órgano interno, presidido por elGestor de Cambios, formado principalmente por representantes de las principales áreas de la gestión deservicios TI. Sin embargo, en algunos casos también 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 tambiéntodos los campos necesarios para el control del proceso de cambio, en particularse recomiendan los siguientes campos para el registro inicial:


24/97

15

o Fecha de recepción.

o Identificador único de laRFC.

o Descripción del cambio propuesto:

Motivación.

Propósito.

CIs involucrados.

Estimación de recursos necesarios para laimplementación.

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 aceptación (denegación) delRFC.

o Evaluación preliminar de la Gestión del Cambio.

o Prioridad y categoría.

o Planes de "back out".

o Recursos asignados.

o Fecha de implementación.

o Plan de implementación.

o Cronograma.

o Revisión post-implementación.o Evaluación final.

o Fecha de cierre.


25/97

16

FSC, o Programa Adelantado de Cambio.

Es información acerca de los cambios futuros que se implementarán en lainfraestructura, debe publicarse en un medio asequible por cualquier miembro dela organización.

c. Proceso de Gestión de Cambio.

El siguiente diagrama enumera las principales actividades del proceso.

Figura 3: diagrama actividades de Gestión de Cambios.

Estas etapas de detallan a continuación.

d. Actividades de Gestión de Cambio.

1) Registro y Aceptación.El primer paso del proceso es el adecuado registro un RFC, el origen del cambio

puede ser muy variado, se recomienda considerar: Gestión de Problema: Se pretende solucionar un problema a través de un

cambio.

Nuevos Servicios TI: El cambio pretende la configurar la infraestructura con elfin de Implementar un Nuevos Servicio TI.

Estrategia Empresarial.

Imperativo Legal.

Para “Aceptar” una RFC, se debe evaluar preliminar su pertinencia, junto concomprobar que la información que se ingreso es válida y suficiente paraimplementar el cambio completo.


26/97

17

2) Clasificación.Después aceptada la RFC, se procede a clasificar por categorías los RFC, categoríaque indicará una ponderación entre el esfuerzo y la necesidad de implementar elcambio especificado en la RFC, en general se recomienda tener en cuenta estas

categorías 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 nuevohardware, etc.

Normal: Es conveniente realizar el cambio pero siempre que ello no entorpezcaalgún otro cambio de más alta prioridad.

Alta: un cambio que debe realizarse sin demora pues esta asociado a errores

conocidos que deterioran apreciablemente la calidad del servicio. ElCAB debeevaluar este cambio en su próxima reunión y adoptar las medidas pertinentesque permitan una pronta solución.

Urgente: es necesario resolver un problema que esta provocando unainterrupción o deterioro grave del servicio. Un cambio de prioridad urgentedesencadena un proceso denominado cambio de emergencia que trataremos deforma independiente.

Estas categorías son datos que deben verse reflejada en la Gestión de losCambios, es decir debería afectar el encolamiento de las actividades y losllamados a reunión del CAB (o EC, Emergency Change).

3) Aprobación y Planificación.Es en esta actividad es donde el Change Manager tiene una alta participación, es élel encargado de llevar un control de sub-tareas necesarias para el cumplimiento losobjetivos de esta actividad, se pueden resumir en:

Convocar la participación de grupos de expertos técnicos: Los cuales debenaportar con su pericia en las actividades sobre la infraestructura y definir los pasos a seguir sobre la infraestructura.


27/97

18

Convocar las personas que responsables de los Servicios TI: Los que debenasegurar que el cambio no afecte el rendimiento de los Servicios TI paraclientes.

Convocar a cualquier área que pueda verse afectada por el cambio: Por ejemplo,

invitar al Jefe de Finanzas, si el cambio afectará los procedimientoscomputacionales que facturan las cuentas de los clientes.

Por su parte, el Change Manager debe asegurar se realice la “Evaluación deImpacto” asociada al cambio y que además sea registrada en la CMDB.

Finalmente, se deben determinar y aprobar las fechas en las que se va a procedera ejecutar las actividades de cambio y que deberíamos hacer si el cambio resultamal (actividades BACK-OUT).

En general estas actividades deben ser apoyadas por herramientas de gestióncomputacionales, que buscan acercar a los participantes del CAB y agilizar la tareade control del proceso. Además la CMDB debería tener los datos precisos que permitan encontrar la información a las siguientes preguntas: ¿Quiénes son losresponsables de éste Servicio?, ¿Quiénes nos dan soporte de esta tecnología?, 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) Implementación.El foco de interés de Gestión de Cambio, en esta actividad, esta dirigida amonitorear las actividades de cambio.También es necesario comunicar a la organización cualquier información de interés para los clientes y a todos los involucrados en el cambio.

Interactuar con Service Desk: Para escuchar e informar a los clientes de lasactividades de cambio realizadas en la infraestructura (las que sean de su interésy pertinencia). Además escuchar sugerencias, percepciones de funcionalidad, deusabilidad y de accesibilidad de los nuevos sistemas implementados.

Informar a profesionales de la informática y expertos técnicos de los trabajossobre la infraestructura.


28/97

19

5) Evaluación y cierre.

Antes de proceder al cierre del cambio es necesario realizar una evaluación que permita valorar realmente el impacto del mismo en la calidad del servicio y en la productividad de la organización.

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 laGestiónde Cambios.

¿Provocó el cambio problemas o interrupciones del servicio imprevistas?

¿Cuál ha sido la percepción de los usuarios respecto al cambio?

¿Se pusieron en marcha los planes de "back-out" en alguna fase del proceso?¿Por qué?

Si la evaluación final determina que el proceso y los resultados han sidosatisfactorios se procederá al cierre de laRFC.


29/97

20

e. Esquema unificado del proceso de Cambio.

El siguiente diagrama de flujo muestra a modo de ejemplo, un flujo de trabajo dealto nivel, que unifica las actividades mencionadas anteriormente y la interaccióncon la CMDB (registrar eventos y nueva configuración).

Figura 5: ejemplo diagrama de flujo proceso cambio


30/97

21

2.4 Gestión de Configuración.a. Objetivo.Sus principales objetivos se pueden resumir en:

Llevar un registro adecuado de los CI’s y de los eventos que ocurren sobre ella,

a través de la CMDB, los que se resumen en:o Identificación e historial de los CI’s que componen la infraestructura

tecnológica.o Las relaciones que existen entre los distintos CI’s.o Servicios TI que componen algunos CI’s.

Se denomina Gestión de Cambios a los protocolos definidos para actualizar laCMDB.

Proporcionar información a los otros procesos de ITIL.o A Gestión de Incidentes: Para encontrar rápida solución a problemas

conocidos.o A Gestión de Problemas: Navegar por los registros históricos, de los

trabajos en la infraestructura, para determinar causales de dichos problemas.

o A Gestión de Cambios: Para determinar el impacto del cambio sobrealgún componente, y además es en este proceso donde se actualizan lasrelaciones.

Generar auditorias periódicas, que contrasten lo que existe en la CMDB con elambiente de producción.

Es importante considerar que la CMDB no es un registro de inventario o de stock,sino más bien debe representar una imagen global de la infraestructura TI de laorganización que permita tomar decisiones estratégicas, siendo el núcleo deinformación de todos los procesos ITIL.


31/97

22

b. Conceptos Básicos de Gestión de Configuración.

CI, Configuration Item.Atributo que modela un parámetro configurable de la infraestructura tecnológica oque define alguna característica de ella, que por sobre todo aporta valor para la

Gestión de la Calidad de los Servicios TI de la organización. Pueden ser datos demuy distinta naturaleza, desde el tamaño 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 artículos de configuración CI’s junto asus datos, trazabilidad y relaciones. Herramienta tecnológica que debe contener:

CI’s y sus relaciones.

Historial de los procesos ITIL. Documentación importante, como contratos, declaración de SLA’s,

responsabilidades de personas o grupos… etc.

2.5 Planificación de Implementación.La implementación de Gestión de Configuración/CMDB requiere al menos de:

Un responsable: La descentralización puede generar descoordinación y podríaestropear todo los esfuerzos.

Un directivo patrocinante: Que soporte el costo político en contra de laresistencia a la implementación.

Invertir en una herramienta software: El control y actualización de la CMDB deforma manual es impracticable.

Se debe realizar un análisis minucioso de los registros de inventario yaexistentes.

Respecto al Diseño de laCMDB Se debe establecer claramente:o

El objetivo y el alcance de la CMDB.o Nivel de detalle: Entre mas detalle, más riesgo de quedar desactualizado,

menos riesgo de encontrar información útil y viceversa.o Generar un plan de implementación.


32/97

23

2.6 Consideraciones de Diseño.La principal tarea de Gestión de Cambios es mantener la CMDB actualizada, es poreso que es imprescindible que ésta este diseñada bajo objetivos realistas, ya que porun 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 registrode los sistemas críticos. La ponderación 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 quevan a ser incluidos en los registros. Se recomienda:

Registrar los CI’s que forman los Servicios más Críticos.

Dejar fuera los que estén en su etapa final de ciclo de vida (ya están en desuso). Es necesario incluir documentación relacionada a los responsables, los niveles

de criticidad o SLA’s.

Nivel de Detalle o Profundidad.Es necesario cuales son los atributos que describen nuestros CI’s y sus las relaciones(lógicas y físicas) que existen entre ellos.


33/97

24

2.7 Modelo Unificado.En el siguiente diagrama se muestra, a modo de ejemplo, la combinación de lasconsideraciones de diseño para la CMDB (Profundidad, Relaciones y Atributos), sideseamos modelar los equipos desktop que existen dentro de un laboratorio.

Figura 6: que muestra los conceptos de “Alcance” y “Profundidad” unificados en elejemplo.

Según 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 elalcanceabarca hasta el CI (compuesto) “ LAN2”.

Como se puede apreciar los atributos CI pueden variar incluso dentro de componentes

físicas idénticas (desktop), lo que interesa incluir es la información que ayude a laGestión de la Calidad de Servicio TI. Por ejemplo, podría ser que en “LAN” seencuentran las terminales de Facturación y Cajas, que en “LAN2” se encuentranterminales de consultas de saldo para clientes y que en “LAN3” no se encuentran

Servicios TI instalados bajo responsabilidad de la organización.


34/97

25

3.- CAPITULO 3. ANALISIS DE LA PROBLEMÁTICA.

3.1 Análisis del Entorno.Durante los últimos años la empresa local Telefónica del Sur, ha experimentadovarios cambios en su infraestructura y en la tecnología que soporta los niveles

productivos de sus servicios finales, siendo el punto de rezago, la gestión de estoscomponentes tecnológicos.Lo anterior queda puesto en evidencia con la creación a principios del año 2006, deun cargo llamado “Jefe de Data Center y Hardware”, concerniente a laadministración de la tecnología en su uso para las funciones del negocio, desde lasestaciones de trabajo (PC escritorio y/o notebooks) hasta los servidores de“Producción”. Es justo con la inserción de este cargo, cuando nace la inquietud conestablecer una forma más ordenada de trabajar en el área, al implementar procedimiento unificado y público, en vez de efectuar modificaciones a través decontactos internos o una simple llamada telefónica.Los primeros pasos los dio el cargo, al crear un “Sistema de ticket de Incidentes”, demodo de poder tener una herramienta software que registre los problemas que tienenlos usuarios de la organización y a la vez implementar procesos de Gestión deIncidentes, además dicho sistema esta pensado para hacer posible la implementaciónel resto de los procedimientos incluidos en el estándar ITIL

Actores del entorno del Proyecto.Como principales actores que se relacionan con la implementación del proyecto podemos mencionar los siguientes:

Sistema de Ticket: Sistema Informático, donde se registran los problemas y secomentan las soluciones (tal como los foros abiertos de Internet). Este sistemaunifica a todos los actores del ámbito del problema que se mencionan acontinuación.

Usuarios no informáticos : los que solicitan que le instalen algo en su estación oinforman de un error en sus herramientas de trabajo. Generalmente este ingresasus solicitudes a través de Mesa de Ayuda (Help Desk), propio de la mayoría delas empresas TI que operan actualmente.

Mesa de Ayuda: Punto único de contacto para usuarios no informáticos, tiene acargo de la resolución de incidencias con los equipos de los usuarios y los


35/97

26

aplicativos que utilizan. Además se encarga de reportar fallas masivas desistemas 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

tecnológica de la mejor manera posible. Éste rol toma las decisiones de procesosrequieren autorización.

Usuarios Informáticos (Ing. De Sistemas) : Son usuarios de alto conocimientode la infraestructura tecnológica, los cuales solicitan cambios, que deberán serevaluados, por los impactos que producen o informan problemas en loscomponentes tecnológicas que forman el servicio final. Estos tienen accesodirecto al sistema de registro de incidentes actual y atienden problemas que leconciernen a través del mismo.

La figura siguiente muestra como interactúan las distintas áreas o actores.

Figura 7: esquema de relaciones de actores del entorno del problema

Las áreas de superposición representan los puntos o lazos de comunicación másestrechos, es importante notar que los “Ing. de Sistemas”, en la mayoría de susactividades tienen acceso a cambiar la configuración de la infraestructura (resaltadoen la figura por el cuadro rojo), esto es particularmente importante para el proyecto,

Usuarios

de Servicios.

Jefe Data Center & HW.

Mesa de Ayuda.

Ing. de Sistemas(desarrollo y

mantenimiento).

Ing. de Operaciones y

Infraestructura Tecnológica.


36/97

27

porque resalta la falta de implementación de procesos de Gestión de Cambios,originando un foco de riesgo para la estabilidad de los Servicios TI Telsur.

a. Procedimiento definido para Gestión de Incidentes Telsur.

A pesar que éste procedimiento es de carácter confidencial, podemos dar elsiguiente análisis resumido del mismo, desde el documento redactado por el Jefe deData Center & Hardware, Gabriel Morales.

Objetivo: Definir el procedimiento de atención y registro de informaciónasociada a la atención y resolución incidente de Servicios TI o equipamientotecnológico que la Subgerencia de Informática provee a Telefónica del Sur y susfiliales.

Alcance: Cualquier falla de servicio percibida por cualquier usuario de

tecnología, incluyendo la resolución de cada caso. No aplica a cambios, ni afallas reportadas al área de sistemas.

Políticas:o Un incidente es cualquier respuesta no esperada del uso de Servicios TI.o Las acciones de resolución del incidente, están orientadas única y

exclusivamente a la restitución o normalización del Servicio TI.o Los incidentes se reportan formalmente en el Sistema de Tickets.o Todas las actividades de resolución de un incidente se registran como

bitácora de un Ticket.o El área resolutora del incidente debe registrar al menos su diagnóstico,

las acciones tomadas, el responsable que define dichas acciones y unaindicación si la solución 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 PC’s y Notebooks, oderiva a un área especialista según de acuerdo al chequeo básico definido por Telefónica del Sur.

o Operaciones TI: Rol cumplido por ACT Ingeniería, opera en modo24x7, resuelve incidentes derivados por la mesa de ayuda y registra susacciones, diagnóstico y resolución en el Ticket respectivo, uopcionalmente escalar a proveedores de segundo nivel a cargo de la


37/97

28

plataforma afectada por el incidente, generalmente proveedores de productos adquiridos para la plataforma TI del Data Center de Telsur oingenieros de sistemas Telsur.

o Especialistas resolutotes: compuesto de diversos Grupos de Trabajo,

componen el segundo nivel en el escalamiento de incidentes a sistemasTelsur, 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 deatención de incidentes, elaborar planes de soluciones definitivas, velar por la explotación de la infraestructura TI a su cargo y facilitar laresolución de incidentes complejos.

b. Gestión de la Configuración por ACT Ingenería.Existe un relativo seguimiento de la configuración de la infraestructura TI de Telsuren forma de planillas Excel, por parte de ACT, entidad encargada de las operacionessobre la misma, dichas planillas están publicadas en la intranet corporativa y norepresentan un enfoque unificado, tal como se espera de la CMDB, ya que losatributos de configuración están agrupados para utilidad interna de ACT. Estas planillas son de carácter confidencial, pero podemos distinguir los siguientesenfoques.

Planilla de Servidores: incluye el nombre del servidor, ambiente(producción o desarrollo), su IP, ubicación, el sistema operativo, marca,modelo, número de serie, modelo de su CPU, número de CPU’s, número dediscos internos, espacio total en disco, disponible, memoria RAMdisponible.

Planilla de Instancias Oracle: incluye ambiente (producción o desarrollo),servidor donde esta instalada, SGA en GigaBytes, versión de motor Oracle,nombre instancia, nombre listener, IP listener, usuario unix.

Distribución de Servicios: incluye información mas orientada al ServicioTI, como nombre del Servicio TI, criticidad del Servicio TI, Servidor que lasoporta, Responsable Telsur y Software instalado en cuatro niveles.

Como se mencionó al principio, estos datos son de utilidad pero no sonactualizados al ritmo en que los cambios ocurren y obviamente no estánintegrados con los procesos de Telsur.


38/97

29

En resumen, hasta la fecha se ha implementado procesos relacionados con Gestiónde Incidentes, los cuales están orientados a mantener el servicio tecnológicodisponible a usuarios. Se han dejando fuera Gestión de Cambios y la creación de

una CMDB, donde la primera se encarga de evaluar el impacto de un cambio en laconfiguración y coordinar su ejecución, y la segunda esta enfocada a habilitar unregistro de la configuración en una base de datos de gestión de configuración(CMDB en inglés), de donde se obtendrán todos los datos necesarios a todos los procesos de Gestión ITIL. Por su parte ACT, empresa consultora lleva un registro dela configuración en planillas publicadas en la Intranet Corporativa Telsur, siendoéste un método poco efectivo y muchas veces muy lento de actualizar.

3.2 Análisis del sistema computacional de gestión vigente. El sistema computacional de gestión, para las políticas y procedimientos analizadosanteriormente es el “Sistema de Tickets”, en el cual se lleva la gestión de Tickets deIncidentes, Requerimientos y Consultas. Todos los cuales están orientados a laGestión 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 primernivel, o por escalamiento a Grupos de Trabajos especializados en alguna tecnología

o Servicio TI en particular. Entre sus funcionalidades mas importantes están:

a. Ingreso de un Ticket: el sistema permite ingresar un ticket, especificando queusuario lo reporta, a que grupo de trabajo asignado, a que Servicio TI,Componente de Servicio afecta y cual fue la falla, y además permite adjuntararchivos que puedan ser de utilidad para la resolución del caso.


39/97

30

Figura 8: interfaz para nuevo ticket

b. Notificaciones vía correo electrónico: el sistema es capas de enviar un correoelectrónico de notificación para ciertos eventos ocurridos en un Ticket, porejemplo: al ingresar un Ticket le envía un correo al usuario que reporta elincidente, que su caso ya ha sido reportado.

c. Grupos de Trabajo y Usuarios que aprueban: el sistema permite crear deforma paramétrica Grupos de Trabajo y Usuarios que autoricen Tickets deRequerimiento.

d. Bitácora de Ticket: el sistema permite llevar una Bitácora de Eventos ocurridosen la gestión de la resolución del incidente, en forma de glosa de texto.


40/97

31

Figura 9:, bitácora 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 módulo llamado “ConsultaGeneral”.

Figura 10: Interfaz “Consulta General”.


41/97

32

f. Cambios de Estados de un Ticket.El sistema permite modificar el estado de un ticket de acuerdo a un flujo definido(detallado más adelante), esta funcionalidad esta restringida según los integrantes deun Grupo Resolutor al cual está asignado y a distintos niveles de accesos definidos a

los usuarios del sistema. La siguiente fotografía muestra las opciones que posee unticket asignado a un grupo donde está incluido el alumno tesista, se destacan en uncuadro 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 :


42/97

33

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 están implementadas en un módulo llamado “Panel de Control”.


43/97

34

Base de Datos, Sistema de Ticket.Dentro de las tablas del sistema, existen algunas que se acercan al concepto de base dedatos de configuración, en particular es capaz de llevar el catálogo de Servicios TI, las

componentes que participan, y las fallas o actividades que le ocurren a dichoscomponentes. A continuación se muestra una vista parcial del modelo de datosentregado como documentación del sistema.

Figura 14: tablas que guardan configuración de Servicios, Componentes y Fallas, enSistema de Tickets

VentajasLa principal ventaja de esto es que estos datos están integrados con el sistema de ticket,es decir si se modela una base de datos completa considerando estas tablas, ésta quedaráautomáticamente integrada con la lógica de l sistema de ticket.Desventajas.Estas tablas no están pobladas con datos que reflejen la configuración de los ServiciosTI.

Flujo del Sistema de Ticket.El sistema está construido para llevar el control de los Tickets de acuerdo con elsiguiente diagrama de transición de estados.


44/97

35

Figura 15: Diagrama de Transición 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 suestado inicial será“Abierto” , mientras que si se trata de un Ticket de Requerimiento suestado inicial será“Pendiente Aprobación” , responsabilidad que recae en el “Jefe deData Center y HW Telsur”.

Limitaciones del Sistema de Tickets.A pesar de ser un muy buena herramienta de Gestión de Incidentes, lo que cumplesatisfactoriamente, 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 están validadas por código,es decir el DTE. Mostrado anteriormente y muchas restricciones están insertas en elcódigo, por lo que su mantención y modificación están completamente vinculadas alcreador del sistema, es decir no existe algo así como una consola de configuraciónde sistema.

2) Otra limitación, es que utiliza una base de datos Mysql versión 4.2, la que no tieneintegridad referencial por claves foráneas, todas las consultas y las validaciones deintegridad referencial están insertos en el código PHP de las páginas que locomponen.


45/97

36

De todas formas la tecnología usada interés de este proyecto, pero el análisis de lafuncionalidad de los actuales procesos administrativos de la infraestructura TI, pasatambién por estudiar las herramientas de gestión existentes.

Recomendaciones de elección de herramienta software según recomendacionesITILA continuación se tabulan los criterios para definir la herramienta a utilizar en laimplementación de procesos ITIL y el cumplimiento de estos criterios por el Sistema deTickets

Criterio Observación.Cumplir con un 80% de requerimientos

operacionales.

El sistema permite efectuar la mayoría de

las operaciones relacionadas a procesosITIL, ya sea notificar, asignar trabajo,reasignar, tipificar un trabajo, envía correoelectrónico, permite llevar bitácoras de loscasos… etc.

Ser implementable con pocasmodificaciones.

El sistema esta parametrizado paracumplir este requerimiento.

Estructura de datos manejable y acorde anuestra realidad.

Con un nuevo modelo de CMDB, elsistema queda completamente acorde a larealidad de la organización.

Diseñado a enfocado a los procesos, no por la tecnología.

Fue concebido con enfoque a procesosITIL de Incidentes.

Costos de mantención y administracióndentro del presupuesto.

La mantención y administración ya estáasumida por funcionarios de Telsur.

Tabla 3: de cumplimiento de criterios de elección de herramienta y el cumplimiento deestos del sistema de tickets

Por lo que se decidió continuar la implementación de ITIL, en particular con este proyecto de Gestión de Configuración y Gestión de Cambios, utilizando estaherramienta.


46/97

37

4.- CAPITULO 4. DISEÑO DE LA SOLUCION.4.1 Diseño de Proceso de Cambio.A. Visión práctica del Proceso de Cambio.De acuerdo al marco de buenas practicas ITIL, la meta de un proceso de Gestión de

Cambios es: “Asegurar que se usen procedimientos y métodos estandarizados en elmanejo de los cambios, y minimizar el impacto que este pudiese provocar”. Enextensión de lo recomendado por ITIL, en la práctica, un proceso de gestión de cambio,debe satisfaces las siguientes aristas:

Recomendaciónmejores

prácticas ITIL.Descripción

Filtrar.Es decir, no admitir peticiones de cambio o RFC, maldocumentadas o que simplemente no pertenecen a lacategoría de cambio.

Coordinar y

Notificar.

Notificar y convocar en el proceso a todos aquellos que seannecesarios para la ejecución de un cambio e informar aaquellos a quienes pudiera afectar, en particular si se está“Evaluando el Impacto”, que podría requerir la opinión deáreas no técnicas de la organización, por ejemplo: Jefe deFinanzas, Jefe de Ejecutivos Call Center, Jefe de ProyectosComerciales, etc.

EvaluarImpacto.

Se refiere en particular a una etapa obligatoria dentro de un proceso de cambio, en la cual se recogen las opiniones de peritos (técnicos o no técnicos) para evaluar el impacto que pudiera provocar un cambio tanto en los Servicio TI final aclientes, como a la propia infraestructura tecnológica. NOTA: En un ambiente con una CMDB consolidada, éstadebería entregarnos la mayor parte de la respuesta a la pregunta, “¿A quien convocamos a evaluar este cambio?”.


47/97

38

ActualizarCMDB.

El proceso obligatoriamente debe procurar a través del ChangeManager (o algún encargado) mantener la CMDB actualizada,ya que es el punto de información estratégico en los procesosITIL.

Controlar.

El proceso debe controlar la aprobación de un cambio, lasactividades que involucran, que las fechas de ejecución secumplan, que las condiciones de aprobación se cumplan, quelos informes de cierre se entreguen, que los manuales deoperación se entreguen, etc.

Acordar.

El proceso de cambio no debe ser demasiado restrictivo, más

bien debe crear instancias de acuerdo.

Plan deRetirada.

Un cambio no puede ejecutarse sin un plan de retirada (a laconfiguración antigua), el cual se ejecuta si en laimplementación del cambio se producen efectos no esperados,tanto en Servicios TI, como en la infraestructura TI.

ResponsableEjecutivo.

Finalmente el proceso debe tener un responsable ejecutivo, un

“operador” del proceso declarado en la documentación ITILcomo “Change Manager”.Este rol no tomará decisiones, solo se encargará de que el proceso y sus condiciones se cumplan.

Tabla 4: recomendaciones mejores práctica, para el proceso de gestión de cambios

Aparte de consideraciones generales de implementación y diseño, ITIL presenta unmarco estratégico que no acota las herramientas de diseño a utilizar en la especificaciónde los procesos, dejando esto al conocimiento y prácticas de procedimientosorganizacional administrativo, es decir, ITIL entrega la estrategia de diseño no el modode especificar el proceso.


48/97


49/97

40

DTE o Diagrama de Transición de Estados: herramienta bajo el alero del análisisestructurado. Se utilizó para estipular los estados posibles del proceso de cambio yde 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 serestandarizada es muy recurrente su uso).

Tablas de Consolidación:Planillas que especifican todo lo que se dejó fuera en losdiagramas, de forma que su lectura de estos sean más ergonómica.

Este grupo de herramientas es más bien uno propuesto por el alumno, acorde al problema que se requiere solucionar y guiado de información publicada por consultorasque implementan procesos de calidad.

D. Cuerpo de Diseño de Alto Nivel.A continuación se muestra el cuerpo del diseño de alto nivel del proceso de gestión decambio.a. Objetivos.El objetivo principal de este proceso es de formalizar las actividades y condicionesasociadas a un cambio a la configuración de la infraestructura tecnológica 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 decambio, hasta el cierre definitivo de las actividades sobre la configuración de loscomponentes tecnológicos y la evaluación final del proceso completo.b. Alcance.Un cambio se define como una la actividad planificada y ordenada de implementar en producción nuevas configuraciones a la infraestructura tecnológica, y por transitividad,a los Servicios TI Telsur, que además afecte registros de la CMDB.Este procedimiento se aplica a lassolicitudes de cambioregistradas por los profesionales de la informática los encargados de la explotación de la plataformatecnológica de Telsur y del buen funcionamiento de los Servicios TI provisionada por laanterior.El alcance del proceso incluye la coordinación de los distintos eventuales implicados enun cambio a la configuración de la infraestructura tecnológica de Telsur, es decir:

Para los expertos técnicos que ejecutan los cambios a la configuración.


50/97

41

Para los responsables directa o indirectamente de la operatividad decomponentes tecnológicos de la infraestructura tecnológica de Telsur.

A aquellos responsables de la continuidad de algún Servicio TI Telsur.

Además definen en el presente proceso, condiciones y reglas decisionales, para

el flujo completo. No aplica:

A incidentes aplicativos en producción.

A requerimientos de instalación o acceso a sistemas por parte usuarios profesionales de la informática.

A estudio de problemas recurrentes en la infraestructura tecnológica de Telsur.

c. Políticas.

El punto de coordinación será el Sistema de Tickets, donde se deben registrartodas las gestiones asociadas al cambio, ya sea los comentarios técnicos y lasnotificaciones de conformidad.

Una solicitud de cambio ingresada por el solicitante, debe especificarclaramente: Objetivo, Prioridad, Impacto, Origen del Cambio y las actividadesque el cambio requerirá que deben incluir por cada una:

o Componente Afectado.o Detalle técnico de la actividad.o Fecha/hora propuesta para la actividad.o Duración de la actividad.o Plan de vuelta atrás.

Siendo los anteriores, los datos necesarios para implementar el cambio en sutotalidad, la falta de estos requisitos será motivo de rechazo del Ticket deCambio.

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 serán ejecutadas por los Grupos de

Trabajo usando las fechas aprobadas por el consejo asesor de cambio.

Un cambio en la configuración se debe registrar en la base de datos de gestiónde configuración, tarea que realizará el Change Manager hasta que existan


51/97

42

herramientas computacionales, que lo automatice para los ejecutores de lasactividades.

Todo ticket de cambio debe permanecer abierto mientras las actividadesasociadas a este no hayan terminado. Además el cierre de un Ticket de Cambio

debe ir asociado a la evaluación final (éxito, fracaso, éxito con vuelta atrás, etc.). Un cambio es de carácterurgente, cuando su postergación pudiese afectar

severamente el negocio.

Dado un cambio de categoríaurgente, el Change Manager debe efectuargestiones de emergencia de forma telefónica, incidentándolas en el Sistema deTickets y registrando eventos en el Formulario de Cambio (cuando aplique).Siendo las respuestas dadas por teléfono por los notificados, serán consideradascomo 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 áreade las actividades sobre la infraestructura, además de informes de control acercade los cambios (exitosos, fallidos, aprobados, solicitados, etc.).

Los Grupos de Trabajo, deben mantener informado a los solicitantes de cambios,a través del Change Manager, sobretodo cuando una de las actividades decambio se ha terminado.

La falta de agilidad de respuesta a una notificación a un experto responsable deun Servicio TI o responsable de un Componente Técnico, significará su posibleexcusión de las alegaciones del Ticket de Cambio.

Bajo cualquier circunstancia actuará como arbitro Gabriel Morales, Jefe de DataCenter & Hardware.

d. Roles y Responsabilidades del Proceso.

Solicitante de Cambio.o

Debe ingresar todos los antecedentes requeridos en el Formulario deCambio y en el Sistema de Tickets.

Grupo de Trabajo, de expertos técnicos.o Actualmente este rol es ejecutado por

ACT DBA.

ACT Ingeniería.


52/97

43

ACT Operaciones.

Networking (Red Interna).

West –Ingeniería.

Sistemas.

IVR & Prepago. Lotus-NT.

Otro que se pueda definir a futuro.o Son los encargados de entregar la evaluación técnica de alguna actividad

que afecte un componente tecnológico bajo su responsabilidad.o Ejecutar actividades que ya estén calendarizadas y autorizadas.o Finalmente estos grupos deben incidentar cualquier información

relevante en el Ticket de Cambio y haciéndola llegar también al ChangeManager.

Responsable(s) de Servicio(s) TI Telsur.o Actualmente este rol es ejecutado por profesionales de la informática, en

general funcionarios Telsur.

Jefe Data Center & Hardware Telsur.o Encargado de autorizar los cambios, de acuerdo con la información

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 según lo estipulado en

este documento. o Actualizar la Base de Datos de Configuración, según los cambios que se

realicen o al surgimiento de nueva información en el proceso.o Mantener un registro y seguimiento de todos los Tickets de Cambio,

confeccionando estadísticas de control de gestión, acerca de: Cambios solicitados. Nº de cambios según su Solicitantes. Nº de cambios según Grupos de Trabajo.


53/97

44

Nº de cambios según Componentes. Nº cambios fallidos y exitosos.

o También debe mantener informada al Área de Informática, publicandoun “Programa Adelantado de Cambios” en el sitio de intranet TWIKY,

indicando: Nº del Ticket de Cambio. Grupo de Trabajo. Fecha Inicio de Trabajos. Descripción. 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, según

el “Programa Adelantado de Cambios” o directamente con el ChangeManager.

o Comunicar al Change Manager si existen percepciones negativas de losusuarios derivadas del cambio.

e. Flujo Proceso de Cambio.El proceso de cambio se resume en las siguientes etapas generales.

1. Aceptación:se verifican que el cambio tenga los datos y las actividadesnecesarias para ser implementado, sino se ofrece apoyo de gestión para hacerlo.

2. Evaluación de Impacto:se convocan a entregar su opinión técnica acerca delcambio, tanto a Grupos de Trabajo, como a Responsables de Servicios TI Telsur.

3. Planificación:se acuerdan las fechas de las actividades que implementan elcambio.

4. Implementación:se monitorean los avances y los errores que puedan existir enella.

5. Evaluación de Cierre:se cierra el cambio y se evalúa si el objetivo del cambiose ha cumplido.

A continuación se muestra el flujo de las macro actividades a seguir y las principalesdecisiones a tomar en el mismo.


54/97

Diagrama Flujo Proceso de Cambio.

Figura 16: Diagrama Flujo de “Gestión de Cambios” de alto nivel.


55/97

46

E. Artefactos de Diseño Detallado.A continuación se despliegan o describen los objetos de diseño del proceso decambio.a) Diagrama Flujo Funciones Cruzadas.

Con la elaboración de este diagrama se determinan las actividades, las decisiones, losdatos de entrada/salida más importantes y los involucrados en el flujo de trabajo, acontinuación se muestra en forma separada el diagrama dividido en las distintas fasesdel proceso.

Fase de Aceptación.

Figura 17: Diagrama de Flujo Funciones Cruzadas “Fase Aceptación”.

En objetivo general de esta fase, es el de obtener los datos suficientes de entrada alresto del proceso, que permitan efectuar todo el análisis de impacto, de aprobación y planificación.


56/97

47

Fase Evaluación.

Figura 18: Diagrama de Flujo Funciones Cruzadas “Fase Evaluación”

En esta fase se evalúa el impacto del cambio, es decir se reúnen las opinionestécnicas de todos los involucrados, de modo de tener información de calidad para lassiguientes fases de aprobación y planificación.


57/97

48

Fase Aprobación y Planificación.

Figura 19: Diagrama de Flujo Funciones Cruzadas “Fase Aprobación y Evaluación”

En esta s fases se audita la aprobación del cambio, sus condiciones de aprobación (siaplica) y planificación de las actividades.


58/97

49

Fases de Implementación y Cierre.

Figura 20: Diagrama de Flujo Funciones Cruzadas “Fase Aprobación y Evaluación”

Finalmente en estas etapas se realiza un control de la implementación de lasactividades del cambio y la calificación del cierre del ticket de acuerdo a los parámetros definidos en el proceso.


59/97

b) Diagrama transición de estados.A continuación se muestra el diagrama de transición de estados posibles para un cambio, estados quecualquier cambio, ayudando al entendimiento y comunicación de los involucrados.

Figura 21: Diagrama de Transición de Estados de un Cambio


60/97

51

Formularios de Datos.Se utilizaron formularios para definir el formato y los valores posibles de lasentradas/salidas del proceso, estos están separados por secciones etiquetadas porletras.Estructura de especificación del formulario

Etiqueta de sección que identifica el formulario.

Vista de los campos.

Tabla de descripción:que incluye las columnas siguientes o Nombre del Campo:el cual coincide con el nombre presente en

la vista del formulario. o Descripción:Especifica la descripción o propósito del campo. o Valores: Describe los valores posibles del campo.

Ejemplo.Como ejemplo continuación se muestra el formulario en la “Sección A:Información General”, el cual se utiliza para ingresar la información general delcambio.

Figura 22: Formulario de Cambio, Sección A: Información General


61/97

5

La especificación completa es propiedad de la Telsur y por lo que no fue adjuntadaen este documento.G. Tablas de Consolidación.

Permitió tabular descripciones que se dejaron fuera en los diagramas anteriores,de modo de facilitar su lectura, en particular se utilizó para estipular lasrelaciones que existen entre:1) Entradas/salidas formateadas según 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 decisión del cambio.

Estructura de las Tablas de Correlación Nº 1: de Actividad, Entrada/Salida porSección de Formulario, Rol Ejecutante y la Descripción de Actividades.

Se describe la estructura del contenido de esta tabla en el siguiente diagramaWarnier-Orr.

INPUT

OUTPUT Nombre Actividad Rol Ejecutante

Descripción Etapa del proceso

INPUT

Nombre Actividad Decicional Rol Ejecutante

Descripción

Figura 23: Diagrama Warnier-Orr de estructura de información en Tabla Correlación Nº 1.


62/97

Tabla 5: correlación para fase de aceptación del proceso de cambio.

Etapa delProceso

Aceptación

Nombre de Actividad INPUT OUTPUT Rol Ejecutante DES

Registro RFC A.B.C A,D,E Solicitante deCambio El solicitante debe registrar todos los datos

Recibir RFC A,D,E Change ManagerEl Change Manager debe dar una mirada ini por el solicitante y cambia el estado del camRegistrar Antecedentes deRechazo A,D,E M Change Manager El Change Manager registra los motivos p

Registrar Motivos yAntecedentes L N Change Manager

El Change Manager debe dar una mirada finantecedente final.

Reunir Información Faltante AE P Solicitante deCambio El solicitante retorna la información solicita

Registrar Motivos de Pendiente O Solicitante deCambio El solicitante debe registrar claramente el m

Registrar Motivos deCancelación L

Solicitante deCambio El solicitante debe registrar claramente el m

Notificar a solicitante por masAntecedentes A,D,E AG Change Manager

El Change Manager comunica al solicitante aceptar su cambio.

Nombre Actividad Decisional INPUT OUTPUT Rol Ejecutante CONDICIÓN

Es un Cambio? A,D,E Change Manager Cualquier RFC que provoque una modif

Dejar Pendiente? A,D,E Solicitante deCambio El solicitante puede dejar pendiente su camb

Retomar Cambio? A,D,E Solicitante deCambio El solicitante decide cuando retomar el camb

Cancelar Cambio? A,D,E Solicitante deCambio El solicitante puede cancelar su cambio.

Antecedentes Suficientes? A,D,E Change Manager La suma de los antecedentes ingresados


63/97

5

Estructura Tabla de Correlación Nº 2:Correlación entre actividad de cambio yestado del cambio, rol ejecutante.

Se describe la estructura del contenido de esta tabla en el siguiente diagramaWarnier-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 información de Tabla deCorrelación Nº 2.

Donde los estados son los aquellos definidos en el Diagrama de Transición deEstados, a su vez los roles son los definidos en el Diagrama de Flujo de FuncionesCruzadas. A modo de ejemplo se muestra un fragmento de la tabla, construido parala fase de aceptación del proceso de cambio.


64/97

Tabla 6: correlación para fase de aceptación del proceso de cambio

Etapa del Proceso Nombre de Actividad Rol Ejecutante Estado Inicial

Aceptación

Registro RFC Solicitante de Cambio

Registrar Antecedentes de Rechazo Change Manager

Registrar Motivos y Antecedentes Change Manager

Reunir Información Faltante Solicitante de Cambio Requiere más Inform

Registrar Motivos de Pendiente Solicitante de Cambio

Registrar Motivos de Cancelación Solicitante de Cambio Cancelado por Usua

Recibir RFC Change Manager Registrado

Notificar a solicitante por mas Antecedentes Change Manager

Nombre Actividad Decisional Rol Ejecutante Estado Inicial

Es un Cambio? Change Manager Recibido

Dejar Pendiente? Solicitante de Cambio Si: Requiere más info

Retomar Cambio? Solicitante de Cambio Si: Pendiente por Usu

Cancelar Cambio? Solicitante de Cambio Si: Requiere más info

Antecedentes Suficientes? Change Manager Si: Recibido , No: Re


65/97

5

H. Inconvenientes Esperados.Dentro de los inconvenientes o puntos a tener en consideración están:

Se deben asumir los costos de asumir y planificar los costos de implementar procesos de Gestión de Cambios: en particular de personas (que participan en el proceso) y de construcción de software de apoyo de gestión del proceso.

El proceso debe haber sido construido a medida de la organización, un procesomuy burocráticos pueden producir cuellos de botella, procesos muy simples pueden producir falta de control y por ende pérdida de los beneficios esperados.

Los usuarios deben aceptar la nueva cultura de trabajo, y en particular para el proceso de cambio, ya que esté debería ser el acceso único a cambiar la

configuración de la infraestructura. Lo anterior se debería resolver con elauspicio de un patrocinante que pueda asumir los costos políticos y con lacapacitación de las áreas que estarán involucradas en el proceso.


66/97

4.2 Diseño de la CMDBA. Análisis y definición de datos de interés para la CMDB.Tal como se ha expuesto en el CAPITULO 2, la base de datos de configuración oCMDB (por sus siglas en inglés) se encuentra en el núcleo de las buenas practicasITIL, ya que provee de información a todos los procesos ITIL sobre de la

configuración de la infraestructura TI y los eventos ocurridos en ella.De acuerdo a las mejores prácticas ITIL, para diseñar una base de datos deconfiguración se deben definir el nivel de “profundidad” y el “alcance”. Para el caso particular de la problemática, es indispensable contar con un modelo que permita un buen alcance en torno a los Servicios TI y flexibilidad de nivel de profundidad deatributos de configuración, según los datos que ingresen al modelo. Se determinoque el modelo debía manejar en un principio los datos más generales, como ¿en queServicios TI participa el “Servidor X”?, para luego continuar con datos mas

específicos de configuración como “Cual es la versión del sistema operativo delServidor X?”.De acuerdo al análisis del entorno, los procedimientos estipulados para Gestión deIncidentes y el análisis del sistema computacional de gestión (CAPITULO III), lossiguientes conceptos o CI deberían estar incluidos en la CMDB.

1) Servicios TI: Concepto que representa una funcionalidad o facilidad tecnológicaentregada a un cliente, en ITIL este concepto se identifica como “Catálogo de

Servicios TI”.2) Componentes: que en conjunto conforman un Servicio TI. Estos pueden ser de

carácter tecnológico o una virtualización creada para nombrar alguna capacidadde un Servicio TI.

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

4) Categorías de Servicios TI y de Componentes: clasifica o agrupa de formaexcluyente a Componentes y a Servicios TI.

5) Atributos: representan atributos computables para un objeto Servicio TI oComponente según a la categoría que pertenezca. La definición de este concepto


67/97

6) Personas y Grupos Responsables:este ítem incluye

Grupo de Trabajo y sus integrantes: que son aquellos que operancomponentes tecnológicos y son responsables por los mismos.

Responsable de Servicio y sus integrantes: son aquellos que son responsablesde la continuidad de Servicios TI.

Soporte a Componente: son aquellas instituciones que dan soporte de 2º o defabricante de algún componente tecnológico.

7) Historial: en general de la configuración de la infraestructura que aprovisionalos 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 histórico de laconfiguración.

8) Ventanas Tiempo: tanto de “Disponibilidad de Servicio TI”, como “Ventanas deMantención” de algún componente, este concepto es importante para Gestión deCambios, ya que provee información para la planificación de los cambios.

9) Fallas o Actividades de Componentes:especifica que actividades se puedenefectuar sobre un Componente y cuales son las fallas que se pueden presentar enel mismo. Esto resuelve una grave error de normalización 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 ticketque 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 relacionesque representan relaciones de infraestructura o sea “Cadenas de Infraestructura”.Este fue uno de los conceptos más complicado de definir, ya que un componenteademás participar en mas de un servicio, por ejemplo una base de datos Y y el

servidor Z, participan en el servicio X, también es necesario describir como estainstalada dichos componentes en torno a otros componentes, por ejemplo la base


68/97

B. Artefactos de Diseño CMDB.a. Modelo Conceptual.Una vez determinados los conceptos claves del diseño de la CMDB, se construyó el diagrama entid

Figura 25: Modelo Entidad Relación.


69/97

b. Modelo de Datos.De acuerdo al modelo conceptual de entidad-relación se elaboró un modelo de datos, para su implem

Figura 26: Modelo de Datos CMDB.


70/97

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 lostriggers.

Nombre Tabla

Descripción

Nombre

Dominio

SI

PK

NO

SI Tabla

Campos FK

NO

SI

Not Null

NO

Default

Descripción

Observación

Figura 27: Diagrama Warnier-Orr, estructura de diccionario de datos para tablas

Nombre Trigger

Descripción

Before

Tipo

After Trigger

Insert

Evento Update

Delete

Acción

Figura 28: Diagrama Warnier-Orr, estructura de diccionario de datos para triggers


71/97

A continuación se muestran fragmentos del diccionario de datos, de modo de ejemplificar lo señaladde datos es propiedad de Telsur por lo que no se adjunto en este documento.

Tabla ATRIBUTOS_SERVICIOS Descripción Contiene los valores de los aCampos Nombre Dominio PK FK NOT NULL Default Descripcióncodigo_atributo INTEGER SI SI SI Foránea a tipos_atributos_servicios, idencodigo_categoría servicio INTEGER SI SI SI Foránea a categoría_servicio,

gestion_cambios

Documents