METODOLOGÍA DE GESTIÓN DE CAMBIOS PARA LA OFICINA DE TELEMÁTICA DE LA POLICÍA NACIONAL

Transcripción

1 METODOLOGÍA DE GESTIÓN DE CAMBIOS PARA LA OFICINA DE TELEMÁTICA DE LA POLICÍA NACIONAL DEISY LORENA CEBALLOS ZAPATA Código: UNIVERSIDAD MILITAR NUEVA GRANADA FACULTAD DE INGENIERÍA PROGRAMA DE INGENIERÍA EN TELECOMUNICACIONES BOGOTÁ, ABRIL DE 2010

2 METODOLOGÍA DE GESTIÓN DE CAMBIOS PARA LA OFICINA DE TELEMÁTICA DE LA POLICÍA NACIONAL DEISY LORENA CEBALLOS ZAPATA Código: Libro final de Pasantía presentado como requisito para optar por el título de Ingeniero en Telecomunicaciones Director Interno Ing. CARLOS OMAR RAMOS LINARES M.Sc. Director Externo TC. JAIRO GORDILLO ROJAS UNIVERSIDAD MILITAR NUEVA GRANADA FACULTAD DE INGENIERÍA PROGRAMA DE INGENIERÍA EN TELECOMUNICACIONES BOGOTÁ, ABRIL DE

3 Ingeniero Carlos Omar Ramos Linares, M.Sc. DIRECTOR INTERNO T.C Jairo Gordillo Rojas DIRECTOR EXTERNO Ingeniero Edward Paul Guillen Pinto, M.Sc JURADO Ingeniero Luis Fernando González de la Calle, M.Sc. JURADO 24 de Marzo de 2010 CIUDAD Y FECHA 3

4 Dedico este proyecto y toda mi carrera universitaria A Dios por ser mi guía espiritual, A mis padres por su apoyo incondicional y amor, A mis hermanas por su confianza y fortaleza, A mi familia y amigos por estar conmigo en todo momento. 4

5 AGRADECIMIENTOS A mis padres por ensenarme a luchar por mis sueños a pesar de las adversidades conquistando las metas que me proponga hasta agotar los recursos que sean necesarios, a estar conmigo cuando he caído y motivarme a seguir adelante, por brindarme su confianza y sus consejos que sirvieron de ayuda para comprender y entender mejor las cosas. A mi madre Ildalie Zapata Vásquez por todo su esfuerzo, por enseñarme que la dedicación nos permite alcanzar nuestras metas, por su amor incondicional para contribuir con mi desarrollo profesional y por hacer de mí una buena persona. A mi padre Luis Alfredo Ceballos González por su esfuerzo diario y tantas horas de trabajo para brindarme una buena educación, por enseñarme valores como el respeto, la honestidad, la dedicación y por su confianza en mí. A mi Abuela Licenia González por ser incondicional conmigo y por el cariño que me ha brindado a lo largo de mi vida sirviéndome de guía para luchar por mis metas. A mis hermanas Luz Adriana y Viviana Ceballos Zapata que siempre me han escuchado, apoyado y acompañado en cada una de las etapas de mi vida. A todos mis amigos por brindarme tantos momentos de alegría, diversión y por su incondicional apoyo, que hicieron los tiempos difíciles más amenos. A todos y cada uno de los ingenieros de facultad que me compartieron sus conocimientos ayuda durante el desarrollo de mi proyecto y mi formación profesional. A todas y cada una de las personas que de una u otra manera contribuyeron a la realización del proyecto. 5

6 TABLA DE CONTENIDO 1. INTRODUCCIÓN TITULO PLANTEAMIENTO DEL PROBLEMA ANTECEDENTES Locales Antecedentes nacionales Internacionales OBJETIVOS Objetivo general Objetivos específicos RESEÑA HISTÓRICA MARCO TEÓRICO BIBLIOTECA DE INFRAESTRUCTURAS DE TECNOLOGÍAS DE LA INFORMACIÓN (ITIL) TECNOLOGÍAS DE LA INFORMACIÓN (TI) BASE DE DATOS DE ADMINISTRACIÓN DE LA CONFIGURACIÓN (CMDB) Gestión de Cambios INGENIERÍA DEL PROYECTO ESTADO DEL ARTE Obtención de Calidad Estructuración de Cambios REQUERIMIENTOS DE LA EMPRESA ESTUDIO DE LAS VARIABLES DE INGENIERÍA Cantidad de RFCs aceptados Tiempo de solución de un cambio de Emergencia DESARROLLO DEL PROYECTO

7 Documentación y registro de los cambios realizados en la OFITE Clasificación y parametrización de las solicitudes de cambio Estructuración del organigrama de las actividades en la Gestión de cambios Documentación de la Metodología adecuada para el proceso en la Gestión de Cambios Socialización y entrega de documentación de los procesos realizados PRUEBAS Y RESULTADOS PRUEBAS Ejemplos de Aplicación de la Metodología a casos reales en la OFITE Encuesta Inicial del Nivel de Conocimiento del Personal de la OFITE con la Gestión de Cambios Sensibilizaciones RESULTADOS Ejemplos de Aplicación de la Metodología a casos reales en la OFITE Encuesta Inicial del Nivel de Conocimiento del Personal de la OFITE con la Gestión de Cambios Encuesta Final del Nivel de Conocimiento del Personal de la OFITE con la Gestión de Cambios Estructuración del Consejo Asesor de Cambios CONCLUSIONES Y RECOMENDACIONES CONCLUSIONES RECOMENDACIONES BIBLIOGRAFIA

8 LISTA DE FIGURAS Figura 1 Estructura Orgánica Policía Nacional Figura 2 Estructura Orgánica Oficina de Telemática Figura 3 Núcleo ITIL versión Figura 4 Metodología por fases Figura 5 Matriz de Impacto- Urgencia propuesta en la oficina Figura 6 Clasificación de Problemas y soluciones Figura 7 Metodología de la solución registro y escala de problemas Mesa de Ayuda Figura 8 Base de Datos de Cambios Aprobados Figura 9 Estructura Orgánica de la OFITE Figura 10 Metodología Gestión de Cambios OFITE Figura 11 Motivos de generación de una RFC Figura 12 Personal encargado de la Recepción de RFCs Figura 13 Métodos de Recepción de RFCS Figura 14 Conocimiento del Consejo Asesor de Cambios Figura 15 Conocimiento del Formato de Solicitudes de Cambio Figura 16 Tabulación Respuestas Tiempo de Solución de los Cambios de Emergencia Figura 17 Tiempo de Solución de una RFC de Emergencia Figura 18 Motivos de generación de una RFC Figura 19 Personal encargado de la Recepción de RFCs Figura 20 Métodos de Recepción de RFCS Figura 21 Conocimiento del Consejo Asesor de Cambios Figura 22 Conocimiento del Formato de Solicitudes de Cambio Figura 23 Tabulación Respuestas Tiempo de Solución de los Cambios de Emergencia Figura 24 Tiempo de Solución de una RFC de Emergencia

9 LISTA DE TABLAS Tabla 1 Especificación de Niveles de evaluación Tabla 2 Actividades de Gestión de Cambios evaluadas Tabla 3 Categorización del Impacto de los Servicios propuesta por los administradores de red Tabla 4 Especificación de Niveles de Impacto, derivada de la tabla de categorización Tabla 5 Clasificación Jerárquica Tabla 6 Clasificación de Procesos Tabla 7 Especificación de Niveles de Urgencia Tabla 8 Matriz de Impacto contra Urgencia Tabla 9 Especificación de Prioridades Tabla 10 Matriz de Riesgo Tabla 11 Zonas de Riesgo Tabla 12 Aplicación de la Metodología a Casos reales Tabla 13 Personal Encuestado Tabla 14 Tabulación respuestas motivos de las RFCs Tabla 15 Tabulación Respuestas Personal encargado del registro de RFCs Tabla 16 Tabulación respuestas método de recepción de RFCs Tabla 17 Tabulación respuestas Conocimiento del Consejo Asesor de Cambios. 74 Tabla 18 Tabulación respuestas Formato de Solicitudes de Cambio Tabla 19 Personal Encuestado Tabla 20 Tabulación respuestas motivos de las RFCs Tabla 21 Tabulación Respuestas Personal encargado del registro de RFCs Tabla 22 Tabulación respuestas método de recepción de RFCs Tabla 23 Tabulación respuestas Conocimiento del Consejo Asesor de Cambios. 81 Tabla 24 Tabulación respuestas Formato de Solicitudes de Cambio

10 1. INTRODUCCIÓN Cada día que pasa la tecnología avanza rápidamente y con ello la facilidad de realizar diferentes tareas que hace algunos años se creían imposibles de desarrollar; es por ello que hoy en día las organizaciones ó empresas dependen cada vez mas de la tecnología para lograr cumplir con los procesos misionales de su creación, por ello es de vital importancia desarrollar metodologías de calidad en cada uno de los procesos de las empresas entablando así una estrecha relación entre la misión empresarial y la infraestructura tecnológica. La oficina de telemática de la Dirección General es la encargada de prestar el soporte de servicio a toda la red de la Policía Nacional, involucrando procesos como lo son la gestión de red, gestión de software, gestión de equipos y terminales y esta labor es de vital importancia para la organización, ya que en la tecnología se fundamenta parte de su labor diaria y parte de la misión de la institución. El desarrollo de este proyecto consiste en diseñar una Metodología de Gestión de Cambios para la Oficina de Telemática de la Dirección General de la Policía Nacional, la cual cuente con un proceso estándar para cada uno de los cambios que se presenten sobre la infraestructura tecnológica fundamentándonos en las librerías de Infraestructura Tecnológica (ITIL) que permiten desarrollar un proceso de gestión de Cambios compatible con los demás procesos que se llevan a cabo en la organización, logrando así contribuir a generar planes y mecanismos que beneficien con el cumplimiento de los procesos misionales de la Oficina de Telemática. El desarrollo de este proyecto es de gran importancia ya que se consiste en la elaboración e implementación de una metodología estándar para las solicitudes de cambio que contribuye con una correcta estructuración de los cambios realizados a la infraestructura tecnológica desde el momento de su registro hasta su posterior cierre. 10

11 El libro está constituido por cinco capítulos. El primer capítulo contiene las bases y soportes sobre las cuales se va a desarrollar el proyecto y a evaluar el progreso de este; entre esas están los objetivos, planteamiento del problema, antecedentes y la reseña histórica de la institución en la que fue llevado a cabo el proyecto. El segundo capítulo contiene el marco teórico que son los conceptos fundamentales para observar y ubicarse con mayor facilidad dentro del área de conocimiento escogida en este trabajo. En el tercer capítulo se hace una descripción del estado actual de la institución respecto al proyecto, midiendo y dando a conocer de las variables ingenieriles que intervienen en el desarrollo del proyecto y el cumplimiento de los objetivos mediante fases. En el cuarto capítulo se muestran los resultados de cada una de las pruebas y procedimientos que se realizaron con el fin de implementar una Metodología estándar de Gestión de Cambios en la institución. El quinto y último capítulo se presentan las conclusiones y recomendaciones finales del proyecto TITULO En la Policía Nacional, específicamente en la Oficina de Telemática, la red de datos trabaja diariamente con TI 1 por ello es necesario un buen desempeño y uso de estas para lograr una alta calidad de servicio, máxima disponibilidad y mínimo impacto en los cambios y actualizaciones realizados. Para lograr esto se propuso realizar un proyecto cuyo título es METODOLOGÍA DE GESTIÓN DE CAMBIOS PARA LA OFICINA DE TELEMÁTICA DE LA POLICÍA NACIONAL 1.2. PLANTEAMIENTO DEL PROBLEMA En la Oficina de Telemática de la Policía Nacional, se cuenta con una red de datos en la cual la realización de cambios y actualizaciones no tienen una correcta estructuración de la información y por ende la clasificación, aceptación 1 TI: Tecnologías de la Información 11

12 y planificación dependen del nivel de conocimiento o experiencia de los miembros a su cargo. Esta necesidad analizada desde el punto de la Ingeniería en Telecomunicaciones y basándose en el modelo ITIL 2 plantea cuestionamientos tales como: el método de registro y clasificación de las solicitudes de cambio, el modelo de planeación para la implementación de cambios y la evaluación del impacto producida por las nuevas implementaciones ANTECEDENTES En esta sección se relacionan los diferentes trabajos desarrollados en esta área, a nivel local, nacional e internacional; con el fin de proporcionar una visión global de la importancia del modelo no solo en la institución sino en todas las organizaciones que dependan de las tecnologías de la información: Locales En el año 2008 el ingeniero Juan Camilo Méndez Sánchez propuso el desarrollo de ITIL en la Dirección General de la Policía Nacional en el área de telemática abriendo las puertas para que las TI puedan ser trabajadas en sus amplios campos brindando beneficios a la institución, haciendo así que la Oficina de Telemática de la Policía Nacional adopte el manual de buenas prácticas para optimizar tiempos de respuesta, reducir problemas e incidentes en la red y mejorar día a día la calidad del servicio. [ ] En el año 2009 el practicante de Ingeniería de Telecomunicaciones Laureano Andrey Amado Tapias propuso la Estructuración de la base de datos de conocimientos para la mesa de ayuda del grupo de gestión de la Oficina de Telemática de la Dirección General De La Policía Nacional enfocado a incidentes problemas y CMDB 3, promoviendo así un correcto 2 ITIL: Biblioteca de Infraestructura de Tecnologías de Información 3 CMDB: Base de Datos de Administración de la Configuración 12

13 uso de la gestión de incidentes y problemas propuestos por el ITIL para la red de la Policía Nacional. [ ] Antecedentes nacionales En su documento Adriana Ramírez y Gartner de una empresa consultora de Colombia (SGI - Fox It) junio 28 del 2007 definen: Para implementar ITIL dentro de una organización se debe observar los beneficios que este modelo brinda como por ejemplo, que conduce a una reducción del 6 al 8 por ciento en las operaciones. Además incrementa del 60 al 90 por ciento el cumplimiento de objetivos y reduce el 40 por ciento de los costos internos de soporte. Aunque en Colombia ninguna empresa tiene implementado estos procesos de calidad (ISO 20000), la empresa de consultoría SGI - Fox It a comenzando a impartir capacitaciones y a realizar consultorías con el fin de que numerosas empresas empiecen a integrar este modelo las principales empresas interesadas hasta este momento son Avianca, Bancafé y la Universidad Javeriana. [ ] Vernon Lloyd autor de varios de los libros sobre cómo mejorar la administración de servicios de tecnologías de la información (ITIL) concluye: Colombia es un país donde el desarrollo de estas prácticas está comenzando y tiene mucho potencial por explotar. Por esta razón estuvo en el país lanzando la tercera versión de ITIL. El experto dijo que todas las industrias del país pueden mejorar sus ventas, ahorrar costos y tiempo si mejoran la administración de los servicios de tecnologías de información además de esto dice que el 40% de los problemas ocurren en lo relacionado a procesos, el 40% con la gente y el 20% de los incidentes están relacionados con la tecnología propiamente dicha. Sin embargo la inversión mayor se hace en la actualización de la tecnología en un 80% y el 20% en la actualización de la gente. Ahí se ve una desproporción entre los 13

14 incidentes ocasionados por la tecnología y la gente, la mayor parte del gasto está en la primera que en realidad es la responsable de un 20% de los incidentes. Esto quiere decir que hay que hacer un cambio cultural del ITIL de uno de tecnología a uno en que hay que hacer una mejor gestión. [ ] En 2006 Dexon Software Inc. Compañía Norteamericana, establecida en el estado de Delaware USA, específicamente en el departamento comercial del Dexon seccional Colombia y a cargo del Ing. Luis B. Chicaiza, Director de Ingeniería de Software decidieron implementar un software que tuviera aplicaciones basadas en ITIL dado que en Colombia es un requerimiento para brindar soluciones de este tipo a las empresas y así alinear las soluciones de software, para cumplir con los requisitos que pide Pink Elephant para certificarse en ITIL. Según afirmo Jaime Torres, Gerente de Marketing de Dexon: El área involucrada en la implementación de ITIL, fue la de ingeniería de desarrollo de software, quien acondicionó el paquete que consiste en una serie de libros que ofrecen una orientación en la provisión de servicios de TI de calidad. ITIL está basado en un conjunto de experiencias de profesionales tanto del sector público como privado, alrededor del mundo. Esto da como resultado, un enfoque coherente y confiable, que es utilizado como el estándar de Administración de Servicios por varias empresas líderes en el mundo. [ ] Internacionales Para el caso Telefónica de España se ha ido incorporando el modelo de acuerdo a las funcione que en él se desempeñen por áreas especificas además de esto se están desarrollando un conjunto de iniciativas de mejora relacionadas con el modelo de referencia ITIL y partiendo con una visión especifica hacia los procesos y servicios todo esto con el fin de obtener 14

15 una mayor calidad en sus productos y servicios, así como la reducción de los defectos y la mejora de la capacidad de predicción de los resultados para poder finalmente ofrecer soluciones oportunas y confiables, enfocadas a satisfacer las necesidades y expectativas de los clientes finales. [ ] 1.4. OBJETIVOS Las metas propuestas para este proyecto están dividas en una general y cinco específicos Objetivo general Diseñar la metodología de gestión de cambios para la Oficina de Telemática de la Policía Nacional Objetivos específicos Para lograr alcanzar el objetivo general se han propuesto alcanzar los siguientes específicos: Documentarse sobre los problemas, solicitudes de cambio y actualizaciones que posee la base de datos de la OFITE 4. Clasificar y parametrizar las solicitudes de cambio encontradas en la base de datos de la OFITE. Estructurar el organigrama de las autoridades en la gestión de cambios. Elaborar y proponer soluciones para garantizar la utilización de procedimientos y métodos estándar para el manejo de los cambios en la red de la OFITE. 4 OFITE: Oficina de Telemática 15

16 Documentar los procesos realizados para la sensibilización al personal de la OFITE RESEÑA HISTÓRICA Mediante el decreto 1000 del 5 de noviembre de 1891 se organizó el cuerpo de la Policía nacional el cual dependía del Ministerio de Gobierno y sus empleados serían de libre nombramiento y remoción. Inicialmente este cuerpo estaría conformado por 300 Policías divididos en tres compañías; cada compañía comandada por un capitán, dos tenientes y un subteniente y todo el cuerpo a orden de un primer y segundo comandante respectivamente. Entre el 23 de enero de 1985 y el 21 de enero de 1896, la Policía Nacional se adscribió al Ministerio de Guerra debido al intento de una guerra civil durante el gobierno de Miguel Antonio Caro. Entre de 1898 y 1904 se dispuso que la Policía Nacional dependiera nuevamente única y exclusivamente del Ministerio del Gobierno y que para el efecto el servicio de vigilancia en la ciudad de Bogotá estaría dividida en siete distritos de Policía. En el año 1900 se adscribió de nuevo la Policía Nacional al Ministerio de Guerra donde permaneció hasta el 6 de septiembre de 1901, mediante el Decreto 1380 del 16 de septiembre de 1902 se creó como parte integrante de la Policía Nacional el Cuerpo de Guardias de Honor del Palacio Presidencial con el nombre Guardia Civil de la ciudad de Bogotá. El cuerpo de Policía Nacional se distribuye en tres grupos: el primero destinado a la vigilancia y seguridad; el segundo a una guardia civil de gendarmería y el tercero a la Policía Judicial. 16

17 El 7 de julio de 1937 es creada la Escuela General Santander mediante el Decreto 1277 la cual comienza a funcionar como instituto de formación general para todos los policías. En 1959 la nación asume el pago de la totalidad del cuerpo de Policía Nacional mediante la ley 193 del 30 de diciembre del mismo año, con lo cual se cierra el proceso de su nacionalización. La Policía Nacional tiene por objeto primordial promover la tranquilidad pública y en consecuencia, le corresponde proteger a las personas y las propiedades; hacer efectivos los derechos y garantías que la Constitución y las leyes les reconocen; velar por el cumplimiento de las leyes del país y las órdenes y disposiciones de las autoridades constituidas, prevenir los delitos, las faltas y las contravenciones y perseguir y aprehender a los delincuentes y contraventores Figura 1 Estructura Orgánica Policía Nacional En la Figura 1 se observa la nueva estructura Orgánica de la Policía Nacional de Colombia establecida por El Decreto No del 23 de noviembre de 2006; 17

18 el cual modifica parcialmente la estructura del Ministerio de Defensa Nacional y el Decreto No. 049 de [ ] A nivel asesor se observan varias dependencias de la Dirección General de la Policía Nacional; entre las cuales se encuentra la Oficina de Telemática, dependencia actualmente dirigida por el T.C Jairo Gordillo y en la cual se lleva a cabo el desarrollo del proyecto. La misión de la Oficina de Telemática de la Dirección General de la Policía Nacional es asesorar y promover el desarrollo tecnológico de la institución en las áreas de informática y telecomunicaciones a través de la investigación, implementación, administración y soporte con el fin de estandarizar los procedimientos e innovar la infraestructura telemática para apoyar la gestión policial. [ ] En la Figura 2 se encuentra la estructura orgánica de la Oficina de Telemática aprobada según resolución del 15 de Junio del año 2007, en la cual se establece el nivel jerárquico del grupo de trabajo. [ ] Figura 2 Estructura Orgánica Oficina de Telemática Este proyecto se desarrolla en el área de tecnologías de la información en el grupo de administración infraestructura telemática. 18

19 2. MARCO TEÓRICO En este capítulo se lleva a cabo el marco teórico del proyecto en el cual se muestra un estudio de la información general del proyecto y del problema a solucionar durante el desarrollo del mismo, proporcionando de esta manera una orientación a la búsqueda de términos BIBLIOTECA DE INFRAESTRUCTURAS DE TECNOLOGÍAS DE LA INFORMACIÓN (ITIL) La librería de infraestructuras de Tecnologías de la Información es un conjunto de guías cada una dedicada a un área específica dentro de la Gestión de Tecnologías de la Información y las Comunicaciones desarrolladas en los años ochenta en Gran Bretaña por la CCTA 5 actualmente conocida como OGC 6, las cuales proporcionan un manual de buenas prácticas, mediante una lista de tareas, roles, procedimientos y responsabilidades que se pueden adaptar a cualquier organización de TI para garantizar la calidad de servicios demandada. [ ] ITIL es una librería de constante evolución y la mejor descripción de Gestión de Servicios TI. Las librerías ITIL fueron desarrolladas al reconocer que las organizaciones dependen cada vez más de las TI para alcanzar sus objetivos corporativos lo que da como resultado una necesidad creciente de servicios TI de calidad que corresponda con los objetivos de las organizaciones y las expectativas del cliente. [ ] Desde entonces se ha ido extendiendo su uso en todas la empresas privadas, tanto multinacionales como Pequeñas y medianas empresas, llegando a ser considerado un estándar de facto7 para la gestión de la infraestructura 5 CCTA: Agencia Central de Telecomunicaciones y Computación 6 OGC: Oficina Gubernamentaria de Comercio Británico 7 Estándar que es basado en la práctica y no es creado por un ente de regulación. 19

20 tecnológica de la empresa; debido a la gran expansión del modelo recientemente fueron publicadas las librerías de ITIL versión 3 para hacer más simple el acceso a la información necesaria para la administración de los servicios; esta versión tiene un enfoque desde la previa alineación de las TI y el negocio a la Gestión del ciclo de vida de los Servicios que las TI proveen a las organizaciones. Los cinco libros de referencia de ITIL V3 son: Estrategia del servicio (Service Strategy) Diseño del servicio (Service Desing) Transición del servicio (Service Transition) Operación del servicio (Service Operation) Mejora continua del servicio (Continual Service) Aunque la base para el desarrollo del proyecto es la librería de transición del servicio, es importante aclarar que cada una de las librerías expuestas en ITIL versión 3 tienen un alto grado de influencia en el proyecto. Figura 3 Núcleo ITIL versión 3 1. La estructura de núcleo de la Figura 3 ilustra la relación de las cinco librerías expuestas en ITIL V3 20

21 OGC, Service Transition ITIL V3: En Change Management, Reino Unido, OGC, p [ ] para las cuales las operaciones TI de las organizaciones trabajan como un ciclo de vida iterativo y multidimensional en el cual se provee una estructura, estabilidad y fuerza para le gestión de servicios TECNOLOGÍAS DE LA INFORMACIÓN (TI) Las tecnologías de la información son aquellas que se encargan del diseño, desarrollo, fomento, mantenimiento y administración de la información por medio de sistemas informáticos. [ ] Cabe resaltar que las TI no solamente incluye las computadoras sino también todos los sistemas informáticos, las redes de telecomunicaciones, la televisión, la radio, los periódicos digitales y dispositivos como los teléfonos celulares o dispositivos portátiles; es por ello que las TI son actualmente parte fundamental en las organizaciones para cumplir con sus objetivos ya que son un factor de gran importancia en la transformación de la nueva economía global y en los rápidos cambios que están tomando lugar en la sociedad. Según Harvey Brooks y Daniel Bell: Las tecnologías de la información más que herramientas generadoras de productos finales, son procesos científicos, cuyo principal objetivo es la generación de conocimientos, que a la postre incidirán en los modos de vida de las sociedades, no sólo en un ámbito técnico o especializado, sino principalmente en la creación de nuevas formas de comunicación y convivencia global [ ] 2.3. BASE DE DATOS DE ADMINISTRACIÓN DE LA CONFIGURACIÓN (CMDB) La Base de Datos de Administración de la Configuración es el complemento central de la gestión de los servicios TI basados en el modelo de procesos ITIL, cuyo fin es definir todos los elementos de configuración, siguiendo el rastro de 21

22 los componentes TI y las relaciones físicas y lógicas entre ellos, para así asociar un ítem configurable con un servicio de TI. Una CMDB puede consistir en varias bases de datos físicas que forman una entidad lógica. La CMDB además de encargarse de los componentes TI y sus diferentes Ítems configurables también se encarga del componente humano, para lo cual tiene que familiarizar el personal con el uso de los procesos ITIL y así lograr desarrollar eficazmente los diferentes procesos en las organizaciones. [ ] 2.4. Gestión de Cambios EL objetivo de este proceso es que se realicen e implementen adecuadamente los cambios necesarios en la infraestructura y servicios TI, mediante procedimientos estándar, rápidamente y con el menor impacto posible en la calidad de los servicios, logrando así reducir el número de incidentes y problemas asociados a todo cambio y obtener una mejor estimación de los costos a los que conlleva el cambio. Esta gestión es considerada la parte más importante en la administración de la infraestructura TI ya que el entorno de negocios competitivo debe desarrollarse en un mundo cambiante y en constante evolución. Es importante tener en cuenta que no todos los cambios que aprueba y planifica la gestión de cambios están encaminados a solucionar los problemas, ya que al eliminar problemas pueden generar otros incidentes relacionados a las nuevas implementaciones. Una excelente gestión de Cambios se lleva a cabo mediante diferentes actividades como el registro, aceptación, clasificación, planeación, construcción, implementación y evaluación de cada una de las RFC 8, cabe aclarar que dichos procedimientos deben contar con la autorización del 8 RFC: Peticiones de Cambio 22

23 CAB 9 cuando los cambios tienen gran impacto sobre la organización y el esfuerzo requerido para su implementación es grande. Beneficios de la Gestión de Cambios La gestión de cambios garantiza que los demás procesos de gestión aumenten su productividad y eficiencia ya que con una adecuada administración de los cambios no solo se logra calidad y disponibilidad en los servicios sino también satisfacción de los usuarios. 9 CAB: Consejo Asesor de Cambios es un órgano interno, presidido por el Gestor de Cambios, formado principalmente por representantes de las principales áreas de la gestión de servicios TI. 23

24 3. INGENIERÍA DEL PROYECTO En este capítulo se detalla el estado actual de los procesos con relación a los cambios de la infraestructura tecnológica y a la utilización de la mesa de ayuda en la Oficina de Telemática de la Policía Nacional, además se observan las variables de ingeniería que intervienen en el desarrollo de este proyecto y la metodología adoptada para los adelantos del mismo ESTADO DEL ARTE El procedimiento desarrollado actualmente en la Oficina de Telemática de la Policía Nacional para la solicitud, registró, aceptación y solución de los cambios de la infraestructura TI se encuentran actualmente organizadas como se enuncia en los siguientes párrafos Obtención de Calidad. Actualmente la Oficina de Telemática de la Policía Nacional se encuentra en la búsqueda y mejora de procesos que conlleven a la institución a brindar servicios de calidad en cada uno de sus servicios, por ello es de suma importancia una excelente gestión de la infraestructura tecnológica en la organización mediante la adopción de modelos con los cuales se logre obtener certificaciones de calidad Estructuración de Cambios La forma en la que son llevados a cabo los cambios de la infraestructura tecnológica en la Oficina es aleatoria ya que no se cuenta con una estructura organizativa para la toma de decisiones y no existe un CAB ni un comité de emergencia para la realización de cambios de gran impacto REQUERIMIENTOS DE LA EMPRESA Para el desarrollo de la metodología de Gestión de Cambios en la Oficina de Telemática de la Dirección General de la Policía Nacional se tuvieron en 24

25 cuenta aspectos importantes que fueron establecidos por la organización como prioridades, los cuales son: 1. Dar continuidad al modelo ITIL, con el fin de que en un futuro se pueda implementar todo el modelo en la Oficina, es por esto que el primer requerimiento es el de ceñirse a dicho modelo basándose en los trabajos anteriormente realizados de implementación del manual de buenas prácticas. 2. Tener en cuenta la adopción de parámetros y configuraciones establecidos anteriormente para la correcta estructuración de la Base de Datos del Conocimiento. 3. Estructurar objetivamente el organigrama de las autoridades en la gestión de cambios de acuerdo a las áreas de trabajo de la organización. 4. Toda la información que se maneja y a la cual se me permite tener acceso debe ser totalmente confidencial, es por esto que no se me permite sacar ningún tipo de información que posea la base de datos, o cualquier otro tipo de información suministrada ni mostrarla fuera de la institución, ni a terceros. 5. Todo el proceso realizado para el desarrollo del proyecto y sus respectivos resultados deben ser informados al personal de la Oficina mediante sensibilizaciones en las cuales se expliquen los aportes hechos a la institución y como estos contribuyen una mejora en la calidad de los servicios de la oficina ESTUDIO DE LAS VARIABLES DE INGENIERÍA Para el desarrollo del proyecto se tuvieron en cuenta las siguientes variables de ingeniería, las cuales están basadas en la provisión de servicios TI y administración y gestión de los mismos. 25

26 Cantidad de RFCs aceptados Esta variable de ingeniería depende de las solicitudes de cambio recibidas en Mesa de Ayuda y los casos en que estas solicitudes son lógicas, coherentes y viables para ser analizadas por el CAB. Es de gran importancia observar el número de casos de solicitudes de cambio aceptados para así tener una medición del total de solicitudes generadas en la institución sobre las que son estudiadas en el CAB. Para la evaluación de esta variable se ha tomado la fórmula como: Número de Solicitudes de Cambio aceptadas 100% Número total de Solicitudes de Cambio Donde el numerador son el número de solicitudes de cambio que Mesa de Ayuda ha considerado viables y coherentes, y el denominador son el número total de solicitudes de cambio reportadas en mesa de ayuda Tiempo de solución de un cambio de Emergencia Esta variable es una de las más importantes ya que intenta medir el tiempo que tarda un cambio de emergencia desde el momento en que es reportado en Mesa de Ayuda hasta el momento de su cierre, para así comprobar la eficiencia del proceso de cambio y la calidad de los servicios TI prestados en la institución ya que un cambio de emergencia afecta con un gran impacto la provisión de los servicios. Para la evaluación de esta variable se ha tomado la fórmula como: Tiempo de Solucion de Cambios de Emergencia Numero de Cambios de Emergencia reportados Donde el numerador es la sumatoria total del tiempo que tarda el cierre de una serie de cambios de emergencia de casos reportados en un lapso de tiempo y el denominador es el número total de cambios de emergencia reportados en el mismo intervalo de tiempo. 26

27 3.4. DESARROLLO DEL PROYECTO En el desarrollo del proyecto se muestran los procedimientos realizados para llevar a cabo la clasificación de los cambios, la estructuración del Consejo Asesor de Cambios y el Comité de Emergencia, así como la metodología de cambios que contribuya a la gestión y administración de la infraestructura tecnológica de la Oficina de Telemática. Figura 4 Metodología por fases Documentación y registro de los cambios realizados en la OFITE Socialización y entrega de documentación a la OFITE Metodología de Gestión de Cambios para la OFITE de la Policía Nacional Clasificación y parametrización de las solicitudes de cambio Documentación de Metodología Estructuración del organigrama de las autoridades en la gestión de cambios Tal y como se observa en la Figura 4 para el desarrollo del proyecto se plantea una metodología de fases que permite llevar a cabo el cumplimiento y valoración de los objetivos del proyecto secuencialmente, logrando así una mejor evolución de los procesos y facilidad en la evaluación de los mismos. FASE 1: Documentación y registro de los cambios realizados en la OFITE. 27

28 FASE 2: Clasificación y parametrización de las solicitudes de cambio. FASE 3: Estructuración del organigrama de las autoridades en la gestión de cambios. FASE 4: Documentación de Metodología adecuada para el proceso de control de cambios. FASE 5: Socialización y entrega de documentación de los procesos realizados a la OFITE. A continuación se explican los procesos que fueron desarrollados en cada fase y que sirvieron de base para la continuidad del proyecto fase por fase Documentación y registro de los cambios realizados en la OFITE. Durante el desarrollo de esta fase se llevó a cabo la documentación de todo lo relacionado a los cambios y la administración de estos en la Oficina de Telemática. Documentación Metodologías Aplicadas en la institución Durante esta fase se realizó la documentación necesaria para el desarrollo del proyecto, la primera etapa consistió en consultar los libros de soporte ITIL y los trabajos desarrollados anteriormente sobre el tema en la institución, para determinar la metodología estándar con la cual se realizará la administración de los cambios, sin embargo durante la documentación del modelo se estableció que muchos de los procesos aconsejados por el ITIL no son aplicables a la institución. La primera fuente consultada fue la información suministrada por el Ingeniero Juan Camilo Méndez autor del primer proyecto de introducción del manual de buenas prácticas a la institución, en esta información se observó la clasificación actual de los incidentes presentados en la Oficina 28

29 de Telemática mediante la matriz de impacto- urgencia, desarrollada en su proyecto, en la cual se definen tres niveles esenciales entre cada una de las variables de impacto y urgencia. Esta matriz debe ser operada por el grupo de Mesa de Ayuda ya que es su labor especificar la prioridad que presentan los problemas y el grupo que debe ser asignado para su solución. [ ] Figura 5 Matriz de Impacto- Urgencia propuesta en la oficina. La segunda fuente de información consultada fue el libro de Estructuración de la Base de Datos de Conocimiento de la Dirección General de la Policía Nacional enfocado a Problemas e Incidentes, desarrollado por el Ingeniero Laureano Amado Tapias en el cual se establecen dos modelos básicos aplicados en la Mesa de Ayuda para la administración de los problemas e incidentes reportados. [ ] El primer modelo es la codificación de los problemas e incidentes reportados en Mesa de Ayuda que cuenta con una parametrización numérica y está compuesta por cuatro números separados entre sí por puntos, el primer número equivale a la categoría, el segundo número equivale a la sub categoría y los dos siguientes números equivalen al tipo de producto y elemento tal y como se observa en la Figura 6. 29

30 Figura 6 Clasificación de Problemas y soluciones El segundo modelo establecido en este libro es el proceso que permite brindar una solución o escalar un problema desde el momento en que se realiza su recepción en Mesa de Ayuda. Figura 7 Metodología de la solución registro y escala de problemas Mesa de Ayuda 30

31 Como se observa en la Figura 7 este modelo lo componen cuatro niveles jerárquicos que permiten brindar un servicio continuo de las TI. Cuando se recibe el reporte de un problema o incidente, se atiende directamente por los operarios de la línea de mesa de ayuda, en ese momento se hace una petición del servicio mediante la generación de un número de orden, este número permite al usuario tener una prueba de que el problema o incidente fue reportado. Si el operario en el momento de consultar la CMDB encuentra la solución al problema, debe registrarla, pero en caso contrario debe ser escalado al segundo nivel de servicio donde se encuentra el personal de técnicos. En el segundo nivel de ayuda el personal técnico realiza un análisis con base a lo reportado en la Mesa de Ayuda para identificar cual es la causa del problema o incidente reportado. El personal técnico realiza las pruebas necesarias para resolver el problema. Si el problema o incidente se soluciona, el personal técnico debe realizar el registro de la solución, en caso contrario el personal técnico debe escalar el problema a un tercer nivel de ayuda donde se encuentran los administradores. Los administradores realizan el análisis del proceso llevado hasta el momento, para determinar o identificar el problema o incidente. El personal de administradores está capacitado para resolver cualquier tipo de problemas. Si el administrador no logra identificar el problema o no cuenta con los recursos para atenderlo deberá ser reportado a los proveedores que le brindan el servicio. 31

32 Documentación actual de la Gestión de Cambios en la Oficina de Telemática de la Policía Nacional La administración de los cambios en la institución se debe llevar a cabo con el objetivo de hacer, mejorar, evaluar y planificar el proceso de cambio de la infraestructura tecnológica. La evaluación de todas las posibilidades que surjan de la aprobación actual de un cambio, plantea las siguientes diez pautas las cuales fueron evaluadas con la ayuda de los administradores de tecnologías de la información teórica y numéricamente como se observa a continuación: - Evaluación Numérica Para llevar a cabo la evaluación de la administración de los cambios al dar inicio al proyecto se estipuló la clasificación numérica con 5 variables, las cuales van de mayor a menor cumplimiento de las pautas; por lo tanto el máximo numero en este caso (4) equivale a un valor con el cual se especifica que se está cumpliendo en un 100% dicho proceso en la oficina y a medida que desciende la numeración decrementa el porcentaje de cumplimiento de las actividades; por ello se propone la Tabla 1 que muestra los niveles de evaluación: Tabla 1 Especificación de Niveles de evaluación Escala de Evaluación 0 Nunca La oficina no cumple en ningún porcentaje la actividad evaluada (0%). 1 Rara vez La oficina cumple en un 25% la actividad evaluada. La oficina cumple en un 50% ó término medio la 2 Parcialmente actividad evaluada. 3 Casi siempre 4 Siempre La oficina cumple en un 75% la actividad evaluada.. La oficina cumple al 100% ó totalmente con la actividad evaluada. 32

33 Por lo tanto la evaluación obtenida de cada uno de las pautas se puede observar en la siguiente tabla: Tabla 2 Actividades de Gestión de Cambios evaluadas Evaluación Actividad 1 Justificación de los cambios aprobados en la Oficina de Telemática Número % 2 50% 2 Cambios Vs calidad del servicio TI 3 75% 3 Registro, clasificación y documentados de los cambios realizados 0 0% 4 Actualizaciones en la CMDB 0 0% 5 Consejo para la Gestión de Cambios 0 0% 6 Indicadores de rendimiento en la Administración Actual de Cambios en la oficina 7 Número de Incidentes presentados debido a los cambios 0 0% 3 75% 8 Base de datos de número de cambios rechazados 0 0% 9 Estimación de los costos de los cambios implementados 3 75% 10 Tiempos de ejecución de cambios de emergencia 0 0% Como se observa en la Tabla 2 de 40 puntos que se deberían obtener en la evaluación de administración de cambios establecida 33

34 es decir el 100% de cumplimiento de actividades; se obtuvo una puntuación de 11 es decir el 27,5%. - Evaluación Teórica 1. Justificación de los cambios aprobados en la Oficina de Telemática. Aunque no existe un Consejo asesor de cambios ni un modelo a seguir para la planeación de los mismos, los cambios aprobados han sido estudiados y justificados por personal de diferentes áreas de la oficina en la mayoría de los casos. 2. Cambios Vs calidad del servicio TI. A pesar de no contar con una metodología para la administración de los cambios la oficina cumple a cabalidad sus objetivos para alcanzar los procesos misionales de su creación, entre los cuales se encuentran la calidad en la prestación de los servicios. 3. Registro, clasificación y documentados de los cambios realizados. El registro de las solicitudes de cambio no se lleva a cabo por el personal de Mesa de ayuda ni tampoco existe un modelo de clasificación para las solicitudes de cambio generadas. 4. Actualizaciones en la CMDB. No todos los cambios implementados en la infraestructura tecnológica de la institución son registrados en la CMDB, lo que provoca una incorrecta administración de estos. Para la Oficina de Telemática es necesario realizar cambios que provean calidad, aumento en el rendimiento y modernización de la infraestructura. Mediante un correcto registro, aceptación, planificación, coordinación y evaluación de cambios. 5. Consejo para la Gestión de Cambios. Al dar inicio al proyecto la Oficina de Telemática de la Policía Nacional no cuenta con la 34

35 estructuración de un Consejo Asesor de Cambios encargado de administrar correctamente las solicitudes; es por ello que uno de los objetivos del proyecto fue llevar a cabo la conformación de este grupo para lograr una mejor administración de los cambios. 6. Indicadores de rendimiento en la Administración Actual de Cambios en la oficina. Actualmente no se tiene el tiempo exacto que tarda la ejecución de un cambio, ya que en muchas ocasiones lo cambios son abiertos en la Mesa de Ayuda, pero no se lleva a cabo la actualización de datos del proceso real ya que no se ha comprado el paquete de cambios de la plataforma service manager ni existe una base de datos estándar para estos. 7. Número de Incidentes presentados debido a los cambios. Aunque la implementación de los cambios conlleva a una serie de incidentes sobre la infraestructura tecnológica de la institución; en la base de datos estos incidentes no se encuentran directamente relacionados con los cambios. 8. Base de datos de número de cambios rechazados. No se cuenta con una base de datos de todas las solicitudes de cambio generadas en la institución. 9. Estimación de los costos de los cambios implementados. Aunque no existe un estándar para la planeación, aprobación y ejecución de los cambios, la Oficina de Telemática cuenta con un sistema de control financiero encargado de realizar un análisis costos-beneficios para las actualizaciones o nuevas implementaciones. 10. Tiempos de ejecución de cambios de emergencia Actualmente el número de cambios de emergencia reportados en la oficina en un lapso de tiempo de junio de 2008 a junio de

36 equivalen a 5 cambios de los cuales ninguno cumple con un tiempo inferior a 2 horas. o Funciones de la Oficina de Telemática para la Administración de los Cambios a. Garantizar la elaboración de planes y mecanismos que aseguren la estabilidad de la infraestructura tecnológica. b. Estudiar y clasificar las solicitudes de cambio para evaluar cuales son necesarias en la infraestructura tecnológica para llegar a disminuir los problemas o realizar actualizaciones que mejoren la calidad del servicio. c. Evaluar y planificar el proceso de cambio de la infraestructura tecnológica para identificar si estos cumplen con los objetivos de su desarrollo. d. Reducir el número de incidentes y problemas eventualmente asociados a todo cambio junto con el número de cambios que no cumplen con los requerimientos prescritos para su desarrollo. e. Evaluar los costos asociados a todo cambio. f. Clasificar y estudiar todas las peticiones de cambio generadas en la organización. g. Actualizar constantemente la CMDB para garantizar la correcta gestión del resto de procesos. h. Reducir el impacto producido por los cambios en la infraestructura TI. i. Evaluar y analizar los incidentes que se puedan presentar tras la implementación del cambio. j. Realizar un estudio detallado de los cambios aprobados donde se encuentre el estudio de factibilidad que demuestre que el cambio es conveniente para la infraestructura tecnológica y su administración. 36

37 k. Evaluar la satisfacción de los usuarios con los cambios que intervienen directamente con ellos. Documentación Base de Datos del Conocimiento Durante la fase de documentación se requirió la información de la Base de Datos del Conocimiento, para lo cual fue necesaria la creación de un usuario y contraseña que permitieran el ingreso al programa Service Manager utilizado actualmente en Oficina para la administración de la infraestructura tecnológica, y en el cual se encuentra la Base de Datos del conocimiento. Este usuario fue solicitado mediante un oficio hecho por escrito al jefe del Área (Ver ANEXOS A en (ANEXO A-1)). Para ingresar a la base de datos donde se encuentra la información de los problemas repetitivos los cuales conllevan a algunos de los cambios realizados en Oficina de Telemática se debe registrar el usuario con su debida contraseña. Figura 8 Base de Datos de Cambios Aprobados Como se muestra en la Figura 8 los cambios registrados en la base de datos del conocimiento están clasificados según el número identificador 37

38 único para cada cambio, la categoría del cambio, la fase en la que se encuentra, la evaluación del riesgo, la fecha de inicio y fecha de cierres previstos y el nombre de cada uno de los cambios; cabe aclarar que el paquete general de cambios de esta aplicación está en proceso de adquisición. Documentación de cambios y peticiones de cambio Para llevar a cabo la documentación de las solicitudes de cambios frecuentes en Oficina de Telemática de la Policía Nacional se realizo un oficio en el cual se solicito el permiso para el acceso a la información (Ver ANEXOS A en (ANEXO A-2)) Gracias a la documentación suministrada por el personal de la oficina se estableció una base para la clasificación de los cambios realizada en la FASE 2 de desarrollo del proyecto con la cual se facilito la aprobación y clasificación de las solicitudes de cambio presentadas Clasificación y parametrización de las solicitudes de cambio. En esta fase se desarrolló la propuesta para la clasificación de las solicitudes de cambios dependiendo de la clase de solicitud de cambio, de la prioridad asignada mediante la matriz de impacto sobre los servicios Vs la urgencia de la solución y la categorización de los servicios y del personal que permite clasificar las áreas que son afectadas con la implementación de un cambio. Clasificación Con base a los requerimientos del grupo de administración de la infraestructura telemática en cuanto a la clasificación de las solicitudes de cambio se desarrollo una propuesta en la cual las solicitudes deben ser clasificadas de cinco formas: a) por clase de solicitud, b) por categoría de impacto, c) por categoría de urgencia, d) por prioridad, e) por riesgo. 38

39 o Clasificación por Clase de Solicitud Para determinar la clase de solicitud generada se propuso la clasificación de cambios preventivos y cambios correctivos. Por cambios preventivos (P) se clasificaran todas aquellas solicitudes de cambio generadas con la intención de prevenir un suceso futuro o de hacer mejoras en la calidad y disponibilidad del servicio, esta clase de cambios tendrá un mayor tiempo de ejecución ya que en el momento no están afectando la provisión de servicios. Los Cambios Correctivos (C) son aquellos que deben ejecutarse debido a que afectan la calidad y disponibilidad de los servicios. o Clasificación Según Categoría de Impacto Para la clasificación de la categoría de impacto de los servicios que se ven afectados con el cambio se desarrollo una propuesta en la cual se estableció la numeración según el impacto del cambio sobre los servicios de la infraestructura tecnológica. El nivel de impacto establecido en la Tabla 3 está basado en la clasificación de los administradores de red y grupos anteriores; quienes especifican el impacto de acuerdo a las necesidades de la institución. Tabla 3 Categorización del Impacto de los Servicios propuesta por los administradores de red CATEGORÍA SUBCATEGORÍA IMPACTO Recursos humanos 5 Mesa de ayuda 2 Operativo 5 Inventarios 3 Financiero 5 Siif 5 Visitantes 3 Office Comunicator 3 Clima laboral 3 Jurídico 4 Prestaciones sociales 4 39

40 APLICACIONES COMPUTADORES Y PERIFÉRICOS COMUNICACIÓN DE DATOS COMUNICACIÓN DE VOZ Protección a dignatarios 4 Víctimas de la violencia y 3 desastres naturales Facturación de dotaciones 3 Académico 3 Consulta wireless 4 Kardex proveedores 4 Requisitos y competencias 3 Plan democracia 3 Gestión parque automotor 3 Funciones para desempeñar 2 cargo Atención al ciudadano 5 Nomina 5 Control de cambios 3 Plan de compras 3 Centros vacacionales 2 Radicación de documentos 4 Operaciones antinarcóticos 5 Red de cooperantes 5 Bienes incautados 3 Disponibilidades 3 Juntas medico-laborales 4 Incorporación 4 Gestión de elementos servicio 3 policial Correo electrónico 5 Intranet 4 Pagina web 4 Equipos de Proyección de datos e 2 imágenes Impresoras 2 Microcomputadores 4 Plotter 3 Portátiles 2 Scanner 2 Servidores 5 Cableado Estructurado 2 Concentradores 3 Direcciones IP 3 DNS servers 5 Dotación de Equipos 3 Firewall 5 Habilitar puntos de red 2 Módems canales 4 Routers 5 Switchs 5 Tranceiver 5 Bases Dotación de Equipos 3 Emisoras 4 Móviles 3 Portátiles 3 40

41 ENLACES FUENTES DE ALIMENTACIÓN SEGURIDAD DE INSTALACIONES TELEFONÍA Repetidores 5 Sistema Troncalizado 5 Back Bone 4 Dedicados 4 Fibra Óptica 5 Frame Relay 5 Microondas 5 Satelital 5 Aire Acondicionado 5 Instalaciones Corriente 3 convencional Instalaciones Corriente Regulada 5 Plantas Eléctricas 4 Reguladores de voltaje 2 UPS 4 Cabinas o Esclusas 3 Circuito Cerrado de Televisión 4 Control de Puertas Eléctricas 4 Equipos de Rayos X 4 Sistemas de Detección de 3 Incendios Avantel 4 Central Telefónica (PBX) 5 Fax 3 Teléfonos 3 La clasificación numérica se determinó con 5 variables para la categorización del impacto de los cambios, las cuales van de mayor a menor impacto, por lo tanto el máximo número en este caso (5), establece cambios con un gran impacto sobre la infraestructura tecnológica y a medida que desciende la numeración, decrementa el nivel de impacto del cambio sobre los servicios, se propone la Tabla 4 que muestra los 5 niveles establecidos para la clasificación. Tabla 4 Especificación de Niveles de Impacto, derivada de la tabla de categorización. Escala de Impacto 1 Intrascendente Mínimo Riesgo que el cambio afecte la disponibilidad total de los servicios, en caso de presentarse permite tiempos moderados para su ejecución. 2 Menor Baja probabilidad que el cambio afecte la disponibilidad total del servicio en la organización. Media probabilidad que el cambio afecte la 3 Medio disponibilidad total del servicio en la organización. (Riesgo Medio) 4 Mayor Alta probabilidad que el cambio afecte la disponibilidad total del servicio en la organización, en caso de presentarse los tiempos de ejecución del cambio son cortos. 41

42 5 Catastrófico Máximo probabilidad que el cambio afecte la disponibilidad total del servicio en la organización, en caso de presentarse los tiempos de ejecución del cambio deben ser inmediatos. El uso de la categorización del impacto de los servicios queda a disposición del personal de la Oficina y se adecua para que todo el personal de soporte conozca su desarrollo y opinen acerca de sus funciones, valorando en cierta medida el porcentaje de aceptación para su posterior uso. o Clasificación Según Categoría de Urgencia Para la clasificación de la categoría de urgencia de las solicitudes de cambio, se desarrollaron diferentes matrices las cuales fueron modificadas; para finalmente establecer una propuesta basada en los procesos misionales y el organigrama jerárquico de la Oficina de Telemática. Esta clasificación fue diseñada en común acuerdo con el personal del Grupo de Administración de Infraestructura Telemática, donde se establecieron los niveles de necesidad de prestación del servicio para las diferentes áreas o dependencias de la Oficina. Tabla 5 Clasificación Jerárquica Magnitud de la Cargo Descripción Urgencia por Cargo 5 Jefe OFITE Director de la Oficina de Telemática de la Policía Nacional 4 Jefe Área Encargado del funcionamiento de las diferentes áreas establecidas en la Oficina de Telemática. 3 Jefe Grupo OFITE Encargado del funcionamiento de los grupos de tercer nivel de soporte de la Oficina de 2 Jefe Grupo Departamentos Telemática. Encargado del funcionamiento de los grupos de primer y segundo nivel a nivel departamental. 42

43 1 Personal OFITE Personal encargado de llevar a cabo las tareas dentro de los procesos de la Oficina de Telemática Como se observa en la Tabla 5 la clasificación jerárquica se llevó a cabo dependiendo de los cargos ocupados en la Oficina, siendo (5) la solicitud de cambio con mayor urgencia y (1) la solicitud que más puede tardar en su ejecución. Posteriormente se debe establecer la magnitud de la urgencia por procesos tal y como se observa en la Tabla 6, donde (5) es el valor asignado a aquellas tareas que afectan totalmente el cumplimiento de los procesos misionales y (1) las tareas menos relevantes para el cumplimiento de dichos procesos. Tabla 6 Clasificación de Procesos Magnitud de la Urgencia por Descripción Procesos 5 Tareas que afecten totalmente el cumplimiento de la Misión de la Oficina. 4 Tareas que afecten en gran parte el cumplimiento de la Misión de la Oficina. 3 Tareas que afecten parcialmente el cumplimiento de la Misión de la Oficina. 2 Tareas que afecten levemente el cumplimiento de la Misión de la Oficina. 1 Tareas que no afecten directamente el cumplimiento de la Misión de la Oficina. Finalmente, luego de establecer la magnitud de urgencia de la solicitud de cambio por cargos y por procesos, estas deben ser sumadas y dividas entre dos para hallar la categoría de urgencia ponderada de la solicitud. Nivel de Urgencia = Magnitud Jerarquica + Magnitud Por procesos 2 43

44 En la Tabla 7 se observa la clasificación de los niveles de urgencia establecidos para las diferentes solicitudes elevadas. Tabla 7 Especificación de Niveles de Urgencia Escala de Urgencia Rango de Evaluación 0 1 Mínimo Bajo Medio Alto Máximo La solicitud de cambio generada permite tiempos moderados para su ejecución, ya que no afecta directamente los procesos misionales de la Oficina. La solicitud de cambio generada permite algunos días para la ejecución del cambio, si este es (Correctivo), ya que la misión general de Oficina no se ve directamente afectada. El tiempo de ejecución de la solicitud de cambio generada debe ser menor a 1 día para cambios correctivos, ya que el desarrollo de tareas que está siendo restringido afecta en gran parte los procesos misionales de la Oficina. La solicitud de cambio debe ser ejecutada lo más pronto posible, ya que la misión general de Oficina se ve directamente afectada con el no cumplimiento de las tareas. Los tiempos de ejecución del cambio deben ser inmediatos, debido a que se pone en riesgo el cumplimiento de los procesos misionales de la Oficina. o Clasificación según su Prioridad Para determinar la prioridad, durante el desarrollo la matriz de impactourgencia se tomó como base el modelo de matriz propuesta por el ITIL y se trató de involucrar la prioridad de las solicitudes según el impacto y urgencia del cambio para dar así el tiempo previsto al desarrollo del mismo. 44

45 Urgencia de la Solución Tabla 8 Matriz de Impacto contra Urgencia. Impacto Sobre los Servicios PRIORIDAD Intrascendente Menor Medio Mayor Catastrófico (1) (2) (3) (4) (5) Mínimo Bajo Medio Alto Máximo Prioridad Prioridad Prioridad Prioridad Prioridad Mínima Baja Moderada Alta Máxima Como se observa en la matriz de la Tabla 8 se consideran 5 variables para la interpretación de la prioridad, las cuales indican el tiempo previsto para la ejecución del cambio dependiendo de la clase de solicitud generada. En la Tabla 9 se muestra los plazos de tiempo establecidos para la solución del cambio dependiendo de la prioridad asignada en la anterior matriz. En el futuro estos tiempos previstos para la ejecución de la solicitud determinarán la eficiencia del personal encargado de la administración de los cambios. 45

46 Tabla 9 Especificación de Prioridades PRIORIDAD Clase de solicitud Correctiva Prioridad mínima Se tienen mayores tiempos para su ejecución Prioridad baja Se tienen altos tiempos para su ejecución dependiendo de las prioridades Prioridad moderada Tiempo de solución moderado dependiendo de las prioridades Prioridad alta Su solución debe ser rápida aunque se deben tener en cuenta las prioridades Prioridad Máxima Su solución debe ser lo más pronto posible. Preventiva Prioridad mínima Tempo de solución inferior a 18 meses. Prioridad baja Tiempo de solución inferior a 12 meses. Prioridad moderada Tempo de solución inferior a 10 meses. Prioridad alta Tempo de solución inferior a 8 meses. Prioridad Máxima Tempo de solución inferior a 4 meses. Esta matriz debe estar a cargo del personal asignado para llevar a cabo la aceptación y clasificación de las solicitudes. Como se observa en la Tabla 8 se debe manejar la categoría de impacto sobre los servicios desde cinco ámbitos los cuales son catastrófico, mayor, medio, menor e intrascendente y hacen referencia directamente al tipo de servicio afectado con el cambio y la cantidad de personas que se ven afectadas con el mismo. La urgencia en la ejecución del cambio se encuentra clasificada en cinco categorías diferentes las cuales son mínimo, bajo, medio, alto y máximo, estos niveles deben ser interpretados directamente con la oficina o persona que está siendo impedida de ejercer su trabajo y los procesos misionales afectados. La prioridad se calcula de acuerdo a la intercepción del impacto y la urgencia encontrados, y como tal debe ser interpretada de acuerdo con 46

47 estas variables para establecer el tiempo estimado para la solución de cada solicitud. Prioridad de Cambio = Urgencia de la Solución Impacto sobre los Servicios Los tiempos especificados en la Tabla 9 para el cierre de las solicitudes se establecieron de común acuerdo con el Intendente Julián Rodríguez encargado del área de Gestión de Red de la oficina y varían de acuerdo a la magnitud y clase de solicitud generada. Estos métodos de clasificación se entregaron a la Oficina de Telemática mediante un oficio, contenido en ( ANEXOS A (ANEXO A-3), con su respectivo manual y grupo al cual se debe asignar el manejo de las clasificaciones. o Clasificación del Riesgo Para determinar la acción a tomar dependiendo de los riesgos a los que se enfrenta la estabilidad de la infraestructura tecnológica con la ejecución de los cambios, se desarrolló una propuesta en la cual se clasifican la probabilidad de riesgo numéricamente, siendo (3) la probabilidad de riesgo más alta que puede presentarse y (1) la probabilidad mínima de riesgo al ejecutarse el cambio. Para el impacto del cambio sobre los servicios se considero la clasificación siendo (5) el más alto impacto y (1) el mínimo impacto que se puede presentar con la ejecución de un cambio. Esta matriz debe ser usada por el personal asignado para realizar el estudio, clasificación y aceptación de las solicitudes de cambio generadas en la institución. 47

48 Probabilidad de Riesgo Tabla 10 Matriz de Riesgo Impacto Sobre los Servicios RIESGO Intrascendente (1) Menor (2) Medio (3) Mayor (4) Catastrófico (5) Máximo (5) Alto (4) Medio (3) Bajo (2) Mínimo (1) Como se observa en la matriz de la Tabla 10 se consideraron 5 variables para la interpretación del riesgo que puede presentarse sobre la infraestructura tecnológica al ejecutar el cambio. De acuerdo a ello las acciones recomendadas se observan en la Tabla 11. Tabla 11 Zonas de Riesgo Zona de Riesgo Acción Zona de Riesgo Aceptable Se recomienda asumir el riesgo. Zona de Riesgo Tolerable Se recomienda reducir el riesgo Zona de Riesgo Moderada Se recomienda asumir evitar ó compartir el riesgo Zona de Riesgo Elevada Se recomienda evitar el riesgo Zona de Riesgo Extrema Se recomienda evitar al máximo el riesgo. De acuerdo al riesgo encontrado, la persona asignada para llevar a cabo el análisis de riesgo debe diligenciar el formato de solicitudes de cambio para proporcionar esta información al gestor de cambios y posteriormente a los 48

49 integrantes del Consejo Asesor de Cambios quienes serán los encargados de la aprobación y planificación del cambio solicitado Estructuración del organigrama de las actividades en la Gestión de cambios. En esta fase se llevo a cabo la estructuración del Consejo Asesor de Cambios en el cual cada uno de los integrantes se eligió de acuerdo al área de trabajo y responsabilidades en la institución. Esta elección se hizo de acuerdo a la estructura orgánica de la Oficina de Telemática y con la ayuda y supervisión de los administradores de Red y el grupo de Mesa de Ayuda. Consejo Asesor de Cambios (CAB) El Consejo Asesor de Cambios es el cuerpo encargado de la toma de decisiones y aprobación de los cambios mas relevantes o con mayor prioridad en la estructura tecnologica sus reuniones deben ser periodicas y objetivas en los temas a tratar. El CAB esta presidido por el Gestor de Cambios y compuesto por representantes de las diferentes areas y/o secciones mas importantes de la organización dependiendo de la estructura organica de esta. Gestor De Cambios Es la persona encargada de estudiar cada una de las Peticiones de Cambio, normalmente en las grandes organizaciones el Gestor de Cambios puede tener ayudantes Coordinadores de Cambios que lo representan. El Gestor de Cambios es tambien responsable de conseguir la autorización necesaria del CAB para la realización de los cambios y posteriormente la planificación y coordinación para la implementación de estos. Comité De Emergencia (CAB/EC) Es el cuerpo encargado de aceptar y tomar las decisiones de los problemas que afectan seriamente el uso de servicios esenciales de los usuarios estos cambios son frecuentemente conocidos como Cambios 49

50 de Emergencia o cambios correctivos con maximo o alta prioridad, para su aceptación e implementación no se deben seguir los procesos normales, ya que los recursos afectados deben estar disponibles de inmediato. El CAB/EC tiene suficiente autoridad para tomar decisiones de emergencia. o Consejo Asesor de Cambios El objetivo del Consejo Asesor de Cambios es garantizar la correctta administracion de los cambios generados en la institución, asegurando de esta manera la calidad y disponibilidad de los servicios. Funciones Del CAB 1. Llevar a cabo la toma de decisiones y aprobación de los cambios mas relevantes o con mayor prioridad en la infraestructuta tecnologica. 2. Garantizar la elaboración de planes y mecanismos que aseguren la estabilidad de la infraestructura tecnológica. 3. Establecer tiempos de respuesta regulados para implementar los cambios en un horario aconsejable que minimice el impacto del servicio. Los horarios mas aconsejables son los fines de semana o fuera del horario de oficina aunque estos horarios dependen de los servicios afectados y de los niveles de servicio pactados para ellos. 4. Elaborar el calendario de Cambios o el Programa de Cambios Futuros (FSC) en el cual se encuentran los detalles de todos los cambios aprobados y su planificación. 5. Realizar el estudio de la disponibilidad de personal, los recursos, costos, aspectos de afectación del servicio y el cliente para la planificación de cambios. 50

51 6. Realizar un estudio detallado de factibilidad sobre el impacto de los cambios en la infraestructura tecnológica y su administración. 7. Evaluar y planificar el proceso de cambio de la infraestructura tecnológica para identificar si estos cumplen con los objetivos de su desarrollo. 8. Diligenciar el formato de cambios establecido para la planificación de cambios (Ver ANEXOS B en (ANEXOB-1). 9. Evaluar la satisfaccion de los usuarios, la calidad y disponibilidad del servicio con los cambios realizados observando si estos cumplen con los objetivos de su creación. 10. Suministrar el calendario de cambios y los formatos diligenciados de cada una de las solicitudes de cambio al grupo de Mesa de Ayuda. Reuniones Del CAB Las siguientes son las pautas que se deben tener en cuenta para la realización de las reuniones del Consejo Asesor de Cambios: 1. Las reuniones se deben llevar a cabo periodicamente cada 8 días. 2. El gestor de Cambios debe hacer circular los documentos y la información correspondiente sobre los puntos a tratar al dar inicio a la reunión. 3. El CAB debe tener una cantidad de puntos fijos en la agenda de sus encuentros, entre los cuales estan: Las RFCs que deben ser evaluadas por los miembros del CAB. Los Cambios abiertos y cerrados. 51

52 La evaluación de Cambios pasados. 4. Las preguntas frecuentes que debe solucionar el CAB o el Gestor de Cambio para su aprobación son: Cuáles son los beneficios esperados del cambio propuesto? La relación costo/beneficio obtenida del análisis del cambio, es considerada viable para la Institución? Cuáles son los riesgos asociados al cambio? Es viable la realización inmediata del cambio? Disponemos de los recursos necesarios para llevar a cabo el cambio satisfactoriamente? Cuál será el impacto general sobre la infraestructura y la calidad de los servicios TI? Puede el cambio afectar los niveles establecidos de seguridad TI? La Figura 9 ilustra la estructura organica de la Oficina de Telematica de la Policía Nacional, la cual fue la base para la estructuracion del CAB. Figura 9 Estructura Orgánica de la OFITE 52

53 La propuesta de estructuracion del CAB se desarrollo teniendo en cuenta las areas de trabajo en las que esta divida la Oficina de Telemática de la Policia Nacional, las responsabilidades de cada una de las areas y la entrevista con el Ingeniero Nelson Barrios del grupo de administradores de Red y el grupo de Seguridad de la información, en esta propuesta el CAB estara integrado por : La creación del CAB/EC se llevo a cabo debido a la necesidad de un comité con autoridad suficiente para la aprobación y planificación de cambios de emergencia que no puedan seguir la metodologia establecida para la administracion de cambios. Por lo tanto la conformación del CAB/EC se realizo de la siguiente forma: 53

54 Para determinar la estructuración del Consejo Asesor de Cambios y el comité de emergencia en las diferentes entrevistas con algunos grupos de la oficina se definieron los integrantes de estos grupos de acuerdo a los perfiles y funciones que se tienen establecidos en la institución, estos perfiles fueron tomados de la resolucion por la cual se define la estructura orgánica interna y se determinan las funciones de la Oficina de Telemática, por lo tanto las funciones de los integrantes del CAB y el CAB/EC se definen como se observa en el ( ANEXOS A (ANEXO A-11)) Luego de estructurar el Consejo Asesor de Cambios y el Comité de Emergencia se determinó la ubicación de este grupo dentro de la Oficina de Telemática de acuerdo a las funciones y responsabilidades que fueron delegadas al grupo por lo tanto esta estrucuturación se establecio de la siguiente forma: Figura 10 Posición del CAC en la Estructura Orgánica de la OFITE 54

55 Al finalizar esta fase, la estructuración del Consejo Asesor de Cambios se entregó a la Oficina mediante un oficio. (Ver ANEXOS A en (ANEXO A-4) Error! No se encuentra el origen de la referencia. ) Documentación de la Metodología adecuada para el proceso en la Gestión de Cambios. En esta fase se desarrolla la metodología de solución para garantizar la utilización de procedimientos y métodos estándar en el manejo de los cambios desde el momento de ingreso de estos hasta su posterior cierre. Mediante la siguiente metodología se busca garantizar que se utilicen modelos estándar para manejar los cambios con rapidez y con el menor impacto posible en la calidad de los servicios. Es importante aclarar que no todos los cambios o despliegues que se aprueben van a eliminar la totalidad de los problemas, si bien se podría observar que al hacer los cambios se pueden presentar incidentes pero a su vez se pueden eliminar algunos problemas de raíz. Para iniciar una adecuada gestión de cambios lo primero que se debe tener en cuenta es la creación de un Consejo Asesor de Cambios encargado de tomar las decisiones sobre los cambios más importantes, también debe ser creado el Comité de Emergencia encargado de la toma de decisiones para cambios correctivos urgentes y debe ser elegido el Gestor de Cambios que será el encargado de la aprobación, planificación y supervisión de cambios con prioridad media o baja. Para establecer correctamente la administración de los cambios se decidió con los administradores de red y el grupo de Mesa de Ayuda establecer un formato de solicitudes de cambio el cual debe ser diligenciado por el personal del Proceso de Administración de la Información, el personal que solicita el cambio y el personal que ejecuta la solicitud. Al finalizar la metodología de solución para la gestión de cambios se hizo entrega de una propuesta en la cual se encuentra incluido el formato de 55

56 solicitudes de cambios y el método a seguir para cada una de las solicitudes, como se puede apreciar en el ANEXOS A en (ANEXO A-5). En la Figura 10 se muestra el diagrama de bloques de la metodología propuesta para la administración de los cambios; durante el desarrollo de esta metodología se tomo como base la metodología establecida por el ITIL V3 en la que se ilustran una serie de procesos a seguir para el registro, aceptación, clasificación y planificación de las RFCs reportados. Mediante este proceso se logra implantar una guía para establecer el método que se debe seguir para una adecuada Gestión de Cambios. Figura 10 Metodología Gestión de Cambios OFITE 56

57 Registro de RFCs: El registro de las solicitudes de cambio puede ser originado desde diferentes áreas de la organización y/o por diferentes motivos, entre los cuales están. Gestión de Problemas: es la encargada de proponer soluciones a errores conocidos, en este caso la RFC es registrada con la información del error conocido tratado anteriormente en mesa de ayuda para que posteriormente pueda ser evaluada correctamente la conveniencia del cambio en la infraestructura TI. Clientes: Todos los clientes de las TI pueden elevar RFCs solicitando más, menos u otros servicios. Estrategia Empresarial: Los procesos tácticos del grupo de aprovisionamiento de servicios puede decidir una redirección estratégica de los servicios TI y esto puede conllevar a una solicitud de cambio en el hardware, software o procedimientos. Imperativo Legal: Se elevan RFCs si se imponen nuevos cambios regulatorios a las actividades del negocio o si se introducen nuevas políticas de seguridad para las TI. Nuevos Servicios: Los Proveedores realizan nuevos productos o servicios, por lo tanto la implementación de nuevos servicios requiere de un cambio en la infraestructura TI, Actualizaciones de Terceros: Se elevan RFCs cuando los Proveedores realizan actualizaciones, crean nuevas versiones en productos anteriores o dejan de soportar versiones anteriores de paquetes de software. 57

58 El resto del Personal TI: En principio cualquier empleado, cliente o proveedor puede sugerir mejoras en los servicios que pueden requerir cambios en la infraestructura. Todas las RFCs deben ser generadas mediante el formato de solicitudes (Ver Error! No se encuentra el origen de la referencia.), y posteriormente registradas por el gestor de cambios en la CMDB, este registro debe contener por lo menos los siguientes datos: Fecha de recepción de la RFC. Numero de identificador único de la RFC. Numero de identificador del error conocido asociado (dado el caso que provenga de la Gestión de Problemas). Descripción e identificación de los CIs involucrados o correspondientes. Descripción del cambio propuesto: - Motivación. - Propósito. Estatus: que inicialmente será el de "registrado". Nombre, cargo y número de teléfono de la persona que realiza la RFC. La información suministrada en este registro deberá ser actualizado con toda la información generada durante el proceso para permitir un detallado seguimiento del mismo desde su aprobación hasta la evaluación final y cierre. Aceptación de RFCs Al finalizar el registro de las RFCs, estas solicitudes son asignadas por el Gestor de cambios a la persona idónea para que evalué si son claras, ilógicas, prácticas o innecesarias. Si se considera que las solicitudes de cambio generadas no están justificadas son rechazadas, y el Gestor de cambios debe informar el estado de la RFC al departamento o persona que 58

59 la solicito con el objetivo de poder realizar reclamaciones a favor de dicha RFC o para que pueda ser consecuentemente modificada. Cabe aclarar que la aceptación del cambio por parte de la persona asignada por el Gestor de Cambio no implica su posterior aprobación por el CAB y es sólo indicación de que se ha encontrado justificado su procesamiento. Cuando la RFC es aceptada o rechazada la persona encargada de ello debe llevar a cabo las actualizaciones básicas que deben incluir el registro del estado actual de la solicitud y su fecha de aceptación o denegación. Clasificación de RFCs Tras la aceptación de la RFC, la solicitud es clasificada por la persona asignada especificando su prioridad, dependiendo de la categoría de urgencia e impacto de estas. Al asignar la prioridad se determinará la importancia que tiene un cambio frente a otras RFCs pendientes y este será el dato relevante para que el CAB establezca el calendario de cambios a realizar. Esta prioridad se determina mediante la matriz de impacto y urgencia desarrollada en la FASE 2 del proyecto (Ver Tabla 8), la cual establece prioridades dependiendo de las categorías de urgencia e impacto de las RFCs. Cuando una RFC se determine con prioridad Máxima (Valoración de 13 a 15) los cambios deben llevarse a cabo mediante el procedimiento de emergencia por lo tanto no se siguen los procedimientos establecidos para la administración de cambios ya que los recursos deben estar disponibles inmediatamente. Por lo tanto la administración del cambio se lleva a cabo por el CAB/EC. La determinación de la categoría se basa en dos puntos clave, los cuales son el impacto de los servicios y la urgencia de ejecución del cambio, la cual varía según responsabilidades de la persona u oficina solicitante. 59

60 Posteriormente las RFCs aceptadas y clasificadas deben ser enviadas al Gestor de Cambios quien es el encargado de suministrarlas en la próxima reunión del CAB y llevar a cabo las actualizaciones a la Base de Datos del conocimiento del proceso de la RFC. Aprobación y Planificación El CAB es el encargado de la aprobación y planificación de las RFCs presentadas, por lo tanto en las reuniones periódicas que se llevan a cabo para la Administración de los Cambios se debe diligenciar el formato establecido (Ver Error! No se encuentra el origen de la referencia.) en el cual se especifica el estado de la RFC junto con la planificación de cada cambio en la que se encuentran los recursos económicos y humanos, los plazos previstos para el cierre dependiendo de la clasificación del cambio. Además de ello, para la planificación de los cambios se debe realizar el Calendario de Cambios o el programa de Cambios Futuros (FSC) el cual contiene detalles de todos los cambios aprobados, este calendario es entendido gracias a las fechas previstas de inicio y cierre de las solicitudes aprobadas. La aprobación de los cambios suele constar de tres aspectos importantes los cuales son: a) la aprobación Financiera en la cual se realiza un análisis de costos-beneficios y presupuestos, b) la aprobación Técnica que realiza un estudio del impacto, la necesidad y viabilidad del cambio y, c) la aprobación del Negocio que se basa en la aprobación de los usuarios acerca de las funciones necesarias. Al finalizar las reuniones del CAB, el Gestor de Cambios debe actualizar la información de las RFC en la CMDB. Estas actualizaciones contienen principalmente las siguientes pautas. Evaluación preliminar del impacto de la implementación y la no implementación del cambio y de los costos necesarios. Impacto, urgencia y prioridad (Si estas fueron modificadas) 60

61 Recomendaciones del Gestor de Cambio. Fecha y Hora de la aprobación. Fecha estimada para la implementación del cambio Planes de Soporte Recursos asignados. Información sobre el constructor y quienes la ejecutan. Posteriormente se asigna la construcción, prueba e implementación del cambio a una persona o área específica de la organización. PROCEDIMIENTO DE EMERGENCIA Debido a la presencia de un cambio de emergencia el CAB/EC es el encargado de la aprobación y planificación de estas RFCs presentadas, por lo tanto se debe llevar a cabo una reunión con los integrantes de este comité; quienes llevaran a cabo la planificación de cada solicitud de cambio teniendo en cuenta los recursos económicos y humanos, los plazos previstos para el cierre. Las reuniones del CAB/EC deben realizarse en el menor tiempo posible, luego de realizar la planificación y ejecución del cambio, para el cambio realizado deben realizarse las respectivas evaluaciones de funcionamiento y satisfacción del cliente. Ejecución del Cambio En esta fase de desarrollo del cambio la persona o área asignada para la implementación debe monitorear el proceso para asegurar que el desarrollo de este concuerde con las especificaciones predeterminadas, y que los calendarios previstos y la asignación de recursos especificados inicialmente son los adecuados. Si el cambio aprobado incluye la modificación de la configuración de los dispositivos TI, a medida que se realiza la nueva configuración de los dispositivos se deben guardar los cambios realizados, especificando las 61

62 líneas modificadas, logrando así que se permita la rápida recuperación de la última configuración estable en caso de falla en el proceso de cambio, este proceso se realizara en remplazo de la copia total de la configuración inicial debido a que el manejo de múltiples cambios requeriría una alta capacidad de discos duros para lograr el almacenamiento de toda la información, esta opción de restauración del sistema se tomo de acuerdo a especificaciones del grupo de Administradores de Red. La ejecución del proceso de cambios esta subdivida en tres procesos que sirven para asegurar que la implementación del cambio se lleve a cabo correctamente y que sea posible realizar una valoración preliminar de los nuevos sistemas implementados en lo que respecta a su: Funcionalidad. Usabilidad. Accesibilidad. En el proceso de implementación es un deber del Gestor de Cambios y/o personal encargado del cambio mantener informados a los usuarios de los futuros cambios y dentro de lo posible hacerles participes del mismo escuchando sus sugerencias, comunicando las ventajas asociadas al cambio, aclarando sus dudas y dando soporte cuando ello sea necesario Las pruebas realizadas durante este proceso deben ser llevadas a cabo por el personal encargado del cambio observando si la calidad y disponibilidad del servicio son los adecuados luego de la nueva implementación. Evaluación La evaluación de los cambios se debe realizar antes del cierre comunicando a los usuarios de la nueva implementación y observando la satisfacción de ellos con el nuevo servicio, para valorar realmente el impacto del mismo en la calidad del servicio y en la productividad de la organización. 62

63 Esta evaluación debe realizarla el Gestor de Cambios que en ocasiones se puede apoyar con el trabajo de la Mesa de Ayuda, teniendo en cuenta los siguientes cuestionamientos: - El cambio produjo los objetivos necesarios? - Están satisfechos los usuarios con los resultados? - Se produjeron nuevos problemas o incidentes con la implementación del cambio? - Se excedieron los recursos económicos y humanos con el desarrollo del cambio? Cuando los cambios realizados han sido satisfactorios, la persona o grupo asignado para la ejecución del cambio ó el Gestor de Cambios deben proceder al cierre de la RFC, pero si por el contrario los cambios no han sido exitosos y las respuestas a las preguntas de evaluación no cumplen con las pautas esperadas, la RFC debe retornar al proceso donde surgió el problema, realizar el plan de restauración del sistema si aplica para volver a la configuración inicial ó volver a iniciar el proceso mediante una RFC nueva. Satisfacción de los Clientes Finalmente el Gestor de Cambios debe valorar la satisfacción de los clientes con el cambio generado; si se encuentra una satisfacción total en el nuevo servicio se procede a la actualización de la Base de Datos del cambio con los siguientes campos: Planes de Restauración del Sistema si aplican. Plan de implementación. Fecha y Hora real del cambio. Revisión post-implementación. Fecha de la Evaluación Final. 63

64 Resultados de la Evaluación final y problemas observados Razones por las que se rechazo o abandono el cambio (en caso que este no cumpla con sus objetivos de creación y se deba poner en marcha el plan de Restauración del Sistema). Fecha de cierre Si por el contrario los clientes no se encuentran satisfechos con el cambio el proceso es enviado nuevamente al CAB, donde se analizaran los fallos en la planeación del mismo y se buscara solución a este. Al finalizar el cumplimiento de los objetivos establecidos en el proyecto de grado a la oficina se hizo entrega de un documento para llevar a cabo la revisión final del cumplimiento de objetivos y proceder de esta manera a realizar las sensibilizaciones correspondientes al personal de la Oficina (Ver ANEXOS A.docx en (ANEXO A-6) Error! No se encuentra el origen de la referencia.) Socialización y entrega de documentación de los procesos realizados. Esta es la fase final del proyecto, donde se llevó a cabo la entrega de la documentación de los diferentes procesos y actividades desarrolladas durante las fases anteriores, en esta documentación se incluyen los aspectos relevantes y cada uno de los diferentes aportes que se obtuvieron con base en el modelo ITIL y a las sugerencias del personal; además se realizaron las sensibilizaciones para dar a conocer al personal de la Oficina de Telemática la evolución e importancia del mismo y su conclusión, en el ( ANEXOS A (ANEXO A-7)) se encuentra un oficio en el cual se observa el día y hora de la realización de las sensibilizaciones; y posteriormente en el ( ANEXOS A (ANEXO A-8)) se encuentra un acta de asistencia del personal de la oficina a las sensibilizaciones realizadas para dar a conocer el desarrollo del proyecto y la importancia de su implementación. 64

65 Durante esta fase se comprobó el desarrollo de las variables de ingeniería que se especificaron al inicio del proyecto, por ello esta fase es esencial ya que también brinda información del estudio de ingeniería. La primera variable a tomar en cuenta es el promedio de RFCs aceptadas en la Oficina de Telemática, esta variable de ingeniería depende de las solicitudes de cambio recibidas en Mesa de Ayuda en un lapso de tiempo y los casos en que estas solicitudes son lógicas, coherentes y viables para ser analizadas por el CAB, en caso de no presentar una prioridad Máxima. Es de gran importancia observar el número de casos de solicitudes de cambio aceptados para en un futuro tener una medición del rendimiento del CAB en la infraestructura tecnológica de la institución. Como la estructuración del CAB es relativamente nueva en la institución; el desarrollo de esta variable se basará en una medición que debe ser ejecutada trimestralmente. Para realizar esta medición fue necesario contar con la documentación del grupo de mesa de ayuda, ya que la compra del modulo de Cambios de la aplicación Service Manager se encuentra en proceso. En el mes de Septiembre cuando se realizó la medición, se obtuvieron los siguientes datos: = 73,33% 15 La última variable a tener en cuenta es el tiempo de solución de un cambio de emergencia, en este caso se toman las solicitudes de cambio urgentes generadas durante junio de 2008 hasta junio de 2009; en esta variable se tuvo en cuenta aquellos cambios que generaron una interrupción de alto impacto en el servicio. 4H + 6H + 7H H H 5 = 5,74 HORAS 65

66 Como se puede observar un cambio de emergencia tarda 5.74 horas desde el momento en que es registrado por el grupo de Mesa de Ayuda hasta su posterior cierre, este estimativo se obtiene gracias a la documentación suministrada por Mesa de ayuda en la cual se observa el tiempo total en el que un caso está abierto, la medida se obtiene de sumar los tiempos de solución de cambios de emergencia en un año y dividirlos por el total de cambios elevados en ese lapso de tiempo. Cabe aclarar que en muchos casos los tiempos son mayores a la realidad, ya que para llevar a cabo el cierre del caso el operario debe dirigirse a la Oficina de Telemática, por ello se hace un estimativo de 3.30 horas para la solución de estos. Al observar en la matriz de asignación de prioridades y tiempos para la ejecución de los cambios se puede deducir que actualmente el personal encargado de los cambios está tardando 1.30 horas más de lo previsto, lo cual afecta en gran parte la calidad de los servicios y satisfacción de los usuarios. 66

67 4. PRUEBAS Y RESULTADOS En este capítulo se detallan las pruebas que se realizaron en el desarrollo del proyecto y se especifican cuales son los resultados obtenidos dentro de la institución PRUEBAS La evolución del proyecto se basa en avances que sean reconocidos por la institución, es por esto que dichos avances deben ser medidos y explicados para observar y detallar el nivel de importancia tanto de la prueba como del proyecto Ejemplos de Aplicación de la Metodología a casos reales en la OFITE. La creación de la metodología estándar cambios en la Oficina de Telemática establece un proceso que se debe seguir para asegurar una correcta administración de estos, por ello mediante tres casos reales se demostró su importancia y utilidad Encuesta Inicial del Nivel de Conocimiento del Personal de la OFITE con la Gestión de Cambios. La encuesta de Nivel de Conocimiento del Personal de la OFITE con la Gestión de Cambios se desarrolló al iniciar el proyecto con el fin de conocer la forma en que se llevaba a cabo los cambios en la oficina, el personal encargado de la recepción de las solicitudes, los tiempos de solución de los cambios de urgencia, entre otras características de gran importancia para el desarrollo del proyecto. La plantilla de esta encuesta se puede observar en el ANEXO B-2 en ANEXOS B Encuesta Final del Nivel de Conocimiento del Personal OFITE con la Gestión de Cambios. Al finalizar el proyecto se llevo a cabo una encuesta del Nivel de Conocimiento del Personal de la OFITE con la Gestión de Cambios; con el 67

68 fin de confirmar la implementación del proyecto en la institución y el conocimiento del personal después de realizadas las sensibilizaciones. La plantilla de esta encuesta se puede observar en el ANEXO B-3 en ANEXOS B Sensibilizaciones. La parte de sensibilizaciones se desarrollo de acuerdo a un cronograma especifico tratando de impartir conocimientos de gestión de TI no solo al grupo de soporte si no a los diferentes grupos de la Oficina de Telemática, dando a conocer el desarrollo del proyecto, la importancia y sobre todo los beneficios concretados y futuros para la institución. La sensibilización de la metodología quedo de la siguiente manera: o Introducción al modelo ITIL y la Gestión de Cambios. En la primera parte de la sensibilización se dio a conocer la importancia del modelo, sus objetivos, beneficios, las diferentes librerías existentes para la administración de las tecnologías de la información, así como la importancia de una correcta metodología para la administración de los cambios. o Clasificación de las solicitudes de cambio y Consejo Asesor de Cambios. Luego de realizar la introducción se dio a conocer el desarrollo del proyecto, se dio a conocer al personal de la oficina las matrices de clasificación de las solicitudes de cambios, explicando mediante diferentes ejemplos su uso y dando a conocer su importancia para la correcta administración de los cambios. Por otro lado se explico de manera global la importancia del Consejo asesor de Cambios, sus funciones y estructura orgánica. o Metodología y formato estándar para la gestión de Cambios 68

69 Finalmente se explico la metodología estándar desarrollada para garantizar una correcta y eficaz administración de los cambios, así como la importancia del formato establecido para la normalización de las solicitudes de cambios RESULTADOS Ejemplos de Aplicación de la Metodología a casos reales en la OFITE. Para demostrar la importancia de la metodología desarrollada para una correcta administración de los cambios se crearon ejemplos de aplicación en los cuales se diligenció el formato gestor de cambios en cada uno de sus campos con los datos que se tenían en las bases de datos de la oficina de algunas implementaciones realizadas hace algunos años; posteriormente se aplicó totalmente la metodología a uno de los ejemplos demostrando la importancia de un proceso estándar para la aceptación, clasificación, aprobación, ejecución y evaluación de cada uno de los cambios generados en la Oficina de Telemática de la Policía Nacional. Tabla 12 Aplicación de la Metodología a Casos reales CASO DESCRPCIÓN 1 Adquisición De Herramientas De Usuario Final (Software Generación De Reportes Estadísticos), ver (ANEXOS A en (ANEXO A-12) 2 Mantenimiento UPS a Nivel Nacional, ver (ANEXOS A en ANEXO A-13) 3 Adquisición de elementos (ANTENAS) con destino a la Oficina de Telemática de la Policía Nacional, ver ( ANEXOS A en ANEXO A- 14) 69

70 Encuesta Inicial del Nivel de Conocimiento del Personal de la OFITE con la Gestión de Cambios. La encuesta inicial del nivel de conocimiento del personal de la Oficina de Telemática con la gestión de cambios se llevó a cabo para tener un punto de partida y así poder hacer una comparación con algunos procesos del modelo que establezcan durante el desarrollo del proyecto, en el se encuentra la ficha técnica de la encuesta realizada. La encuesta fue realizada a parte del personal de la oficina, entre los cuales se encuentran: Tabla 13 Personal Encuestado Distribución Grupo Administración de Software y Centro de Computo Grupo Administración de la Infraestructura Telemática Personal 9 14 Grupo Calidad de la Información 3 Grupo Seguridad de la información 7 Grupo Proyección e implementación de Infraestructura Telemática 4 Grupo Ciclo de Vida de la Información 8 Grupo Soporte y Apoyo Administrativo 5 TOTAL 50 70

71 o Por qué Motivos se realiza actualmente una solicitud de cambios? Es importante conocer las causas más frecuentes por las cuales son generadas las solicitudes de cambio en la oficina para así tener un estimativo general de los cambios que se llevan a cabo en su infraestructura tecnológica. Tabla 14 Tabulación respuestas motivos de las RFCs Motivos de RFCs Personas Problemas Repetitivos 14 Insatisfacción de los usuarios 6 Planes de mejoramiento de Calidad 14 Requisitos de Seguridad ó Licencias 6 Abastecedores 4 Otros 6 TOTAL 50 Figura 11 Motivos de generación de una RFC Motivos de Generación de una RFC Problemas Repetitios= 28% 12% 8% 12% 28% 28% 12% Insatisfacción de los Usuarios=12% Planes de Mejoramiento de Calidad=28% Requisitos de Seguridad ó Licencias=12% Abastecedores=8% Otros=12% o Quién se encarga de la recepción de solicitudes de Cambio? 71

72 Una correcta administración de cambios está basada en un proceso que inicia desde el registro de las RFCs hasta la ejecución y cierre de estas, es por esto que es de suma importancia conocer quiénes son los encargados de la recepción de RFCs en la oficina; ya que durante el desarrollo del proyecto se establecerá quiénes son los grupos, áreas ó personas encargadas de llevar a cabo el registro de las RFCs para dar inicio al proceso de cambios. Tabla 15 Tabulación Respuestas Personal encargado del registro de RFCs Personal para el registro de RFCs Personas Administradores de Red 6 Personal Soporte Técnico 20 Mesa de Ayuda 12 Personal de Calidad de la Información 12 TOTAL 50 Figura 12 Personal encargado de la Recepción de RFCs Personal Encargo de la Recepción de RFCs 24% 24% 12% 40% Administradores de Red=12% Personal Soporte Tecnico=40% Mesa de Ayuda=24% Personal Calidad de la Información=24% o Actualmente como se realizan las solicitudes de cambio? Existen diferentes formas de realizar las solicitudes de cambio en una empresa y es dependiendo de las políticas y necesidades de esta que 72

73 se establece el mejor método para la recepción de las diferentes RFCs generadas. Tabla 16 Tabulación respuestas método de recepción de RFCs Método Actual para las RFCs Personas Vía telefónica 12 Formato de Solicitudes 8 Personalmente 16 Correo Electrónico 14 TOTAL 50 Figura 13 Métodos de Recepción de RFCS Metodo de Recepción de RFC'S 28% 32% 24% 16% Vía Telefoníca=24% Formato de solicitudes=16% Personalmente=32% Correo Electronico=28% o Sabe algo acerca del Consejo Asesor de Cambios? El Consejo Asesor de Cambios es el cuerpo principal de la gestión de cambios y es de suma importancia saber el nivel de conocimiento del personal de la oficina respecto a este grupo, ya que uno de los principales objetivos del proyecto de pasantía es establecer el trabajo y funciones de él. 73

74 Tabla 17 Tabulación respuestas Conocimiento del Consejo Asesor de Cambios Conocimiento del Consejo Asesor de Personas Cambios Si 6 No 44 TOTAL 50 Figura 14 Conocimiento del Consejo Asesor de Cambios Conoce acerca del Consejo Asesor de Cambios? 12% 88% Si=12% No=88% o Conoce algún formato para la Solicitud de Cambios? Un formato de solicitudes de cambio es un estándar que debe ser establecido en las empresas para llevar a cabo la recepción de las solicitudes de cambio de manera coordinada, logrando así un control de los cambios realizados. 74

75 Tabla 18 Tabulación respuestas Formato de Solicitudes de Cambio Conocimiento Formato de Solicitudes de Cambio Personas Si 4 No 46 TOTAL 50 Figura 15 Conocimiento del Formato de Solicitudes de Cambio Conocimiento del Formato Estandar para las RFCs 8% 92% Si=8% No=92% o Cuánto tiempo tarda en solucionarse una petición de cambio de emergencia? Como tal el tiempo de solución de un caso o reporte esta dado por la dificultad del mismo, aunque en el caso de solicitudes de cambio que son consideradas urgentes se esperan tiempos de solución de los casos muy pequeños, ya que se trata de problemas que están afectando seriamente los procesos misionales de la oficina. 75

76 Figura 16 Tabulación Respuestas Tiempo de Solución de los Cambios de Emergencia Tiempo de Solución de RFCs de Personas emergencia De 0 a 4 Horas 12 De 4 a 8 Horas 18 De 1 a 3 Días 8 Una semana 6 Meses 6 TOTAL 50 Figura 17 Tiempo de Solución de una RFC de Emergencia Tiempo de Solución de una RFC de emergencia 12% 12% 24% De 0 a 4 Horas=24% 16% 36% De 4 a 8 Horas=36% De 1 a 3 Dias=16% Una semana=12% Meses=12% Encuesta Final del Nivel de Conocimiento del Personal de la OFITE con la Gestión de Cambios La encuesta Final del nivel de conocimiento del personal de la Oficina de Telemática con la gestión de cambios se llevó a cabo para medir la utilización de la gestión de cambios después de finalizar el proyecto y. La encuesta fue realizada al siguiente personal de la oficina: 76