miércoles, 17 de febrero de 2016
Gestión de Problemas.
Visión
General
La
Gestión de Problemas puede ser:
- Reactiva: Analiza los incidentes ocurridos para
descubrir su causa y propone soluciones a los mismos.
- Proactiva: Monitoriza la calidad de la
infraestructura TI y analiza su configuración con el objetivo de prevenir
incidentes incluso antes de que estos ocurran.
Objetivos
Entre la funciones principales de la Gestión de Problemas figuran:
- Identificar, registrar y clasificar los problemas.
- Dar soporte a la Gestión de Incidentes proporcionando información y soluciones temporales o parches.
- Analizar y determinar las causas de los problemas y proponer soluciones.
- Elevar RFCs (Petición de cambio) a la Gestión de Cambios para llevar a cabo los cambios necesarios en la infraestructura TI.
- Realizar un seguimiento post-implementación de todos los cambios para asegurar su correcto funcionamiento.
- Realizar informes que documenten no sólo los orígenes y soluciones a un problema sino que también sirvan de soporte a la estructura TI en su conjunto.
- Analizar tendencias para prevenir incidentes potenciales.
Los principales beneficios de una correcta Gestión de Problemas:
- Un aumento de la calidad general de los servicios TI.
- Se minimiza el número de incidentes.
- Los incidentes se solucionan más rápidamente y, generalmente, en la primera línea de soporte TI ahorrando recursos e innecesarios escalados.
- La documentación desarrollada es de gran utilidad para la Gestión de la Capacidad, Disponibilidad y Niveles de Servicio.
Las principales dificultades a la hora de implementar la Gestión de Problemas se resumen en:
- Establecer una estrecha colaboración entre la Gestión de Incidentes y la de Problemas. Sin ésta la Gestión de Incidentes no dispondrá de toda la información necesaria para la rápida solución de los incidentes y la Gestión de Problemas carecerá de la información necesaria para determinar, clasificar y resolver los problemas.
- Mantener actualizadas las bases de datos asociadas requiere un compromiso por parte de todos los agentes implicados que frecuentemente requiere un seguimiento cercano de los responsables de la infraestructura TI.
- Aumento de los costes por la contratación de personal especializado, aunque estos se vean sobradamente compensados por los beneficios derivados.
Proceso
Las principales actividades de la Gestión de Problemas son:
- Control de Problemas: se encarga de registrar y clasificar los problemas para determinar sus causas y convertirlos en errores conocidos.
- Control de Errores: registra los errores conocidos y propone soluciones a los mismos mediante RFC (Petición de cambio) que son enviadas a la Gestión de Cambios. Asimismo efectúa la Revisión Post Implementación de los mismos en estrecha colaboración con la Gestión de Cambios.
Y cuando la estructura de la organización lo permite, desarrollar una Gestión de Problemas Proactiva que ayude a detectar problemas incluso antes de que estos se manifiesten provocando un deterioro en la calidad del servicio.
Muestra los procesos implicados en la correcta Gestión de Problemas.
Proceso - Control de Problemas
El
principal objetivo del Control de Problemas es conseguir que estos se
conviertan en Errores Conocidos para que el Control de Errores
pueda proponer las soluciones correspondientes.
El Control de Problemas se compone en esencia de tres fases:
1. Identificación y Registro
Una de las tareas principales de la Gestión de Problemas es identificar los mismos. Las principales fuentes de información utilizadas son:
- La base de datos de Incidentes: en principio cualquier incidente del que no se conocen sus causas y que se ha cerrado mediante algún tipo de solución temporal es potencialmente un problema. Sin embargo, se habrá de analizar si este incidente es aislado o su impacto en la estructura TI antes de elevarlo a la categoría de problema.
- Análisis de la infraestructura TI: en colaboración con la Gestión de Disponibilidad y de Capacidad, la Gestión de Problemas debe analizar los diferentes procesos y determinar en que aspectos se debe reforzar los sistemas y estructuras TI para evitar futuros problemas.
- Deterioro de los Niveles de Servicio: el descenso del rendimiento puede ser una indicación de la existencia de problemas subyacentes que no se hayan manifestado de forma explicita como incidentes.
Todas las áreas de la infraestructura TI deben colaborar con la Gestión de Problemas para identificar problemas reales y potenciales informando a ésta de cualquier síntoma que pueda ser señal de un deterioro en el servicio TI.
El registro de problemas es, en principio, similar al de los incidentes aunque el énfasis debe hacerse no en los detalles específicos de los incidentes asociados sino más bien en su naturaleza y posible impacto.
El registro debe incorporar, entre otra, información sobre:
- Los CIs (Elementos de configuración) implicados.
- Causas del problema.
- Síntomas asociados.
- Soluciones temporales.
- Servicios involucrados.
- Niveles de prioridad, urgencia e impacto.
- Estado: activo, error conocido, cerrado.
2. Clasificación y Asignación de Recursos
La clasificación del problema engloba desde las características generales de éste, tales como si es un problema de hardware o software, que áreas funcionales se ven afectadas y detalles sobre los diferentes elementos de configuración CIs (Elementos de configuración) involucrados en el mismo.
Un factor esencial es la determinación de la prioridad del problema, que al igual que en el caso de los incidentes, se determina tanto a partir de la urgencia (demora aceptable para la solución del problema) como de su impacto (grado de deterioro de la calidad del servicio).
Al igual que en la Gestión de Incidentes la prioridad puede cambiar en el curso del ciclo de vida del problema, por ejemplo, si se encuentra una solución temporal al mismo que reduce considerablemente su impacto.
Una vez clasificado y determinada su prioridad se deben de asignar los recursos necesarios para su solución. Estos recursos deben ser suficientes para asegurar que los problemas asociados son tratados eficazmente y así minimizar su impacto en la infraestructura TI.
3. Análisis y Diagnóstico: Error conocido
Los objetivos principales del proceso de análisis son:
- Determinar las causas del problema.
- Proporcionar soluciones temporales a la Gestión de Incidentes para minimizar el impacto del problema hasta que se implemente los cambios necesarios que lo resuelvan definitivamente.
Es esencial tener en cuenta que no siempre el origen del problema es un error de hardware o software. Es moneda frecuente que el problema este causado por:
- Errores de procedimiento.
- Documentación incorrecta.
- Falta de coordinación entre diferentes áreas.
Es también posible que la causa del problema sea un "bug" bien conocido de alguno de las aplicaciones utilizadas. Por lo tanto es conveniente establecer contacto directo con el entorno de desarrollo, en caso de aplicaciones desarrolladas "en la casa", o investigar en Internet información sobre errores conocidos aplicables al problema en cuestión.
Una vez determinadas las causas del problema éste se convierte en un Error Conocido y se remite al Control de Errores para su posterior procesamiento.
Proceso - Control de Errores
Una vez que el Control de Problemas ha determinado las causas de un problema es responsabilidad del Control de Errores el registro del mismo como error conocido.
Identificación y Registro de errores
El registro de los errores conocidos es de vital importancia para la Gestión de Incidentes pues debe llevar asociado, siempre que esto sea posible, algún tipo de solución temporal que permita minimizar el impacto de los incidentes asociados.
Análisis y Solución
Se deben investigar diferentes soluciones para el error evaluando en cada momento:
- El posible impacto de las mismas en la infraestructura TI.
- Los costes asociados.
- Sus consecuencias sobre los SLAs (Acuerdo de nivel de servicio).
En algunos casos, en los que el impacto del problema puede tener consecuencias graves en la calidad del servicio, pueden emitirse una RFCs (Petición de cambio) de emergencia para su procesamiento urgente por la Gestión de Cambios.
Una vez determinada la solución óptima al problema y antes de elevar una RFCs (Petición de cambio) a la Gestión de Cambios han de tenerse en cuenta las siguientes consideraciones:
- ¿Es conveniente demorar la solución? Ya sea porque se prevén cambios significativos en la infraestructura TI a corto plazo o por el escaso impacto del problema en cuestión.
- ¿Es la solución temporal aportada suficiente para mantener unos niveles de calidad de servicios aceptable?
- ¿Los beneficios justifican los costes asociados?
Sea cual sea la respuesta, todo la información sobre el error y su solución se registrará en las bases de datos asociadas. En el caso en el que se considere que el problema necesita ser solucionado se emitirá unaRFCs (Petición de cambio). Será responsabilidad de la Gestión de Cambios la implementación de los cambios de infraestructura propuestos.
Revisión Post Implementación y Cierre
Antes de dar el problema por resuelto y cambiar su estado a “cerrado” se debe analizar el resultado de la implementación de la RFCs (Petición de cambio) elevado a la Gestión de Cambios PIR (Revisión Post Implementación).
Si los resultados de esta PIR (Revisión Post Implementación) son los deseados y se pueden cerrar todos los incidentes relacionados con este problema se considera concluido el proceso y se emiten los informes correspondientes.
Control del Proceso
El objetivo de la Gestión de Problemas no es otro que el de mejorar el funcionamiento de la infraestructura TI y para evaluar su eficacia es imprescindible realizar un continuo seguimiento de los procesos relacionados y evaluar su rendimiento.
En particular una buena gestión de problemas debe traducirse en una:
- Disminución del número de incidentes y una más rápida resolución de los mismos.
- Mayor eficacia en la resolución de problemas.
- Gestión proactiva que permita identificar problemas potenciales antes de que estos se manifiesten o provoquen una seria degradación de la calidad del servicio.
La correcta elaboración de informes permite evaluar el rendimiento de la Gestión de Problemas y aporta información de vital importancia a otras áreas de la infraestructura TI.
Entre la documentación generada cabría destacar:
- Informes de Rendimiento de la Gestión de Problemas: donde se detalle el número de errores resueltos, la eficacia de las soluciones propuestas, los tiempos de respuesta y el impacto en la Gestión de Incidentes.
- Informes de Gestión Proactiva: donde se especifiquen las acciones ejercidas para la prevención de nuevos problemas y los resultados de los análisis realizados sobre la adecuación de las estructuras TI a las necesidades de la empresa.
- Informes de Calidad de Productos y Servicios: donde se evalúe el impacto en la calidad del servicio de los productos y servicios contratados y que eventualmente puedan permitir adoptar decisiones informadas sobre cambios de proveedores, etc.
Una eficaz Gestión de Problemas también requiere determinar claramente quienes son los responsables de cada proceso. Sin embargo, en pequeñas organizaciones es recomendable no segmentar en exceso las responsabilidades para evitar los costes asociados: sería poco eficaz y contraproducente asignar unos recursos humanos desproporcionados al proceso de identificación y solución de problemas.
Gestión de Incidentes.
Visión General
La Gestión de Incidentes tiene como objetivo resolver cualquier incidente que cause una interrupción en el servicio de la manera más rápida y eficaz posible.
La Gestión de Incidentes no debe confundirse con la Gestión de Problemas, pues a diferencia de esta última, no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el servicio. Sin embargo, es obvio, que existe una fuerte interrelación entre ambas.
Objetivos
Los objetivos principales de la Gestión de Incidentes son:- Detectar cualquiera alteración en los servicios TI.
- Registrar y clasificar estas alteraciones.
- Asignar el personal encargado de restaurar el servicio según se define en el SLA(Acuerdo de nivel de servicio) correspondiente.
Según el libro de Soporte del Servicio de ITIL® un incidente es:
“Cualquier evento que no forma parte de la operación estándar de un servicio y que causa, o puede causar, una interrupción o una reducción de calidad del mismo”.
Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como un incidente, lo que incluye a las Peticiones de Servicio tales como concesión de nuevas licencias, cambio de información de acceso, etc. siempre que estos servicios se consideren estándar.
Cualquier cambio que requiera una modificación de la infraestructura no se considera un servicio estándar y requiere el inicio de una RFC (Petición de Cambio) que debe ser tratada según los principios de la Gestión de Cambios.
- Mejorar la productividad de los usuarios.
- Cumplimiento de los niveles de servicio acordados en el SLA(Acuerdo de nivel de servicios).
- Mayor control de los procesos y monitorización del servicio.
- Optimización de los recursos disponibles.
- Una CMDB(Base de datos de la gestión de configuraciones) más precisa pues se registran los incidentes en relación con los elementos de configuración.
- Y principalmente: mejora la satisfacción general de clientes y usuarios.
Por otro lado una incorrecta Gestión de Incidentes puede acarrear efectos adversos tales como:
- Reducción de los niveles de servicio.
- Se dilapidan valiosos recursos: demasiada gente o gente del nivel inadecuado trabajando concurrentemente en la resolución del incidente.
- Se pierde valiosa información sobre las causas y efectos de los incidentes para futuras reestructuraciones y evoluciones.
- Se crean clientes y usuarios insatisfechos por la mala y/o lenta gestión de sus incidentes.
Las principales dificultades a la hora de implementar la Gestión de Incidentes se resumen en:
- No se siguen los procedimientos previstos y se resuelven las incidencias sin registrarlas o se escalan innecesariamente y/o omitiendo los protocolos preestablecidos.
- No existe un margen operativo que permita gestionar los “picos” de incidencias por lo que éstas no se registran adecuadamente e impiden la correcta operación de los protocolos de clasificación y escalado.
- No están bien definidos los niveles de calidad de servicio ni los productos soportados. Lo que puede provocar que se procesen peticiones que no se incluían en los servicios previamente acordados con el cliente.
Proceso
Muestra los procesos implicados en la correcta Gestión de Incidentes.
Control del Proceso
La correcta elaboración de informes forma parte esencial en el proceso de Gestión de Incidentes.
Estos informes deben aportar información esencial para, por ejemplo:
- La Gestión de Niveles de Servicio: es esencial que los clientes dispongan de información puntual sobre los niveles de cumplimiento de los SLA(Acuerdo de nivel de servicio) y que se adopten medidas correctivas en caso de incumplimiento.
- Monitorizar el rendimiento del Centro de Servicios: conocer el grado de satisfacción del cliente por el servicio prestado y supervisar el correcto funcionamiento de la primera línea de soporte y atención al cliente.
- Optimizar la asignación de recursos: los gestores deben conocer si el proceso de escalado ha sido fiel a los protocolos preestablecidos y si se han evitado duplicidades en el proceso de gestión.
- Identificar errores: puede ocurrir que los protocolos especificados no se adecuen a la estructura de la organización o las necesidades del cliente por lo que se deban tomar medidas correctivas.
- Disponer de Información Estadística: que puede ser utilizada para hacer proyecciones futuras sobre asignación de recursos, costes asociados al servicio, etc.
Por otro lado una correcta Gestión de Incidentes requiere de una infraestructura que facilite su correcta implementación. Entre ellos cabe destacar:
- Un correcto sistema automatizado de registro de incidentes y relación con los clientes
- Una KB (Base de Conocimiento) que permita comparar nuevos incidentes con incidentes ya registrados y resueltos. Una KB (Base de Conocimiento) actualizada permite:
- Evitar escalados innecesarios.
- Convertir el “know how” de los técnicos en un activo duradero de la empresa.
- Poner directamente a disposición del cliente parte o la totalidad de estos datos (a la manera de FAQs (Preguntas frecuentes) en una Extranet. Lo que puede permitir que a veces el usuario no necesite siquiera notificar la incidencia.
- Una CMDB(Base de datos de la gestión de configuraciones) que permita conocer todas las configuraciones actuales y el impacto que estas puedan tener en la resolución del incidente.
Para el correcto seguimiento de todo el proceso es indispensable la utilización de métricas que permitan evaluar de la forma más objetiva posible el funcionamiento del servicio. Algunos de los aspectos clave a considerar son:
- Número de incidentes clasificados temporalmente y por prioridades.
- Tiempos de resolución clasificados en función del impacto y la urgencia de los incidentes.
- Nivel de cumplimiento del SLA(Acuerdo de nivel de servicio).
- Costes asociados.
- Uso de los recursos disponibles en el Centro de Servicios.
- Porcentaje de incidentes, clasificados por prioridades, resueltos en primera instancia por el Centro de Servicios.
- Grado de satisfacción del cliente.
sábado, 13 de febrero de 2016
Gestión de Versiones.
Visión General
La Gestión de Versiones es la encargada de la implementación y control de calidad de todo el software y hardware instalado en el entorno de producción.
Debe colaborar estrechamente con la Gestión de Cambios y de Configuraciones para asegurar que toda la información relativa a las nuevas versiones se integra adecuadamente en la CMDB(Base de datos de la gestión de configuraciones) de forma que ésta se halle correctamente actualizada y ofrezca una imagen real de la configuración de la infraestructura TI.
También debe mantener actualizada la DSL (Biblioteca de Software Definitivo), donde se guardan copias de todo el software en producción, y el DHS (Depósito de Hardware Definitivo), donde se almacenan piezas de repuesto y documentación para la rápida reparación de problemas de hardware en el entorno de producción.
Objetivos
Las complejas interrelaciones entre todos los elementos que componen una infraestructura TI convierten en tarea delicada la implementación de cualquier cambio.
La Gestión de Cambios es la encargada de aprobar y supervisar todo el proceso pero es tarea específica de la Gestión de Versiones el diseñar, poner a prueba e instalar en el entorno de producción los cambios preestablecidos.
Todo ello requiere de una cuidadosa planificación y coordinación con el resto de procesos asociados a la Gestión de Servicios TI.
Entre los principales objetivos de la Gestión de Versiones se incluyen:
- Establecer una política de implementación de nuevas versiones de hardware y software.
- Implementar las nuevas versiones de software y hardware en el entorno de producción tras su verificación en un entorno realista de pruebas.
- Garantizar que el proceso de cambio cumpla las especificaciones de la RFC (Petición de Cambio) correspondiente.
- Asegurar, en colaboración con la Gestión de Cambios y Configuraciones, que todos los cambios se ven correctamente reflejados en la CMDB(Base de datos de la gestión de configuraciones).
- Archivar copias idénticas del software en producción, así como de toda su documentación asociada, en la DSL (Biblioteca de Software Definitivo)
- Mantener actualizado el DHS (Depósito de Hardware Definitivo).
Los beneficios de una correcta Gestión de Versiones se resumen en:
- El proceso de cambio se realiza sin deterioro de la calidad de servicio.
- Las nuevas versiones cumplen los objetivos propuestos.
- Se reduce el número de incidentes por incompatibilidades con otro software o hardware instalado.
- El proceso de pruebas asociado no sólo permite asegurar la calidad del software y hardware a instalar sino que también permite conocer la opinión de los usuarios sobre la funcionalidad y usabilidad de las nuevas versiones.
- El correcto mantenimiento de la DSL (Biblioteca de Software Definitivo) impide que se pierdan (valiosas) copias de los archivos fuente.
- Se reduce el número de copias de software ilegales.
- Control centralizado del software y hardware desplegado.
- Protección contra virus y problemas asociados a versiones de software incontroladas.
Las principales dificultades con las que topa la Gestión de Versiones son:
- No existe una clara asignación de responsabilidades y/o la organización TI no acepta la figura dominante de la Gestión de Versiones en todo el proceso de implementación del cambio.
- No se dispone de un entorno de pruebas adecuado en donde se puedan testear de forma realista las nuevas versiones de software y hardware.
- Hay resistencia en los diferentes departamentos a la centralización del proceso de cambio. Es habitual que existan reticencias a adoptar sistemas estandarizados en toda la organización, sobre todo cuando ésta no ha sido la política tradicional de la misma.
- Se realizan cambios sin tener en cuenta a la Gestión de Versiones argumentado que estos sólo son responsabilidad de un determinado grupo de trabajo o que su "urgencia" requería de ello.
- Hay resistencias a aceptar posibles planes de "back-out". Ciertos entornos de producción pueden elegir "ignorar" lo problemas que una nueva versión puede provocar en otras áreas y resistirse a volver a la última versión estable.
- La implementación sincronizada de versiones en entornos altamente distribuidos.
La solución a estos problemas pasa por:
- Un firme compromiso de la organización con la Gestión de Versiones y sus responsables.
- Un adecuado plan de comunicación que informe a todos los responsables y usuarios de la organización TI de las ventajas de una correcta gestión de todo el proceso de cambio.
Proceso
Las principales actividades de la Gestión de Versiones se resumen en:
- Establecer una política de planificación para la implementación de nuevas versiones.
- Desarrollar o adquirir de terceros las nuevas versiones.
- Poner a prueba las nuevas versiones en un entorno que simule lo mejor posible el entorno de producción.
- Validar las nuevas versiones.
- Implementar las nuevas versiones en el entorno de producción.
- Llevar a cabo los planes de back-out o retirada de la nueva versión si esto fuera necesario.
- Actualizar la DSL, el DHS (Depósito de Hardware Definitivo) y la CMDB(Base de datos de la gestión de configuraciones).
- Comunicar y formar a los clientes y usuarios sobre las funcionalidades de la nueva versión.
Muestra los procesos implicados en la correcta Gestión de Versiones:
Control del Proceso
Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Versiones.
Para que estos informes ofrezcan una información precisa y de sencilla evaluación es necesario elaborar métricas de referencia que cubran aspectos tales como:
- Número de lanzamientos de nuevas versiones.
- Número de back-outs y razones de los mismos.
- Incidencias asociadas a nuevas versiones.
- Cumplimientos de los plazos previstos para cada despliegue.
- Asignación de recursos en cada caso.
- Corrección y alcance de la CMDB(Base de datos de la gestión de configuraciones) y la DHS (Depósito de Hardware Definitivo).
- Existencia de versiones ilegales de software.
- Adecuado registro de las nuevas versiones en laCMDB(Base de datos de la gestión de configuraciones)
- Incidencias provocadas por uso incorrecto (formación inadecuada) de la nueva versión por parte de los usuarios.
- Disponibilidad del servicio durante y tras el proceso de lanzamiento de la nueva versión.
Gestión de Cambios.
Visión General
Las principales razones para la realización de cambios en la infraestructura TI son:
- Solución de errores conocidos.
- Desarrollo de nuevos servicios.
- Mejora de los servicios existentes.
- Imperativo legal.
El principal objetivo de la Gestión de Cambios es la evaluación y planificación del proceso de cambio para asegurar que, si éste se lleva a cabo, se haga de la forma más eficiente, siguiendo los procedimientos establecidos y asegurando en todo momento la calidad y continuidad del servicio TI.
Objetivos
El objetivo primordial de la Gestión de Cambios es que se realicen e implementen adecuadamente todos los cambios necesarios en la infraestructura y servicios TI garantizando el seguimiento de procedimientos estándar.
La Gestión de Cambios debe trabajar para asegurar que los cambios:
- Están justificados.
- Se llevan a cabo sin perjuicio de la calidad del servicio TI.
- Están convenientemente registrados, clasificados y documentados.
- Han sido cuidadosamente testeados en un entorno de prueba.
- Se ven reflejados en la CMDB(Base de datos de la gestión de configuraciones).
- Pueden deshacerse mediante planes de "retirada del cambio" (back-outs) en caso de un incorrecto funcionamiento tras su implementación.
Las actividades principales de la Gestión de Cambios se resumen en:
Los principales beneficios derivados de una correcta gestión del cambio son:
- Se reduce el número de incidentes y problemas potencialmente asociados a todo cambio.
- Se puede retornar a configuraciones estables de manera sencilla y rápida en caso de que el cambio tenga un impacto negativo en la estructura TI.
- Se reduce el número de "back-outs" necesarios.
- Los cambios son mejor aceptados y se evitan "tendencias inmovilistas".
- Se evalúan los verdaderos costes asociados al cambio y por lo tanto es más sencillo valorar el retorno real a la inversión.
- La CMDB(Base de datos de la gestión de configuraciones) está correctamente actualizada, algo imprescindible para la correcta gestión del resto de procesos TI.
- Se desarrollan procedimientos de cambio estándar que permiten la rápida actualización de sistemas no críticos.
La implementación de una adecuada política de gestión de cambios también se encuentra con algunas serias dificultades:
- Los diferentes departamentos deben aceptar la autoridad de la Gestión de Cambios sobre todo en lo que respecta al cambio, independientemente de que este se realice para solucionar un problema, mejorar un servicio o adaptarse a requisitos legales.
- No se siguen los procedimientos establecidos y, en particular, no se actualiza correctamente la información sobre los CIs (Elemento de configuración) en la CMDB(Base de datos de la gestión de configuraciones).
- Los encargados de la Gestión de Cambios no conocen a fondo las actividades, servicios, necesidades y estructura TI de la organización incapacitándoles para desarrollar correctamente su actividad.
- Los Gestores del Cambio no disponen de las herramientas adecuadas de software para monitorizar y documentar adecuadamente el proceso.
- No existe el compromiso suficiente de la dirección por implementar rigurosamente los procesos asociados.
- Se adoptan procedimientos excesivamente restrictivos que dificultan la mejora o por el contrario el proceso de cambio se trivializa provocando una falta de estabilidad necesaria para la calidad del servicio.
Conceptos básicos
Resulta conveniente describir y diferenciar sus respectivas atribuciones:
- Gestor de Cambios: es el responsable del proceso del cambio y como tal debe ser el último responsable de todas las tareas asignadas a la Gestión de Cambios. En grandes organizaciones el Gestor de Cambios puede disponer de un equipo de asesores específicos para cada una de las diferentes áreas.
- 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. Sin embargo, en algunos casos también puede incorporar:
- Consultores externos.
- Representantes de los colectivos de usuarios.
- Representantes de los principales proveedores de software y hardware.
Alcance de la Gestión de Cambios
En principio, todo cambio no estándar debe considerarse tarea de la Gestión de Cambios. Sin embargo es a veces impracticable gestionar todos los cambios mediante ésta.
El alcance de la Gestión de Cambios debe ir en paralelo con el de la Gestión de Configuraciones: todos los cambios de CIs (Elemento de configuración) inventariados en la CMDB(Base de datos de la gestión de configuraciones) deben ser correctamente supervisados y registrados.
Al igual que a la hora de implementar la Gestión de Configuraciones se sugirió como medida simplificadora la creación de "configuraciones de referencia" o paquetes de hardware y software estándar (por ejemplo, un PC de referencia con todas sus componentes de hardware y software predefinidas), es importante crear procesos de cambio cuyos protocolos están previamente definidos y autorizados para, por ejemplo, realizar los cambios asociados a las configuraciones de referencia antes citadas.
Estos protocolos de cambio estándar deben ser cuidadosamente elaborados pero una vez definidos permiten una gestión más rápida y eficiente de cambios menores o de bajo impacto en la organización TI.
Proceso
Las principales actividades de la Gestión de Cambios se resumen en:
- Monitorizar y dirigir todo el proceso de cambio.
- Registrar, evaluar y aceptar o rechazar las RFC (Petición de Cambio) recibidas.
- Convocar reuniones del CAB (Consejo acesor del cambio) , excepto en el caso de cambios menores, para la aprobación de las RFC (Petición de Cambio) y la elaboración del FSC (Calendario de cambios).
- Coordinar el desarrollo e implementación del cambio.
- Evaluar los resultados del cambio y proceder a su cierre en caso de éxito.
Control del Proceso
Es imprescindible elaborar informes que permitan evaluar el rendimiento de la Gestión de Cambios.
Para que estos informes ofrezcan una información precisa y de sencilla evaluación es imprescindible elaborar métricas de referencia que cubran aspectos tales como:
- RFC (Petición de Cambio) solicitados.
- Porcentaje de RFC (Petición de Cambio) aceptados y aprobados.
- Número de cambios realizados clasificados por impacto y prioridad y filtrados temporalmente.
- Tiempo medio del cambio dependiendo del impacto y la prioridad
- Número de cambios de emergencia realizados.
- Porcentaje de cambios exitosos en primera instancia, segunda instancia, etc.
- Numero de back-outs con una detallada explicación de los mismos.
- Evaluaciones post-implementación.
- Porcentajes de cambios cerrados sin incidencias ulteriores.
- Incidencias asociadas a cambios realizados.
- Número de reuniones del CAB (Consejo acesor del cambio) con información estadística asociada: número de asistentes, duración, nº de cambios aprobados por reunión, etc.
miércoles, 10 de febrero de 2016
martes, 9 de febrero de 2016
CASO DE ÉXITO DE EMPRESA QUE INCORPORÓ ITIL
TEQUILA PATRÓN (ENTREVISTA CON
PABLO HIGUERA DIRECTOR DE TI)
Patrón Spirits es una empresa fundada
en 1989 con el objetivo de producir “el mejor tequila del mundo”, creando así
el primer tequila ultra-premium a nivel mundial. Bajo la dirección del maestro
destilador Francisco Alcaraz fue construida la fábrica en Jalisco, con el fin
de destilar tequila, bajo una técnica centenaria, llamada Tahona, la cual
consiste en aplastar las fibras del agave lentamente con una gran piedra
volcánica. Actualmente Patrón Spirits es la empresa No.1 de tequila
ultra-premium en el mundo, está disponible en más de 140 países. Usando
botellas hechas a mano, une la producción con el arte. La marca Patrón Spirits
se caracteriza tanto por una excelente calidad en sus productos como por su
preocupación por medio ambiente debido a esto, obtuvo la certificación en ISO
14000 y un premio por parte de PROFEPA.
ANTECEDENTES DEL PROYECTO
La necesidad de implementar la solución
IT360 se basó en la falta de herramientas para manejar de forma sencilla,
integrada y rápida la administración de inventarios, gestión de incidentes y
problemas, entre otros. La falta de aplicaciones de monitoreo complicaba la
detección de la causa-raíz de los problemas existentes de la red.
SOLUCIÓN INTEGRAL (IT 360)
Solución integral que incluye mesa de
ayuda, monitoreo de redes, aplicaciones y ancho de banda.
¿POR QUÉ DECIDIERON IMPLEMENTAR UNA
SOLUCION COMO IT360?
Cuando inicié a trabajar para Patrón
Spirits, me dí cuenta de que no existía ninguna herramienta para la
administración de TI; no se podía hacer inventarios, reportar incidentes o
realizar cambios. No teníamos ninguna herramienta de monitoreo, razón por la
cual estábamos siendo muy reactivos; cuando ocurría algún problema no podíamos
identificar la causa-raíz de este. Ahí nació la inquietud de adquirir una
herramienta que nos ayudara. Yo ya había manejado algunas herramientas de
MangeEngine pero nunca IT360. Investigando, me di cuenta de que esta solución
nos iba a resolver el problema.
OBJETIVOS DEL PROYECTO
- Implementar los procesos de ITIL en la empresa y automatizar los procesos de negocios según las mejores prácticas.
- Ofrecer servicio a más de 1000 usuarios internos.
- Monitorear la infraestructura. Garantizar la continuidad de los servicios
¿QUÉ BENEFICIOS OBTUVIERON?
Obtuvimos muchísimos beneficios. Uno de
los principales, fue poder contar con alertas tempranas en caso de posibles
problemas, alertas sobre discos duros, switches, puertos, latencia, enlaces,
etc. Usando IT360 en Patrón Spirits hemos creado una cultura de mesa de
servicio y así hemos conseguido garantizar la continuidad en nuestro servicio.
Nos ayudó a ser más proactivos. En un principio a muchas personas no les
gustaba levantar un ticket, pero cuando observaron que se les daba seguimiento
a los requerimientos que solicitaban y que se podían hacer encuestas de forma
automática, cambiaron de parecer. Ahora es una forma natural de trabajo,
gracias a los beneficios obtenido, toda la empresa se adaptó, ya llevamos 3
años con la herramienta. En cuanto a beneficio de costo, se define como una
reducción de caidas de servicio, al final esto, mejora el costo. Tenemos áreas
muy críticas como la línea de producción, envasado, almacenes, así como toda la
parte de logística. Si tenemos una caída, obviamente se afectan los costos de
producción. Como ejemplo, ahora resolvemos un problema de un access point en 10
minutos, debido a que sabemos con exactitud cuál es.
Sitio web de referencia.
¿QUÉ ES ITIL?
Desarrollada a
finales de 1980, la Biblioteca de Infraestructura de Tecnologías de la
Información (ITIL®) se ha convertido en el estándar mundial de de facto
en la Gestión de Servicios Informáticos. Iniciado como una guía para el
gobierno de UK, la estructura base ha demostrado ser útil para las
organizaciones en todos los sectores a través de su adopción por innumerables
compañías como base para consulta, educación y soporte de herramientas de
software. Hoy, ITIL® es conocido y utilizado mundialmente.
Pertenece a la OGC, pero es de libre utilización.
ITIL® fue
desarrollada al reconocer que las organizaciones dependen cada vez más de la
Informática para alcanzar sus objetivos corporativos. Esta dependencia en
aumento ha dado como resultado una necesidad creciente de servicios
informáticos de calidad que se correspondan con los objetivos del negocio, y
que satisfagan los requisitos y las expectativas del cliente. A través de los
años, el énfasis pasó de estar sobre el desarrollo de las aplicaciones TI a la
gestión de servicios TI. La aplicación TI (a veces nombrada como un sistema de
información) sólo contribuye a realizar los objetivos corporativos si el
sistema está a disposición de los usuarios y, en caso de fallos o
modificaciones necesarias, es soportado por los procesos de mantenimiento y
operaciones.
A lo largo de todo el
ciclo de los productos TI, la fase de operaciones alcanza cerca del 70-80% del
total del tiempo y del coste, y el resto se invierte en el desarrollo del
producto (u obtención). De esta manera, los procesos eficaces y eficientes de
la Gestión de Servicios TI se convierten en esenciales para el éxito de los
departamentos de TI. Esto se aplica a cualquier tipo de organización, grande o
pequeña, pública o privada, con servicios TI centralizados o descentralizados,
con servicios TI internos o suministrados por terceros. En todos los casos, el
servicio debe ser fiable, consistente, de alta calidad, y de coste aceptable.
ITIL® fue producido
originalmente a finales de 1980 y constaba de 10 libros centrales cubriendo las
dos principales áreas de Soporte del Servicio y Prestación del Servicio. Estos
libros centrales fueron más tarde soportados por 30 libros complementarios que
cubrían una numerosa variedad de temas, desde el cableado hasta la gestión de
la continuidad del negocio. A partir del año 2000, se acometió una revisión de
la biblioteca. En esta revisión, ITIL® ha sido reestructurado
para hacer más simple el acceder a la información necesaria para administrar
sus servicios. Los libros centrales se han agrupado en dos, cubriendo las áreas
de Soporte del Servicio y Prestación del Servicio, en aras de eliminar la
duplicidad y mejorar la navegación. El material ha sido también actualizado y
revisado para un enfoque conciso y claro.
Sitio web de referencia.
Suscribirse a:
Entradas (Atom)