Source: http://docplayer.es/487646-Gestion-de-servicios-de-ti-75-46-administracion-y-control-de-proyectos-ii.html
Timestamp: 2017-12-16 00:31:45+00:00

Document:
Gestión de Servicios de TI Administración y Control de Proyectos II - PDF
Gestión de Servicios de TI Administración y Control de Proyectos II
Download "Gestión de Servicios de TI. 75.46 - Administración y Control de Proyectos II"
Francisco Rojas Márquez
1 Gestión de Servicios de TI Administración y Control de Proyectos II
2 Agenda El enfoque histórico La nueva visión ITIL: un conjunto de buenas prácticas Generación de valor La operación diaria Complejidad de los servicios Mantenimiento del valor en el tiempo Beneficios de ITIL Cómo se implementa ITIL Factores críticos de éxito El desafío de la integración
3 Gestión de Servicios de TI EL ENFOQUE HISTÓRICO
4 La situación más común Procesos no formalizados Servicios no definidos Foco en la tecnología Organización reactiva Limitada relación con el negocio Falta de comunicación entre áreas de TI Falta de visión de Gestión de Servicios Dificultad para mostrar valor
5 Tendemos a organizarnos de esta forma Creación de Silos Operacionales Gerencia de TI Resultados Soporte y Desarrollo Infraestructura Microinformática Comunicaciones Operaciones Seguridad Aplicación A Unix Computadoras portátiles y de escritorio LAN Procesamiento Batch Seguridad Informática Objetivos Aplicación B Aplicación C Objetivos Windows Mainframe Objetivos Impresoras Periféricos especiales Objetivos WAN Objetivos Monitoreo y Control Mesa de Ayuda Objetivos Seguridad Aplicativa Gestión de Accesos
6 Visión tradicional del Servicio
7 Visión tradicional del Servicio Operaciones Administración de BD Soporte y Desarrollo Infraestructura Negocio Unidad de Negocio 1 Unidad de Negocio 2 Unidad de Negocio 3 1) Usuarios utilizan sistemas de información. Usuarios Usuarios Usuarios 3) Tecnología Informática es vista como el elemento principal a proveer a los usuarios a través de los sistemas de información Tecnología Informática Sistemas Sistema de Información ) Sistemas de información implementan la funcionalidad requerida por el negocio. Hardware Sistema Operativo Base de Datos Datos Aplicaciones Redes 4) TI organizada en silos enfocados en proveer tecnología y niveles de servicio que no necesariamente representan valor para el negocio. Organización Acuerdos de Nivel de Servicio Procesos Operaciones Acuerdos de Nivel de Servicio Administración de Bases de Datos Acuerdos de Nivel de Servicio Soporte y Desarrollo Acuerdos de Nivel de Servicio Infraestructura 5) Procesos (por lo general informales) orientados hacia los objetivos individuales de cada área ( silo ).
8 Cómo nos ven los usuarios?
9 Pero los clientes nos ven así Funcionalidad + Disponibilidad Performance Continuidad Seguridad Soporte Confiabilidad
10 Gestión de Servicios de TI LA NUEVA VISIÓN
11 Se necesita un cambio de foco Gerencia de TI Oficina de Procesos Oficina de Proyectos Estrategia de Servicios Arquitectura de Servicios Operaciones Centro de Soporte Infraestructura Aplicativa Infraestructura Tecnológica Infraestructura de Comunicaciones Seguridad Gestión de Ambientes Atención de Incidentes y Pedidos Arquitectura Aplicativa Hardware Centralizado LAN Seguridad Informática Procesamiento Batch Gestión de Accesos Software Factory Hardware Distribuido WAN Seguridad Aplicativa Monitoreo y Control Software de Base Administración de Recursos
12 Con foco en el servicio a través de los procesos
13 La nueva visión de TI como Proveedor de Servicios Negocio Unidad de Negocio 1 Unidad de Negocio 2 Unidad de Negocio 3 Proceso de Negocio Proceso de Negocio Proceso de Negocio ) Procesos de negocio requieren apoyo informático. 3) Infraestructura informática y de telecomunicaciones configura a los servicios de TI. Servicios de Calidad Funcionalidad + Disponibilidad Performance Seguridad Soporte Servicios Servicio ) Servicios de TI apoyan a los procesos de negocio. Acuerdos de Nivel de Servicio Infraestructura 5) Procesos para gestionar los servicios de TI aseguran la operación de los equipos de soporte para proveer al negocio servicios de calidad. Hardware Acuerdos de Nivel de Operacional Sistema Operativo Base de Datos Redes Aplicaciones Datos Equipos de Soporte Arquitectura de Servicios, Operaciones, Centro de Soporte, etc. 4) Equipos de soporte operan y mantienen la infraestructura de los servicios de TI. Procesos Desarrollo de Software Aseguramient o y Control de Calidad Proyectos Configuración y Cambios Nivel de Servicios Incidentes y Problemas Capacidad y Disponibilidad Continuidad
14 Cambio en la visión de TI Tradicional Foco en Tecnología Administrar Infraestructura Usuarios Modalidad Bombero Siempre detrás de las necesidades Islas Procesos informales Gestión de Servicios Foco en el Negocio Proveer Servicios Clientes Prevención y Control Generando nuevas posibilidades Integrado Estandarización y mejores prácticas
15 Una problemática compleja Gestión de los Servicios de IT La punta del Iceberg ADMINISTRAR Y PROVEER TECNOLOGÍA INCIDENTES EN PRODUCCIÓN PEDIDOS DE USUARIOS OPERAR LOS SERVICIOS RESOLVER LOS PROBLEMAS CONTROLAR LA CONFIGURACIÓN ATENDER PEDIDOS DE CAMBIOS PLANIFICAR Y EJECUTAR PROYECTOS DISEÑAR Y DESARROLLAR CAMBIOS GESTIONAR LA CALIDAD INTRODUCIR CAMBIOS AL AMBIENTE PRODUCTIVO
16 Administración de Servicios de TI ITIL: UN CONJUNTO DE BUENAS PRÁCTICAS
17 Qué es ITIL? Information Technology Infrastructure Library Biblioteca sobre: Provisión de Servicios basados en IT Administración de la Infraestructura de IT Generados por la OGC (UK Office of Government Commerce), recolectando la experiencia de los referentes de mercado. Mejores Prácticas (no metodología). Lineamientos (no recetas). Debe ser adaptado a cada caso: Qué procesos son críticos en mi caso? Cómo implemento en concreto cada proceso? (procedimientos, definición de responsabilidades y autoridades, herramientas)
18 Qué NO es ITIL? Una herramienta de Software. La solución que un proveedor quiere imponer. Un conjunto de procedimientos a cumplir/seguir. El reemplazo de todo lo que ya hacemos bien. Lo único necesario para brindar un mejor servicio. Independiente de la cultura organizacional. La solución a todos nuestros males.
19 ITIL V3
20 Actividades de Apoyo Actividades Primarias Cadena de Valor de TI y sus Procesos VALOR Gestión de la relación con el cliente Cumplimiento de los requerimientos de demanda Gestión de la relación con el cliente Gestión de la demanda Gestión de proyectos Gestión de requerimientos Diseño y construcción de la solución Aseguramiento de calidad de la solución Desarrollo de soluciones Gestión de pasajes a producción Gestión de cambios a producción Gestión de la configuración de producción Cumplimiento de pedidos de servicio Mantenimiento de servicios Resolución de incidentes y problemas Soporte del servicio Gestión de los riesgos, la seguridad y la conformidad Instalaciones y Operaciones Gestión de las instalaciones Gestión de operaciones Riesgos, Seguridad y Conformidad Estrategia de TI Gestión de la cartera de servicios Gestión de la capacidad Gestión de la disponibilidad Gestión de nivel de servicios Gestión de procesos Gestión de datos Aprovisionamiento, Personal y Proveedores Finanzas de TI Cartera de Servicios, Arquitectura y Diseño de Servicios Gestión del aprovisionamiento, el personal y los proveedores Gestión de las finanzas de TI
21 Actividades de Apoyo Actividades Primarias Cadena de Valor de TI e ITIL como Modelo de Referencia VALOR ITIL Service Strategy ITIL Service Design Gestión de la relación con el cliente Gestión de la demanda CMMI Software Engineering Unified Process Agile (SCRUM) PMBOK SWEBOK Desarrollo de soluciones ITIL Service Transition ITIL Service Operation ITIL Continual Service Improvement Soporte del servicio COBIT ITIL Service Design ITIL Service Transition ITIL Service Operations ISO Instalaciones y Operaciones Riesgos, Seguridad y Conformidad ITIL Service Operations ITIL V2 ICT Infrastructure Management ITIL Service Design CMMI Supplier Sourcing ITIL Service Strategy ITIL Service Design TOGAF Zachman Framework CMMI -Process aspects Aprovisionamiento, Personal y Proveedores Finanzas de TI ITIL Service Strategy Cartera de Servicios, Arquitectura y Diseño de Servicios
22 Gestión de Servicios de TI GENERACIÓN DE VALOR
23 Qué es un servicio de TI? Medio para entregar valor a los usuarios, facilitando la obtención de resultados que desean obtener sin la necesidad de asumir los costos y riesgos implicados. Utilidad o aptitud para el propósito (requerimientos funcionales) Garantía o aptitud para el uso (requerimientos no funcionales
24 Generación de valor: qué + cómo Utilidad Garantía Funcionalidad del servicio Capacidad y Disponibilidad Confiabilidad Soporte Continuidad Seguridad
25 Cómo lograr el valor necesario? Modelado de Negocio Diseño del Servicio Construcción del Servicio Operación del Servicio Mercado (usuarios del servicio) Demanda (necesidades y patrones de uso del servicio) Nivel de Servicio Diseño y Arquitectura del Servicio Montaje de Infraestructura Construcción de software Gestión de Pasajes a Producción Monitoreo y Gestión de Eventos Gestión de Incidentes, Problemas y Pedidos Especificación del Servicio SLA OLA UC Seguir-dad Análisis y Diseño Aplicativo Hardware y Software de Base Capaci-dad y Disponibilidad Continuidad Comunicaciones Desarrollo Pruebas Gestión de Cambios Gestión de Cartera Gestión de Proyectos Servicios de Valor
26 Modelado del Negocio y Diseño del Servicio Gestión de la demanda Gestión de la disponibilidad Identificar los patrones de actividad del negocio (PBA). Identificar los perfiles de usuario (UP) y su relación con los PBA. Definir los servicios básicos y los servicios de apoyo y sus formas de empaquetamiento. Desarrollar los paquetes de nivel de servicio (cubrir patrones de demanda específicos con utilidad y garantía determinada). Gestión financiera Proporcionar cuantificación financiera del valor de los servicios de TI y el costo de su infraestructura. Gestión de la capacidad Asegurar un nivel de capacidad justificado para todos los aspectos de TI, de acuerdo a las necesidades de negocio actuales y futuras. Asegurar que el nivel de disponibilidad de los servicios de TI alcanza o excede las necesidades de negocio (actuales y futuras). Gestión de la continuidad Apoyar al proceso de continuidad de negocios asegurando la continuidad operativa de los servicios de TI. Gestión de nivel de servicio Negociar, acordar y documentar niveles de servicio con representantes del negocio. Monitorear e informar la capacidad de TI de entregar los servicios con los niveles acordados.
27 Gestión del Nivel de Servicio Pilares de los SLA SLR OLA Necesidades Catálogo de Servicios de TI Acuerdos de nivel operacional Áreas internas de TI Áreas de Negocio SLA Compromiso UC Contratos de soporte Respuesta a las necesidades del negocio Especificación de Servicio de TI Utilidad + Garantía Proveedores externos de TI
28 Gestión de Servicios de TI LA OPERACIÓN DIARIA
29 Cuál es la situación? Eventos que requieren atención Errores ocultos en la infraestructura Servicios que se rompen Necesidad de adaptar los servicios al contexto cambiante Pedidos de usuarios Prepararse para el día a día Necesidad de proteger el ambiente productivo
30 Operación compleja requiere una gestión activa Gestión de accesos Otorgar derechos de uso de los servicios de TI a los usuarios. Gestionar la confidencialidad, disponibilidad e integridad de los datos. Gestión de eventos Detectar y clasificar los eventos generados por el monitoreo de la infraestructura y los servicios. Determinar las acciones de control adecuadas. Gestión de incidentes y pedidos de usuario Recuperar la operación normal tan pronto como sea posible. Proveer un canal para que los usuarios puedan realizar pedidos estándar. Gestión de problemas Encontrar los errores en la infraestructura que causan incidentes. Determinar la mejor solución posible para cada caso. Gestión de cambios Proporcionar un mecanismo controlado para procesar los pedidos de cambio a los servicios productivos. Gestión de pasaje a producción Procurar que los ambientes productivos se modifiquen lo menos posible, de manera totalmente controlada y con todas las consideraciones necesarias.
31 Gestión de Servicios Informáticos GESTIÓN DE INCIDENTES
32 Incidente Se refiere tanto a la interrupción no planificada de un servicio de TI como a la reducción en la calidad de éste. También se consideran incidentes a aquellas fallas de elementos de configuración que no hayan impactado (todavía) a un servicio (Ej. la falla de un disco físico correspondiente a un conjunto de discos espejados).
33 Objetivos Restaurar la operación normal del servicio afectado lo más rápido posible, minimizando el impacto en el negocio y asegurando que se mantengan los niveles acordados de calidad y disponibilidad. Se entiende por operación normal del servicio a lo que se haya definido dentro de los límites del SLA.
34 Alcance Abarca cualquier evento que impacte, o pueda impactar, a un servicio. Los Pedidos de Servicio (Service Request) serán derivados al proceso específico correspondiente.
35 Modelos de incidentes Son aquellos incidentes que pueden considerarse repetitivos y para los cuales se crea un modelo predefinido de incidente. Se debe tener en cuenta: Los pasos a seguir en el incidente. El orden de estos pasos. Responsabilidades. Procedimientos de escalamiento. Líneas de tiempo.
36 Incidentes graves Debe existir un proceso que se encargue del manejo de incidentes graves. La definición de qué es un Incidentes graves debe ser realizada a nivel corporativo, teniendo en cuenta los criterios de priorización e impacto al negocio. Un Incidente grave no es un problema. Puede requerirse la utilización de un equipo de investigación dedicado.
37 Actividades Identificación Registro Categorización y priorización Diagnóstico Inicial Escalamiento Investigación y diagnóstico Resolución y recuperación Cierre
38 Identificación Puede ingresar en forma proactiva (monitoreo) o reactiva (avisos del usuario).
39 Registro Todos los incidentes deben ser registrados. En caso de detectar un Incidente al resolver otro, se debe abrir un nuevo registro. Datos básicos a incluir en un registro de incidente: Número único de referencia Prioridad Fecha y hora de registro CI relacionado Categoría de cierre Método de call-back Estado del incidente
40 Categorización Se debe definir correctamente la granularidad del árbol de categorización. Pasos para lograr el diseño de las categorías: 1. Sesión de brainstorming entre los involucrados. 2. Definición del nivel inicial. 3. Utilización de las categorías iniciales por un período corto de tiempo. 4. Realizar un análisis de lo registrado. 5. Implementar las revisiones necesarias. 6. Repetir desde el punto 3.
41 Priorización Normalmente la prioridad de un incidente se define en función de: La urgencia: Cuán rápido el negocio necesita una solución. El impacto: Generalmente medido con la cantidad de usuarios afectados por el incidente. Otros factores determinantes del nivel de impacto son: Riesgo de vida. Número de servicios afectados. Nivel de pérdidas financieras. Efectos en la imagen (reputación) del negocio. Violación de marcos legales o regulatorios. Algunas organizaciones necesitarán definir una prioridad especial para usuarios VIP (Gerentes, Ejecutivos, Directores).
42 Priorización Urgencia Imapcto Alto Medio Bajo Alta Media Baja Código de prioridad Descripción Tiempo de resolución promedio 1 Críitica 1 hora 2 Alta 8 horas 3 Media 24 horas 4 Baja 48 horas 5 Planificada Planificada
43 Diagnóstico inicial Se utiliza para esto los scripts de diagnóstico y la base de datos de errores conocidos. En esta actividad se intentará resolver el incidente en un primer nivel de atención. Escalamiento: Funcional Jerárquico Investigación y diagnóstico: Entender el orden cronológico de eventos que causaron el incidente. Búsquedas a la KEDB. Confirmar el impacto del incidente.
44 Resolución y recuperación Involucra la resolución del incidente para lo cual se pueden usar los siguientes métodos: Resolución conjunta con el usuario. Resolución remota. Resolución por soporte de campo. Resolución por proveedor externo.
45 Cierre Esta actividad será realizada siempre por el Service Desk. El Service Desk deberá validar junto con el usuario el cierre del incidente. También deberá verificar lo siguiente: Categorización de cierre. Encuesta de satisfacción. Documentación del incidente. Cierre formal.
46 Roles y responsabilidades Administrador de Incidentes Promover la eficiencia y eficacia del proceso. Producir información de gestión. Administrar los recursos humanos. Monitoreo de la efectividad del proceso y recomendaciones de mejora. Desarrollo y mantenimiento de los sistemas de la Gestión de Incidentes. Administración de Incidentes Mayores. Desarrollo y mantenimiento del proceso de la Gestión de Incidentes y sus procedimientos.
47 Roles y responsabilidades Primera línea Atención inicial de incidentes Escalamiento Segunda línea Grupo de soporte (puede ser soporte de campo). Mayor conocimiento técnico. Tercera línea Incluye a los grupos de especialistas (Servers, bases de datos, redes).
48 Gestión de Servicios Informáticos CENTRO DE SERVICIOS AL USUARIO
49 Objetivo Proveer un punto único de contacto (SPOC) para los clientes Centralizar la gestión de la resolución de incidentes
50 Alcance Restablecer la operación del servicio lo más rápido posible. Registrar todos los incidentes/solicitudes. Proveer un primer nivel de soporte y diagnóstico. Proveer un primer nivel de solución cuando fuese posible. Mantener informados a los usuarios del progreso de sus casos. Llevar a cabo las encuestas de satisfacción de los usuarios. Cerrar incidentes y solicitudes. Verificar la CMDB.
51 Actividades Clasificar, asignar, realizar diagnóstico inicial, priorizar y escalar a quien corresponda el incidente Facilitar la rápida recuperación de los servicios Ofrecer orientación a los usuarios Promover el servicio mediante comunicaciones
52 Estructuras organizativas Local Centralizado Virtual
53 Local Diseñado para soportar las necesidades locales del negocio. Usuario Local El soporte se encuentra Usuario y Local brinda Usuario usualmente Local Usuario Local en la misma localidad que está siendo soportada. Es práctico para pequeñas organizaciones. Service Desk Local Es impráctico para organizaciones dispersas geográficamente. Gestión Técnica Gestión de Aplicaciones Gestión de Operaciones de TI Soporte de terceros Gestión de Requerimientos
54 Service Desk centralizado Se centraliza la atención de varios centros geográficos distintos en un Service Desk central. Puede requerirse Sede Cliente 1 soporte Sede en Cliente forma 2 presencial, Sede Cliente 3pero esto debe ser manejado y administrado desde el Service Desk. Ventajas para las grandes organizaciones: Service Desk Reduce los costos operacionales. Proporciona una vista gerencial central consolidada. Segunda línea Mejora el uso de los recursos. Gestión Técnica Gestión de Aplicaciones Gestión de Operaciones de TI Soporte de terceros Gestión de Requerimientos
55 Service Desk virtual La ubicación de los analistas del SD es transparente al usuario. Deben existir procesos y procedimientos San Francisco comunes y un solo Service Desk registro de incidentes. Paris Service Desk London Service Desk Virtual Service Desk Rio de Janeiro Service Desk Lenguaje común acordado para la entrada de datos. Se mantiene el punto único de contacto con el cliente. Sydney Puede Beijing seguir requiriéndose presencia on-site Service para Desk algunos Service Desk puntos. Sistema de Gestión de los Servicios de Conocimiento
56 Grupos de Service Desk especializados En algunos casos es recomendable crear grupos de especialistas dentro de la función de Service Desk. Esto permitirá derivar los incidentes según el tipo de especialista que pueda resolverlos.
57 Recomendaciones Recomendaciones de ambientación: Luz natural y suficiente espacio físico. Control acústico del ambiente. Área de esparcimiento o break. Recomendaciones para facilitar el contacto único: Hacer público el número telefónico del Service Desk. Adhesivos informando el número en los teléfonos. Utilización de salvapantallas con datos de contacto del Service Desk. Incorporar merchandising con el número de contacto.
58 Gestión de Servicios Informáticos GESTIÓN DE PROBLEMAS
59 Objetivos Prevenir la ocurrencia de problemas e incidentes asociados. Eliminar incidentes recurrentes. Minimizar el impacto de incidentes que no pudieron ser prevenidos.
60 Problema Causa desconocida de uno o más Incidentes.
61 Impacto, urgencia y prioridad Los problemas deben priorizarse utilizando los mismos criterios utilizados para los Incidentes (matriz de prioridades). Se debe tener en cuenta lo siguiente: Frecuencia e impacto de incidentes relacionados. Definición sobre qué constituye un problema. Incorporar el concepto de severidad del problema (costo, tiempo de resolución, recursos).
62 Solución alternativa En algunos casos puede ser encontrada una solución alternativa a los incidentes causados por el problema. Es importante que aún así, se continúe con la investigación de la causa raíz del problema. Siempre debe registrarse en la herramienta de gestión el detalle de la solución alternativa encontrada.
63 Error conocido Una vez que se complete el diagnóstico del problema y que se haya encontrado una solución alternativa, se deberá registrar en la KEDB el error conocido. De esta manera, si surgen nuevos incidentes o problemas relacionados, éstos pueden ser resueltos rápidamente. También puede detectarse la necesidad de registrar un error conocido en una fase previa al diagnóstico, a modo informativo. Identificación de errores conocidos La identificación y registro del error conocido debe llevarse a cabo aún si todavía no se ha encontrado la solución definitiva del error, proporcionando información de su existencia y/o posibles registros de soluciones temporales de prueba. Para evitar la duplicación de registros, se recomienda centralizar la administración de la KEDB en un único responsable.
64 Base de datos de errores conocidos Permite el almacenamiento del conocimiento obtenido a través de la resolución de incidentes y problemas, para permitir un rápido diagnóstico y solución en caso que ocurran. El registro de error conocido debe contener detalles exactos de la falla y sus síntomas, además de datos precisos para la solución (alternativa o definitiva) del problema. Pueden existir casos donde se decida convivir con un problema en la infraestructura de TI, cuando el caso de negocio no justifique la resolución. Los datos incluidos en la KEDB debe ser fácilmente accesibles.
65 Roles y responsabilidades Gestor de Problemas Grupos de Resolución de Problemas
66 Gestión de Servicios Informáticos GESTIÓN DE CAMBIOS
67 Gestión de Cambios Objetivo: Mantener la Infraestructura bajo control Asegurar la aplicación de procedimientos estándares para la atención de los cambios, de manera de minimizar el impacto en los servicios.
68 Gestión de Cambios Actividades: Aceptación (recepción y filtro inicial) Clasificación (menor, significativo, mayor, urgente) Aprobación y Planificación Seguimiento de la ejecución Información de Gestión (cantidad de Cambios que no se aceptaron, cambios OK, etc.)
69 Actividades Crear RFC Propuesta de Cambios (opcional) Registrar el RFC Autorizar la propuesta de cambio Reporte de evaluación Iniciador Gestión del Cambio Change authority Gestión del Cambio Gestión del Cambio Revisar el RFC Evaluar el cambio Autorizar el cambio Solicitado Plan actualizado Listo para evaluación Listo para decisión Autorizado Planificado Coordinar la implementación de Cambio* Implementado Revisar y cerrar el registro de cambio Cerrado Ordenes de Trabajo Ordenes de Trabajo *Incluye construcción y prueba del cambio Actualizar el cambio y la información de la congiguración en el CMS
70 Crear el RFC El cambio es originado por pedido de un iniciador. Para cambios mayores con implicaciones organizacionales y/o financieras significativas, puede ser requerida una propuesta de cambio (Change Proposal). La propuesta de cambio contendrá una descripción completa del cambio junto con una justificación financiera y de negocio. Los procedimientos para registrar y documentar los cambios deben estar previamente definidos.
71 Registro de un Pedido de Cambio RFC Número RFC Iniciación Motivo del Cambio CI (atributos) Prioridad y Urgencia Recomendación del CAB Implementador del Cambio Resutado de las Pruebas Fecha y Hora de Aprobación Descripción del Cambio Análisis de Riesgo e Impacto / Recursos Fecha y Hora de Implementación Implementación Programada Resultados del Cambio Autorizado por Revisión Post-Implementación
72 Revisar el RFC La Gestión de Cambios debe revisar cada uno de los requerimientos y filtrar los que considera que son: Imprácticos. Repetidos en otros RFC recientes que fueron aprobados, rechazados o continúan en revisión. Incompletos.
73 Evaluar el RFC Debe evaluarse la implementación de cada cambio. Se propone seguir el método de las siete R de la Gestión del Cambio Quién REQUIERE el cambio? Cuál es la RAZÓN del cambio? Cuál es el RETORNO esperado del cambio? Cuáles son los RIESGOS implicados en el cambio? Cuáles son los RECURSOS necesarios para realizar el cambio? Quién es RESPONSABLE de la construcción, prueba e implementación del cambio? Cuál es la RELACIÓN entre éste y otros cambios?
74 Autorizar el RFC Gestión del Cambio Categorización de riesgos. Evaluación de cambios. Asignación de prioridad. Planificación de cambios.
75 Coordinar la Implementación Los especialistas técnicos deben construir el cambio. Change Management tiene la responsabilidad de asegurar que los cambios sean implementados tal como fueron planificados. Verificar los procedimientos de vuelta atrás (Remediation Plan) Change Management tiene un rol de control para asegurar que todos los cambios hayan sido testeados.
76 Revisar y Cerrar el RFC Es necesario realizar una revisión post-implementación para confirmar Que el cambio cumplió con sus objetivos. Que el iniciador y los demás interesados están conformes con el resultado. Que no se han producido efectos colaterales.
77 Roles y responsabilidades Administrador de Cambios Asigna prioridades a los RFC junto con el iniciador. Rechaza los RFC que son impracticables. Lista todos los RFC para ser revisados en las reuniones del CAB. Elabora la agenda de la reunión y la envía con anticipación a todos los miembros del CAB. Decide quiénes deben asistir a las reuniones, dependiendo de la naturaleza del RFC, qué es lo que será modificado y qué áreas de conocimiento técnico son necesarias.
78 Roles y responsabilidades Administrador de Cambios Convoca las reuniones del Comité de Cambios / Comité de Emergencia (CAB/EC : Change Advisory Board / Emergency Committee) para los cambios urgentes. Preside todas las reuniones del CAB y del CAB/EC. Actualiza el registro del cambio. Revisa todos los cambios implementados. Cierra los RFC. Realiza reportes regulares de la gestión.
79 Roles y responsabilidades Comité de Administración de Cambios El CAB es un cuerpo que existe para dar soporte en la autorización de los cambios y en asistir en la evaluación y priorización de los mismos. Reglamento del CAB Deben distribuirse los RFC con antelación a la reunión. Responder y realizar el análisis de los RFC (mandatorio). Concurrir a la reunión del CAB (opcional). Aprobar o rechazar los RFC. Analizar cambios aplicados sin una referencia al CAB Revisión del proceso de cambios Resultados del negocio que salen del proceso de cambio
80 Roles y responsabilidades Comité de Emergencias Es un grupo pequeño de personas que se reúnen o contactan para la evaluar y autorizar los cambios de emergencia. La selección de los miembros puede depender de la naturaleza del cambio. Los miembros deben tener conocer y entender tanto las perspectiva del negocio como los temas técnicos, para poder tomar las decisiones apropiadas. El contacto vía teléfono o puede ser el único medio factible de reunión.
81 Gestión de Servicios Informáticos GESTIÓN DE LIBERACIONES Y DESPLIEGUE
82 Gestión de Liberaciones Objetivo: Asegurar que todos los aspectos de la liberación de un cambio (técnicos y no técnicos) sean tenidos en cuenta. Facilitar la introducción del software y hardware en un ambiente de IT controlado
83 Alcance Asegurar planes de despliegue e implementación claros y comprensibles. Definir paquetes de versiones que puedan ser construidos, instalados, testeados y desarrollados eficientemente, para que sea posible una implementación exitosa. Permitir introducir servicios nuevos o modificados, junto con los sistemas, tecnología y organización que lo soporten, que sean capaces de cumplir con los SLA. Lograr clientes, usuarios y personal de sistemas conformes con las prácticas y los entregables del proceso.
84 Actividades Planificación (políticas, recursos) Preparación y automatización de la instalación Aceptación (de usuarios y demás áreas afectadas) Planificación del despliegue Comunicación Capacitación Distribución e instalación (despliegue) Información de Gestión (cantidad de despliegues, cantidad de CI s impactados en cada despliegue, etc.)
85 Formas de implementación Big Bang vs. Por fases Big Bang: El servicio nuevo o modificado es implementado conjuntamente a todos los usuarios. Por fases: El servicio es implementado inicialmente a una parte de los usuarios, y luego se repite la misma operación al resto de usuarios siguiendo un plan. Push vs. pull Push: El componente del servicio es distribuido desde una posición central a las estaciones de trabajo de los usuarios. Pull: El componente del servicio es colocado en una posición central y los usuarios lo bajan cuando disponen de tiempo a sus estaciones de trabajo. Automatizado vs. manual Es el mecanismo de implementación de las versiones.
86 Roles Administrador de Pasajes a Producción Administrador de Construcción de Paquetes Personal técnico involucrado
87 Gestión de Servicios de TI COMPLEJIDAD DE LOS SERVICIOS
88 Cuál es la situación? Procesos de negocio dependen de los servicios de TI Gran cantidad de servicios de TI interconectados Procesos de negocio en constante adaptación Tecnología de los servicios de TI compleja Negocio en contexto dinámico Necesidad de controlar la infraestructura Arquitectura aplicativa de múltiples capas
89 Servicios complejos requieren control Gestión de la configuración Crea y mantiene actualizada una base de datos (CMDB) cuyo contenido representa un modelo de la infraestructura de los servicios en producción. Permite identificar, registrar y ofrecer información de todos los componentes de IT de los ambientes productivos. Gestiona Ítems de Configuración (elementos que componen la infraestructura productiva de los servicios de TI).
90 Gestión de la Configuración Objetivo: Identificar, registrar y ofrecer información de todos los componentes de IT que están bajo el control de Gestión de la Configuración
91 Gestión de la Configuración Los CI (configuration items) se registran en una CMDB (configuration management database) Los CI tienen: Alcance (qué aplicativos, sectores, etc interesan?) Nivel (registro 1 PC o registro 1 mouse + 1 teclado, etc) Atributos Relaciones
92 Gestión de la Configuración Actividades: Planificar Identificar Controlar Proveer información de gestión
93 Definitive Media Library La Definitive Media Library es una biblioteca segura en la cual las versiones definitivas de todos los CI son almacenadas y protegidas. En la DML se almacenan todas las copias maestras que han pasado por los controles de calidad. La DML debe incluir copias definitivas de software comprado (junto con licencias e información) y de software desarrollado internamente. Las copias maestras de la documentación de un sistema también deben ser almacenada de forma electrónica en la DML. La DML incluirá un lugar físico para guardar copias. Sólo lo que ha sido debidamente autorizado podrá aceptarse en la DML.
94 Relación entre la DML y la CMDB DML and CMDB DML Cis Físicos Información sobre CIs Cis Electrónicos Registro de versión CMDB Construcción de una nueva versión Prueba de una nueva versión Implementación de una nueva versión Distribución de una nueva versión en producción
95 Configuration Baseline Es la configuración de un servicio producto o infraestructura que ha sido formalmente revisada, acordada Servirá de base para futuras actividades y puede ser modificada sólo a través de procedimientos formales de cambio. Contiene la estructura, los contenidos y los detalles de una configuración, y representa un conjunto de CI y sus relaciones.
96 Configuration Snapshot Es el estado actual de un CI o de un entorno, por ejemplo obtenido a través de una herramienta de descubrimiento. Esta foto es guardada en el CMS y queda como un registro de estado histórico.
97 Roles del Proceso Administrador de Configuraciones Coordinador de Configuraciones Dueño de CI Administrador de la Librería de Medios Administrador de Herramientas / CSM Comité de Control de Configuración
98 Gestión de Servicios de TI MANTENIMIENTO DEL VALOR EN EL TIEMPO
99 Cuál es la situación? Servicios que sufren sucesivas adaptaciones Avances tecnológicos constantes Estrategia de negocio que evoluciona Cambios organizativos Contexto cambiante Pérdida progresiva de valor Mejor comprensión de los procesos
100 Implementar la mejora continua para sostener valor Caso de Negocio Articular razones para justificar la mejora. Proveer datos de costo y beneficios. Analizar el ROI. Los 7 pasos de la mejora de proceso 1. Identificar qué debo medir. 2. Determinar qué puedo medir. 3. Reunir los datos. 4. Procesar los datos. 5. Analizar la información. 6. Presentar y usar la información. 7. Implementar acciones correctivas.
101 Administración de Servicios de TI BENEFICIOS DE ITIL
102 Por qué implementar ITIL? Procesos negocio dependen de servicios de TI. La TI es cada vez más compleja, igual su gestión. Aumento de marcos regulatorios (SOX, BCRA 4609). Cumplimiento con las auditorías (COBIT). Exigencias del mercado (Certificación World-Class).
103 Qué puedo esperar de ITIL? Optimizar la utilización de recursos. Ajustar la disponibilidad y la capacidad. Adecuar la escalabilidad. Aumentar la confiabilidad de los servicios de TI. Mejorar la experiencia del usuario. Reducir el riesgo de la operación.
104 ITIL como impulsor de la Gestión de Servicios de TI Promueve la visión de TI como proveedor de servicios. Fomenta el foco en el cliente. Alinea la organización de TI con el negocio. Posiciona a TI como parte importante de la cadena de valor. Compromete a dar lo que realmente se puede dar. Mejora la calidad de los servicios. Servicios de IT Procesos de Negocio Productos Valor al Cliente
105 ITIL como impulsor de la Gestión por Procesos Estandariza los procesos en base a las mejores prácticas. Define sus interrelaciones. Define roles y responsabilidades. Promueve el uso de conceptos comunes (comunicación). Sirve de base para la certificación de personas y empresas. Servicios de IT Procesos de Negocio Productos Valor al Cliente
106 Administración de Servicios de TI CÓMO SE IMPLEMENTA ITIL?
107 Qué implica realizar un proyecto ITIL? Fase inicial (análisis de brecha) Conocer la situación actual (Personas, Procesos, Tecnología). Considerar el tamaño de la organización. Establecer las motivaciones. Clarificar expectativas. Diseño Diseñar los procesos prioritarios (enfoque modular). Implementación Implementar (apoyo de herramientas). Institucionalizar. Mejora continua Manejo del Cambio
108 Más madurez es mejor? Productividad y Calidad Estado Significado Resultado 0 - Incompleto El proceso no se ejecuta adecuadamente 1 Ejecutado Acuerdo general en que se hace Riesgo 2 - Administrado Planificado y controlado Productos estándar 3 - Establecido Proceso definido para la ejecución y administración Cambios al proceso aprobados y documentados Existen definición formal de los procesos 4 - Predecible Ejecución consistente en la práctica Performance medida y analizada Conocimiento cualitativo de la calidad Predecibilidad 5 - Optimizado Performance optimizada para cumplir los objetivos de negocio Efectividad del proceso medida Procesos no efectivos cambiados / eliminados
109 Temas a tener en cuenta en cada fase de una implementación Antes (Planificación) Durante (Diseño e implementación) Después (Seguimiento y Mejora Continua) Personas Conocer cultura Establecer visión Cambio cultural Participación de las distintas áreas Comunicar Formar Marketing Comunicar Capacitar Establecer grupos de interés Procesos Gap Analysis Seleccionar procesos Priorizar implementación Diseñar procesos Documentar Implementarlos Medir Optimizar Integrar Herramientas Relevar tecnología Seleccionar y adquirir nueva tecnología Automatizar Procesos Migrar datos Realizar pruebas Integrar Administrar Actualizar Integrar
110 Administración de Servicios de TI FACTORES CRÍTICOS DE ÉXITO
111 Principales aspectos a considerar Definir formalmente un proyecto para la implementación. Conseguir y mantener el apoyo de los niveles directivos (al proyecto y a los administradores de los procesos). Trabajar en equipo: los procesos de Administración deben ser comprendidos y utilizados por todos y para todos. Definir los servicios que presta TI al resto de la organización. Implementar las mejoras gradualmente (maduración y quick-wins), utilizar los procesos. Dedicar el tiempo necesario para aportar en las mejoras, capacitación, utilización de los procesos.
112 Gestión de Servicios de TI EL DESAFÍO DE LA INTEGRACIÓN
113 Actividades de Apoyo Actividades Primarias Cadena de Valor de TI y sus Procesos VALOR Gestión de la relación con el cliente Gestión de la demanda Desarrollo de soluciones Soporte del servicio Instalaciones y Operaciones Riesgos, Seguridad y Conformidad Aprovisionamiento, Personal y Proveedores Finanzas de TI Cartera de Servicios, Arquitectura y Diseño de Servicios
114 Visión integral de los procesos de gestión de servicios de TI
Gestión de Servicios de TI. 75.46 - Administración y Control de Proyectos II
Gestión de Servicios de TI 75.46 - Administración y Control de Proyectos II Gestión de Servicios de TI INTRODUCCIÓN Situación Procesos de negocio complejos y cambiantes, tiempos acelerados y un mercado

References: Resolución 
 Resolución 
 resolución 
 Resolución 
 resolución 
 Resolución 
 Resolución 
 Resolución 
 Resolución 
 resolución 
 resolución 
 Resolución