Antes de imprimir este documento piense en el medio ambiente!

Transcripción

1 Versión 5.0 Página 1 de 8 1. OBJETIVO Estandarizar los métodos y procedimientos que nos permitan dar un trámite eficaz y eficiente a los cambios de emergencia con el fin de reducir al mínimo el impacto sobre el servicio ante cualquier incidente presentado, garantizando el mejoramiento día a día en la prestación de los servicios TI. 2. ALCANCE Inicia con la recepción y verificación de la solicitud de Cambios de emergencia realizada por el solicitante y termina con el informe de cierre del ticket al Solicitante del Cambio. Este procedimiento aplica a nivel Nacional. 3. DESCRIPCIÓN DE ACTIVIDADES No Actividad Responsable Registro Inicio 1 Remitir el Formato Requerimiento de Cambio a MIS (mis@icbf.gov.co) con copia a Comité Cambios de Emergencia (cce@icbf.gov.co). Solo se aceptan solicitudes hechas por el Líder SRT que avala el cambio. Correo electrónico / Telefónico 2 3 Adicional al envío de la solicitud por correo electrónico es necesario contactar telefónicamente al Gestor de Cambios del. Recibir el requerimiento de cambio de emergencia autorizado por ICBF, verificar que la solicitud cuente con la información mínima necesaria (descrita en el numeral anterior). Realizar el registro de la solicitud de cambio de emergencia en la herramienta de gestión, una vez hecho esto asignar la categoría acorde a la solicitud de cambios. Evaluar la solicitud de cambio de emergencia y aceptarlo o rechazarlo de acuerdo a los siguientes criterios: Completitud del Formato Requerimiento de Cambio F01.PR03.PA04 (Cuando aplique) Que no sea un cambio estándar o un cambio normal. Contratista / Profesional Universitario de la Subdirección de Recursos Tecnológicos Agente Mesa de Servicio F01.PR03.PA04 Registro de la solicitud y categorización Aceptación o rechazo la solicitud F01.PR03.PA04

2 Versión 5.0 Página 2 de 8 4 Revisar si a solicitud de cambio de emergencia cumple con las condiciones mínimas para evaluarlo Si: Asignar el número consecutivo del RFC, se solicita aprobación por correo electrónico de los miembros del Comité de Cambios de Emergencia CCE. No: Informar la no aceptación de la Solicitud de Cambio de Emergencia al solicitante y líder SRT que avala el cambio y pasar a la actividad 9. Analizar la solicitud de cambio (RFC), garantizando su viabilidad para ejecutarlo. Asignación consecutivo y gestión aprobación 5 P.C 6 7 Es Viable RFC de Emergencia? Sí: Se tiene aprobación de por lo menos 2 de los miembros del Comité de Cambios de Emergencia CCE. Las aprobaciones deben hacerse por escrito, vía correo electrónico. No: Informar la no aprobación de la Solicitud de Cambio de Emergencia al solicitante y líder SRT que avala el cambio. Se cierra el tiquete en la y pasar a la actividad 9. Informar al Solicitante y Ejecutor la aprobación del cambio de emergencia para que procedan con su ejecución. Verificar, analizar y ejecutar las actividades definidas para que el cambio de emergencia se lleve a cabo a satisfacción. Posterior a la ejecución se debe realizar la verificación funcional (PIR) por la persona indicada en el formato de solicitud de cambio. Cambio Satisfactorio? Sí: Notificar al Solicitante del Cambio y al Comité de Cambios de Emergencia CCE. Continuar con la actividad 9 Comité Cambios de Emergencia CCE / Ejecutor del Cambio / Gestor de Cambios Operador TI Registro de la aprobación o rechazo del cambio. Correo Electrónico / Gestión Gestión / Correo Electrónico Registro de resultados de ejecución del cambio. Gestión / Correo Electrónico No: Ejecutar actividades definidas para Rollback (Si aplica) pasa a la actividad 8.

3 Versión 5.0 Página 3 de 8 Revisar si la ejecución de RollBack fue Exitosa 8 Si: Solicitar un diagnóstico a los administradores del servicio e involucrados en la elaboración del control de cambio, para que se informe la causa raíz de la falla en la ejecución del cambio. Dicha respuesta se debe entregar al gestor de cambios del Operador de TI y al líder de la SRT quienes darán su aval de que el diagnóstico es correcto. Cuando se cuente con el aval el gestor de cambios enviará la información al gestor del conocimiento del operador de TI para que se registre como error conocido. / Gestor de Problemas / Líder de la SRT Registro de resultados de ejecución de RollBack 9 Nota: P.C. Punto de Control 4. CRITERIOS OPERATIVOS ACTIVIDAD 1 No: Se debe escalar al gestor de problemas para que inicie la investigación de la causa raíz de la falla del cambio y su respectiva investigación se alimente posteriormente como error conocido. Diligenciar y adjuntar a la herramienta de gestión el Formato Requerimiento de Cambio F01.PR03.PA04, el cual deberá formalizarse a más tardar el siguiente día hábil después de realizada la solicitud. 10 Cierre del Ticket en la herramienta de gestión Operador T F01.PR03.PA04 Se debe tener en cuenta que para los cambios de emergencia es necesario que se envíe como mínimo la siguiente información por correo electrónico a mis@icbf.gov.co y cce@icbf.gov.co. o Líder de de la SRT o Nombre del Solicitante o Nombre del Cambio o Alcance del Cambio o Actividades del cambio incluyendo Rollback (si aplica)

4 Versión 5.0 Página 4 de 8 ACTIVIDAD 2 Para la verificación de la se debe tener en cuenta que: o En caso de que la solicitud de cambio de emergencia se realice a través del Formato Requerimiento de Cambio F01.PR03.PA04, relacionar el CI al tiquete de cambio. o Los criterios que se tienen en cuenta para la aceptación de un control de cambios de emergencia son: Debe solucionar cualquier interrupción que se presente en un servicio de alto impacto (afectación masiva, proceso misional, pérdida financiera) Evitar un incumplimiento contractual Que no sea un cambio estándar o un cambio normal Dar cumplimiento a normatividad legal NO deben ser cambios para dar cumplimiento a metas, objetivos ni compromisos adquiridos con otras dependencias. ACTIVIDAD 3 Para la ejecución de la los cambios de emergencia deben cumplir los siguientes criterios: o Se debe solucionar cualquier interrupción que se presente en un servicio de alto impacto (afectación masiva, proceso misional, pérdida financiera) o Evitar un incumplimiento contractual o Dar cumplimiento a normatividad legal o NO deben ser cambios para dar cumplimiento a metas, objetivos ni compromisos adquiridos con otras dependencias. Adicionalmente en caso de que la solicitud inicial cuente con Formato Requerimiento de Cambio F01.PR03.PA04, verificar y agregar de ser necesario el tipo de cambio. ACTIVIDAD 9 En la ejecución de esta actividad el gestor de cambios del Operador de TI, deberá adjuntar las aprobaciones de los miembros del comité en la herramienta de Gestión; a más tardar 2 días hábiles después de la solicitud del cambio. En caso de que el solicitante del cambio y líder SRT, reciban observaciones por parte del gestor de cambios del Operador de TI, deben registrarse en la Gestión a más tardar el siguiente día hábil después de la ejecución del cambio. Si no se ha relacionado CI al tiquete de cambio se notificará al gestor de la configuración para que se verifique si se actualiza o no la CMDB con el cambio de emergencia. 5. DURACIÓN DEL CICLO DEL PROCEDIMIENTO (DÍAS): Un (1) día

5 Versión 5.0 Página 5 de 8 6. PRODUCTO Cambio de emergencia aprobado y ejecutado en ambientes de producción. 7. DEFINICIONES: Cambio Estándar: Relaciona todos aquellos cambios, de riesgo conocido y de procedimiento documentado que no necesitan de un formato (RFC) para detallar el cambio, debido a que su implementación tiene un impacto bajo para la operación. Por ello a este tipo de cambios se les asigna una prioridad baja. Estos son cambios pre-aprobados como gestión de usuarios en el Directorio Activo (creación, modificación, activación, deshabilitación), modificaciones en Grupos de Seguridad Informática, asignación de PC nuevos, instalación de Licencias, entre otros. Son mantenimientos que no generen indisponibilidad de servicios, procedimientos repetitivos, administración. Cambio No estándar: Adición, modificación o eliminación de algo que podría afectar a los de TI. El Alcance debería incluir todos los de TI, Elementos de Configuración, Procesos, Documentación entre otros, los cuales pueden generar indisponibilidad por lo que deben ser evaluados por un comité experto o CCC. Entre ellos están los que dan solución a errores conocidos, Mejoras sobre soluciones, Nuevos productos (HW/SW), bajas de productos o soluciones, imperativo legal y obligaciones contractuales. Cambio de Emergencia: Son cambios que deben implementarse de manera inmediata y son requeridos para solucionar o prevenir incidentes de alto impacto en los de TI, los procesos Institucionales o en situaciones que afectan negativamente la imagen de ICBF, su aprobación se realiza por un CCE. Comité de Cambios de Emergencia (CCE): Esta actividad consiste en convocar de manera inmediata al comité de emergencia por el solicitante del cambio o el líder de servicios el comité está conformado por: Gerente Proyecto y Operaciones del ICBF (Con voz y voto) Coordinador de Operaciones UT (Con voz y voto) Líder de desarrollo SSII (Con voz y voto) Gestor de Cambio de la UT (Con voz) Por la urgencia del cambio no se realizarán memorias de la reunión ya que posiblemente sea una teleconferencia o una conferencia en Lync. Los soportes serán adjuntados al cambio en la Gestión. CI: elementos de configuración, que se encuentran registrados en la CMDB. Cambios de Tecnologías de la Información: Procedimiento responsable del control del Ciclo de Vida de los Cambios. Su objetivo primario es permitir la ejecución de los Cambios a realizar, con la mínima afectación sobre los de TI.

6 Versión 5.0 Página 6 de 8 Incidentes de Tecnologías de la Información: Es el procedimiento responsable del manejo del ciclo de vida de todos los incidentes. Requerimientos de Tecnologías de la Información: Procedimiento responsable del control del Ciclo de Vida de todos los cambios estándar. CMDB (Configuration Management Data base) Base de Datos de Configuraciones: Es una base de datos que contiene detalles relevantes de cada CI (ítem / elemento de configuración) y sus relaciones. Algunos de los ítems de configuraciones son el equipo físico, software, usuarios, equipos de comunicaciones entre otros. De igual manera la CMDB guarda la relación entre incidencias, problemas, cambios y otros datos de los servicios de TI. Adicionalmente se debe tener en cuenta que cada elemento almacenado en la CMDB es un CI, Configuration Item, sobre el cual se guarda información sobre sus atributos y relaciones. : Son todos los sistemas, aplicaciones, controles, soluciones de cálculo, metodología, etc., que ayudan a la gestión de una empresa; para el caso de TI para el manejo y control de servicios es el software en donde se documentan los servicios de gestión tecnológica como Incidentes, Requerimientos, Problemas, Controles de Cambios, etc, todas estas correspondientes a Tecnologías de Información; algunas de las Herramientas que se encuentran hoy en día en el mercado son: Altiris de Symantec IBM Service Management de IBM CA Service Desk Manager de CA Technologies Service Manager de Hewlett Packard Aranda's Service Desk de Aranda Software BMC Remedy Mesa de Servicio: Constituye el único punto de contacto con los usuarios finales para registrar, comunicar, atender y analizar todas las llamadas, incidentes reportados, requerimientos de servicio y solicitudes de información. Es a través de la gestión proactiva de la Mesa de que la Dirección de Información de Tecnología se informa de las necesidades que tienen los funcionarios en cuanto a los recursos informáticos a nivel nacional. Tecnologías de la Información (TI): Las tecnologías de la información y las Comunicaciones (TIC o TICs), Nuevas Tecnologías de la Información y de la Comunicación (NTIC), agrupan los elementos y las técnicas utilizadas en el tratamiento y la transmisión de las informaciones, principalmente de informática, internet y telecomunicaciones. Ticket /Número de Servicio: Número consecutivo suministrado por una Gestión durante el reporte de una Solicitud de Servicio, para facilitar a través del mismo el seguimiento y control. 8. DOCUMENTOS DE REFERENCIA No Aplica.

7 Versión 5.0 Página 7 de 8 9. RELACIÓN DE FORMATOS F01.PR03.PA04 Formato Requerimiento de Cambio 10. ANEXOS No Aplica. 11. NATURALEZA DE LOS CAMBIOS: Ítem Modif. Nombre del ítem Descripción del Cambio Se modifica la actividad 1 adicionando la Nota 1, y se elimina el párrafo antes de diligenciar el formato, el cual deberá formalizarse a más tardar el siguiente día hábil después de su solicitud. 3 Descripción de actividades Se modifica la actividad 2, dado a que el requerimiento de cambio de emergencia con frecuencia es solicitado a través de correo electrónico por medio de una documentación mínima establecida. Mientras que el formato establecido se documenta al finalizar la ejecución del cambio o cuando el cambio es rechazado. Además se incluye, en el registro del cambio la relación de los elementos de configuración (CIs) afectados durante el mismo, para los casos en que el requerimiento es solicitado a través del formato. Se elimina de la actividad 3 el párrafo que hace mención al registro de observaciones en la herramienta de gestión, puesto que todas las acciones de documentación se contemplan en la actividad 9. Se elimina de la actividad 4 la acción de registro de aprobaciones en la herramienta de gestión, puesto que está contemplada en la actividad 9. Se crea actividad 8 con el análisis, el registro y la documentación de las causas raíces de las fallas procedentes de la ejecución de los cambios y su roll back en la base de datos de conocimiento de TI. También se crea la actividad 9, donde se recopila

8 Versión 5.0 Página 8 de 8 4 Criterios operativos 7 Definiciones toda la información para documentar y proceder con el cierre en la herramienta. Se registran los criterios operativos a tener en cuenta para la ejecución de las actividades 1, 2, 3 y 9. Se adicionó la definición de CI y se eliminaron las definiciones de incidente e ITIL.