ITIL: MEJORA CONTINUA DEL SERVICIO

Objetivos:

  • Recomendar mejoras para todos los procesos y actividades involucrados en la gestión y prestación de los servicios TI.
  • Monitorizar y analizar los parámetros de seguimiento de Niveles de Servicio y contrastarlos con los SLAs en vigor.
  • Proponer mejoras que aumenten el ROI y VOI asociados a los servicios TI.
  • Dar soporte a la fase de estrategia y diseño para la definición de nuevos servicios y procesos/ actividades asociados a los mismos

Ciclo de Deming

El ciclo PDCA: Planificar (Plan), Hacer (Do), Verificar (Check) y Actuar (Act), también conocido como ciclo de Deming en honor a su creador, Edwards Deming, constituye la columna vertebral de todos los procesos de mejora continua:

  • Planificar: definir los objetivos y los medios para conseguirlos.
  • Hacer: implementar la visión preestablecida.
  • Verificar: comprobar que se alcanzan los objetivos previstos con los recursos asignados.
  • Actuar: analizar y corregir las desviaciones detectadas así como proponer mejoras a los procesos utilizados

Métricas

No se puede mejorar aquello que no se conoce y no se puede llegar realmente a conocer aquello que no se puede medir.

Una organización TI debe utilizar tres tipos de métricas:

  • Tecnológicas: que miden la capacidad, disponibilidad y rendimiento de las infraestructuras y aplicaciones.
  • De procesos: que miden el rendimiento y calidad de los procesos de gestión de los servicios TI.
  • De servicios: que evalúan los servicios ofrecidos en términos de sus componentes individuales.

Si la organización TI se ha propuesto, por ejemplo, como CSF la mejora en la atención al usuario los KPIs incluirían:

  • Tiempo medio de resolución de los incidentes.
  • Adecuación de los procesos de escalado.
  • Percepción de los usuarios respecto a la atención prestada mediante encuestas de satisfacción.

Este ciclo continuo se compone de 6 fases:

1.Establecer la visión: se deben establecer metas y objetivos alineados con el modelo de negocio de la organización.

2.Conocer el estado actual: saber de dónde partimos (organización, recursos, capacidades, procesos,…) para poder utilizar ese estado como referencia de base.

3.Establecer objetivos cuantificables: a partir de la visión establecer hitos y entregables que permitan realizar un seguimiento del proceso.

4.Planificar: establecer un Plan de mejora del Servicio (SIP) que determine qué acciones son necesarias para obtener los objetivos deseados en los plazos previstos y con el nivel de calidad predeterminado.

5.Comprobar: determinar si se han cumplido los planes y se han seguido lo procesos establecidos.

6.Integrar los cambios: asegurase de que los cambios realizados forman parte de la cultura de la organización permitiéndonos así reiniciar el ciclo con nuevo impulso

Herramientas y Metodologías

  • Análisis comparativo
  • Análisis de brechas (Gap analysis)
  • Análisis DAFO
  • Cuadro de Mando Integral (CMI)

Una de las herramientas básicas para la puesta en marcha del CSI es la realización de un “Caso de Negocio” que permita evaluar, en términos del negocio, los potenciales beneficios de la implantación del CSI.

Este caso de negocio debe ofrecer una clara respuesta a preguntas iniciales tales como:

  • ¿Cuáles son nuestros objetivos?
  • ¿Dónde nos encontramos respecto a esos objetivos?
  • ¿Qué necesitamos para alcanzarlos?
  • ¿Cuál será el retorno previsto?
  • ¿Cómo se evaluará lo obtenido?

ITIL: FASE OPERACIÓN DEL SERVICIO (SEGUNDA PARTE)

5. Gestión de Acceso

El objetivo de la Gestión de Acceso a los Servicios TI es otorgar permisos de acceso a los servicios a aquellos usuarios autorizados e impedírselo a los usuarios no autorizados.

En una palabra, es la puesta en práctica de las políticas y acciones definidas en la Gestión de la Seguridad y la Gestión de la Disponibilidad.

Las actividades de la Gestión de Acceso a los Servicios TI incluyen:

  • Petición de acceso, que puede llegar por distintas vías como el departamento de RRHH, una solicitud de cambio, una instrucción autorizada…
  • Verificación. Se comprueba la identidad del usuario que solicita el acceso, así como de aquellos que lo autorizan. También se examina si los motivos para otorgar el acceso son pertinentes.
  • Monitorización de identidad. Los cambios en la asignación de permisos suelen estar asociados a un cambio de estatus dentro de la organización: ascensos, despidos, jubilaciones…
  • Registro y monitorización de accesos. La Gestión de Accesos es responsable de asegurar que los permisos que ha otorgado se están usando apropiadamente.
  • Eliminación y restricción de derechos. En algunos casos, los derechos pueden ser eliminados por completo: fallecimiento, dimisión, despido, traslados…

Control del proceso

La eficacia del proceso de Gestión de Acceso a los Servicios TI puede controlarse mediante los siguientes indicadores:

  • Número de peticiones de acceso.
  • Instancias de acceso garantizado, por servicio, usuario, departamento, etc.
  • Instancias de acceso garantizado por derechos de acceso de departamento o individuo.
  • Número de incidentes que requirieron la revocación de los permisos de acceso.
  • Número de incidentes causados por una configuración incorrecta de los accesos.

6. FUNCIONES

Las funciones involucradas en la fase de Operación del servicio son las responsables de que los servicios cumplan los objetivos solicitados por los clientes y de gestionar toda la tecnología necesaria para la prestación de dichos servicios:

  • Centro de Servicios: responsable de todos los procesos de interacción con los usuarios de los servicios TI.
  • Gestión de Operaciones TI: responsable de la operación diaria del servicio.
  • Gestión Técnica: es una unidad funcional que incluye a todos los equipos, grupos y departamentos involucrados en la gestión y soporte de la infraestructura TI.
  • Gestión de Aplicaciones: esta unidad funcional es la responsable de la gestión del ciclo de vida de la aplicaciones TI

Centro de Servicios

  • Call Center: Su objetivo es gestionar un alto volumen de llamadas y redirigir a los usuarios, excepto en los casos más triviales, a otras instancias de soporte y/o comerciales.
  • Centro de Soporte (HelpDesk): Su principal objetivo es ofrecer una primera línea de soporte técnico que permita resolver en el menor tiempo las interrupciones del servicio.
  • Centro de Servicios (ServiceDesk): representa la interfaz para clientes y usuarios de todos los servicios TI ofrecidos por la organización, con un enfoque centrado en los procesos de negocio. Aparte de ofrecer los servicios citados anteriormente, ofrece servicios adicionales a clientes, usuarios y la propia organización TI tales como:
    • Supervisión de los contratos de mantenimiento y niveles de servicio.
    • Canalización de las Peticiones de Servicio de los clientes.
    • Gestión de las licencias de software.
    • Centralización de todos los procesos asociados a la Gestión TI.

La implementación de un Centro de Servicios requiere una meticulosa planificación. En primera instancia deben establecerse los siguientes puntos:

  • Cuáles son las necesidades.
  • Cuáles han de ser sus funciones.
  • Quiénes serán los responsables del mismo.
  • Qué cualificaciones profesionales poseerán sus integrantes.
  • Si se deben externalizar ciertos servicios como, por ejemplo, el soporte técnico del hardware.
  • Qué estructura de Centro de Servicios (distribuido, central o virtual) se adapta mejor a nuestras necesidades y las de nuestros clientes.
  • Qué herramientas tecnológicas necesitamos.
  • Qué métricas determinarán el rendimiento del Centro de Servicios.

Gestión de Operaciones

Los objetivos de la Gestión de Operaciones TI consisten en:

  • Mantenimiento del status quo de los procesos y actividades de la organización para alcanzar estabilidad en el día a día.
  • Escrutinio regular y mejoras para alcanzar un servicio mejorado con costes reducidos, manteniendo la estabilidad.
  • Aplicación rápida de habilidades operacionales para diagnosticar y resolver cualquier fallo que ocurra en las operaciones

Implementación

  • Comprender en profundidad cómo se emplea la tecnología para prestar servicios.
  • Comprender la importancia relativa y el impacto de esos servicios en el negocio.
  • Los procedimientos y manuales que delimitan los roles operacionales tanto en la gestión de la tecnología como en la prestación de servicios.
  • Disponer de un conjunto de métricas claramente diferenciadas que informen sobre la culminación de objetivos de servicio, y mantengan informados a los gestores TI sobre la eficiencia y efectividad de las Operaciones TI.
  • Los equipos de operaciones TI deben comprender exactamente cómo afecta el rendimiento de la tecnología a la prestación de servicios.
  • Una estrategia de gasto orientada a equilibrar los requisitos de las distintas unidades de negocio con los ahorros disponibles gracias a la optimización de la tecnología existente o la inversión en nueva tecnología.
  • Una estrategia de inversión basada en retorno del valor, más que retorno del gasto

Las dos funciones de la Gestión de Operaciones, que trataremos en profundidad en el siguiente apartado, suelen conformar estructuras organizacionales por sí mismas:

  • Control de Operaciones, cuya plantilla generalmente se organiza en turnos de operadores encargados de asegurar que las tareas rutinarias se llevan a cabo. El Control de Operaciones también desempeña tareas de monitorización y control, para lo que a menudo recurre a unidades específicas como el Puente de Operaciones o un Centro de Operaciones en Red.
  • Gestión de Instalaciones, encargada de supervisar el mantenimiento de todo el equipamiento físico. A menudo está ubicada junto a la Gestión Técnica y de Aplicaciones en grandes centros de datos

El Control de Operaciones desempeña las siguientes tareas:

  • Gestión de Consolas, que define cómo se va a llevar a cabo la observación central y evalúa la capacidad de monitorización. Con este fin, las consolas son sometidas a ejercicios de monitorización y control de actividades.
  • Programación de tareas, que gestiona los trabajos rutinarios o automáticos.
  • Back-up y restauración de archivos en beneficio de los equipos de Gestión Técnica y de Aplicaciones, así como de los usuarios.
  • Gestión de Impresión y salidas, para la recopilación y distribución de documentos impresos u otros entregables electrónicos.
  • Actividades de rendimiento o mantenimiento en beneficio de los equipos de Gestión Técnica o de Aplicaciones

Gestión Técnica

El objetivo principal de la Gestión Técnica consiste en ayudar en la planificación, implementación y mantenimiento de una infraestructura técnica estable para apoyar los procesos de negocio de la organización mediante:

  • Una topología técnica bien diseñada, elástica y económica.
  • Uso de habilidades técnicas adecuadas para mantener la infraestructura técnica en condiciones óptimas.
  • Uso ágil de habilidades técnicas para una diagnosis rápida y resolución de cualquier error técnico que pueda ocurrir

Las actividades de la Gestión Técnica engloban:

  • Identificar el conocimiento y experiencia necesarios para prestar servicios y gestionar la infraestructura TI:
  • Documentando las habilidades que posee la organización.
  • Identificando las necesidades de formación.
  • Diseñar y desarrollar (aunque no impartir) programas de formación relacionados con los recursos técnicos.
  • Formación técnica de los usuarios.
  • Formación técnica del Centro de Servicios
  • Formación técnica de otros equipos del ciclo de vida.

Las actividades de la Gestión Técnica engloban

  • La Gestión Técnica a menudo participa en la contratación de:
  • Recursos humanos, en caso de que no se puedan desarrollar las habilidades requeridas (por falta de personal, de nivel mínimo).
  • Vendedores, ya que a menudo los miembros del equipo de la Gestión Técnica son los únicos que saben exactamente los conocimientos técnicos que debe tener un comercial y cómo evaluarlos en los candidatos.
  • La Gestión Técnica también se encarga de definir estándares para
  • Diseñar nuevas arquitecturas, participando además en la definición de las mismas durante las fases de Estrategia y Diseño.
  • Las herramientas de Gestión de Eventos y respuestas “modelo” a ciertos tipos de eventos.
  • Estándares de rendimiento que luego serán utilizados por la Gestión de la Disponibilidad y la de la Capacidad

La Gestión Técnica puede medirse a través de los siguientes indicadores:

  • Métricas de los entregables acordados.
  • Mediciones de procesos.
  • Rendimiento de la tecnología.
  • Tiempo promedio entre incidencias de determinado equipamiento.
  • Medición de las actividades de mantenimiento.
  • Formación y desarrollo de habilidades

Gestión Aplicaciones

La Gestión de Aplicaciones tiene como principal objetivo identificar los requisitos funcionales del software de aplicaciones, prestar apoyo en el diseño y desarrollo de dichas aplicaciones y colaborar en el soporte y mejora que siguen a su despliegue. Para lograr este fin, se precisa:

  • Aplicaciones bien diseñadas, elásticas y que optimicen costes.
  • Garantizar que la funcionalidad requerida está disponible para alcanzar los resultados de negocio deseados.
  • Organizar las habilidades técnicas adecuadas para mantener aplicaciones operacionales en condiciones óptimas.
  • Uso ligero de habilidades técnicas para una diagnosis rápida y la resolución de cualquier fallo técnico que pueda presentarse

Estructura

Un ejemplo típico es:

  • Aplicaciones financieras.
  • Aplicaciones de mensajería y colaboración.
  • Aplicaciones de RRHH
  • Aplicaciones de soporte industrial
  • Aplicaciones de automatización de fuerza de ventas (CRM)
  • Aplicaciones de procesamiento de ventas.
  • Aplicaciones del centro de llamadas y marketing
  • Aplicaciones específicas del negocio (sanidad, seguros, banca, etc.)
  • Aplicaciones TI, como Centro de Servicios, Sistemas de Gestión de la Empresa (SKMS, CMS), etc.
  • Portales web.
  • Tienda online

Métricas de los entregables acordados. Esto puede incluir:

  • Capacidad de los usuarios para acceder a la aplicación y sus funcionalidades.
  • Reportes y archivos enviados a los usuarios.
  • Porcentajes de éxito y disponibilidad para determinadas transacciones críticas para el negocio.
  • Formación del Centro de Servicios.
  • Registro de resolución de problemas en el sistema de Gestión del Conocimiento.
  • Percepción que los usuarios tienen de la calidad, en comparación con los requisitos definidos en los SLAs

Métricas de procesos

  • Tiempo de respuesta a eventos y porcentajes de finalización.
  • Tiempos de resolución de incidentes en la segunda y tercera líneas de soporte.
  • Estadísticas de resolución de problemas.
  • Número de incidencias escaladas y razones que motivaron su escalado.
  • Número de cambios implementados y revertidos.
  • Número de cambios no autorizados que se detectaron.
  • Número de versiones desplegadas (total y exitosas)
  • Problemas de seguridad detectados y resueltos
  • Utilización real del sistema comparada con las previsiones del Plan de Capacidad.
  • Seguimiento de sesiones.
  • Gasto en comparación con el presupuesto
  • Rendimiento de aplicaciones. Estas métricas se basan en las especificaciones de la fase de Diseño y el rendimiento técnico contenido en los OLAs. Suelen incluir:
  • Tiempos de respuesta.
  • Disponibilidad de la aplicación.
  • Integridad de los datos e informes.
  • Métricas de las actividades de mantenimiento.
  • Mantenimiento llevado a cabo según la planificación.
  • Número de ventanas de mantenimiento que se prolongaron.
  • Objetivos de mantenimiento alcanzados (número y porcentaje)
  • Probabilidad de la colaboración entre los equipos de Gestión de Aplicaciones y los equipos de Desarrollo de Aplicaciones en proyectos. Métricas de:
  • Tiempo invertido en proyectos.
  • Satisfacción del cliente y el usuario con el entregable del proyecto.
  • Costes de involucrarse en el proyecto.
  • Formación y desarrollo de habilidades. Estas métricas garantizan que la plantilla tiene las habilidades y formación necesarias para gestionar la tecnología de la que son responsables, además de identificar áreas en las que se requiere formación adicional

ITIL: Fase Operación del Servicio (Primera Parte)

Los principales objetivos de la fase de Operación del Servicio incluyen:

  • Coordinar e implementar todos los procesos, actividades y funciones necesarias para la prestación de los servicios acordados con los niveles de calidad aprobados.
  • Dar soporte a todos los usuarios del servicio.
  • Gestionar la infraestructura tecnológica necesaria para la prestación del servicio

Los principales procesos asociados directamente a la Fase de Operación del Servicio son:

  • Gestión de Eventos
  • Gestión de Incidencias
  • Petición de Servicios TI
  • Gestión de Problemas
  • Gestión de Acceso a los Servicios TI
  1. Gestión de Eventos

El principal objetivo de la Gestión de Eventos, en su función de monitorizar todos los sucesos importantes, consiste en detectar y escalar condiciones de excepción para así contribuir a una operación normal del servicio:

  • Proporcionando puntos de entrada para varios procesos de la fase de Operación (p. ej. Gestión de Incidencias).
  • Posibilitando la comparación entre el rendimiento real del servicio con los estándares de diseño y los SLAs.
  • Contribuyendo a la Mejora Continua del Servicio mediante informes de mejora

Las actividades de la Gestión de Eventos son:

  • Aparición de eventos. El proceso se inicia cuando ocurre el suceso, ya sea detectado o no.
  • Notificación de eventos. El evento es notificado al equipo o responsable de gestión.
  • Detección y filtrado de eventos. La notificación llega a un agente o herramienta de gestión que la lee e interpreta el suceso con el fin de determinar si merece mayor atención o no.
  • Clasificación de eventos. Se le asigna una categoría y un nivel de prioridad.
  • Correlación. Se analiza si existen eventos similares, así como la importancia del evento en sí mismo y se decide si es necesario tomar medidas.
  • Disparadores. Se ponen en marcha los mecanismos necesarios para dar respuesta al evento.
  • Opciones de respuesta. Se eligen las soluciones a adoptar.
  • Revisión de acciones y cierre. Se revisan las excepciones o eventos importantes para determinar si se han tratado correctamente. Se cierra el proceso de Gestión de Eventos

A la hora de evaluar la eficiencia y efectividad del proceso de Gestión de Eventos deben verificarse los siguientes indicadores:

  • Número de eventos, por categorías.
  • Número de eventos, por importancia.
  • Número y porcentaje de eventos que requirieron de intervención humana y cómo fue esa intervención.
  • Número y porcentaje de eventos que desembocaron en el registro de una nueva incidencia o solicitud de cambio.
  • Número y porcentaje de eventos ocasionados por problemas ya existentes o errores conocidos.
  • Número y porcentaje de eventos repetidos o duplicados. Esto es relevante para optimizar la función de Correlación.
  • Número y porcentaje de eventos relacionados con problemas de rendimiento.
  • Número y porcentaje de eventos que indican futuros problemas de disponibilidad.
  • Número y porcentaje de cada tipo de evento, por plataforma o aplicación.
  • Número y ratio de eventos por comparación al número de incidentes.

2. Gestión de Incidencias

La Gestión de Incidencias tiene como objetivo resolver, de la manera más rápida y eficaz posible, cualquier incidente que cause una interrupción en el servicio.

La Gestión de Incidencias 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.

Procesos dentro de Gestión de Incidencias:

  • Registro y Clasificación
  • Clasificación
  • Análisis y Asignación
  • Cierre

La correcta elaboración de informes forma parte esencial en el proceso de Gestión de Incidencias. Considere los siguientes aspectos:

  • La Gestión de Niveles de Servicio: es esencial que los clientes dispongan de información puntual sobre los niveles de cumplimiento de los SLAs 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 deberán 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.

3. Gestión de Peticiones

  • Proporcionar un canal de comunicación a través del cual los usuarios puedan solicitar y recibir servicios estándar para los que existe una aprobación previa.
  • Proporcionar información a los usuarios y clientes sobre la disponibilidad de los servicios y el procedimiento para obtenerlos.
  • Localizar y distribuir los componentes de servicios estándar solicitados.
  • Ayudar a resolver quejas o comentarios ofreciendo información general.

Las actividades incluidas en el proceso de Gestión de Peticiones son:

  • Selección de peticiones. Los usuarios, a través de las herramientas destinadas a tal fin por la Gestión de Peticiones, emiten sus peticiones conforme a una serie de tipologías predefinidas.
  • Aprobación financiera de la petición. Dado que la mayoría de peticiones tienen implicaciones financieras, se considera su coste y se decide si tramitar la petición o no.
  • Tramitación. La petición es cursada por la persona o personas adecuadas según cada caso.
  • Cierre. Tras notificar al Centro de Servicios y comprobar desde aquél que el usuario ha quedado conforme con la gestión se procede a cerrarla.

Control del proceso

  • Número total de peticiones de servicio.
  • Ruptura de peticiones de servicio en cada etapa.
  • Tamaño de la copia de seguridad de las peticiones más destacadas.
  • Tiempo medio que dura la gestión de cada tipo de petición de servicio.
  • Número y porcentaje de peticiones de servicio completadas en los tiempos acordados.
  • Coste medio de cada tipo de petición de servicio.
  • Nivel de satisfacción del cliente con la gestión de las peticiones de servicio

4. Gestión de Problemas

Cuando algún tipo de incidente se convierte en recurrente o tiene un fuerte impacto en la infraestructura TI, es la función de la Gestión de Problemas el determinar sus causas y encontrar posibles soluciones.

Cabe diferenciar entre:

Problema: causa subyacente, aún no identificada, de una serie de incidentes o un incidente aislado de importancia significativa.

Error conocido: Un problema se transforma en un error conocido cuando se han determinado sus causas

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

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 Incidencias
  • 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 pueda permitir adoptar decisiones informadas sobre cambios de proveedores, etc.

ITIL: FASE TRANSICIÓN DEL SERVICIO (Segunda Parte)

6. Gestión de Entregas y Despliegues

  • 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 después de que la Validación y Pruebas las haya verificado en un entorno realista.
  • Garantizar que el proceso de cambio cumpla las especificaciones de la RFC correspondiente.
  • Asegurar, en colaboración con la Gestión de Cambios y la de Configuración y Activos TI, que todos los cambios se ven correctamente reflejados en la CMDB.
  • Archivar copias idénticas del software en producción, así como de toda su documentación asociada, en la DML.
  • Mantener actualizado el DS

Las versiones pueden clasificarse, según su impacto en la infraestructura TI, en:

Versiones mayores: que representan importantes despliegues de software y hardware y que introducen modificaciones importantes en la funcionalidad, características técnicas, etc.

Versiones menores: que suelen implicar la corrección de varios errores conocidos puntuales y que a menudo son modificaciones que vienen a implementar de una manera correctamente documentada soluciones de emergencia.

Versiones de emergencia: modificaciones que reparan de forma rápida un error conocido.

Informe

  • 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 y la DS.
  • Existencia de versiones ilegales de software.
  • Adecuado registro de las nuevas versiones en la CMDB.
  • 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.
  • Diseñar y mantener un entorno de pruebas, es decir, una réplica exacta del escenario en el que el servicio desarrolla su actividad.
  • Conocer a fondo las funcionalidades del servicio y mantener listados actualizados de todos los casos de uso para poder hacer chequeos completos.
  • Conocer a fondo los requisitos de calidad del servicio acordados con el cliente para poder garantizar que las nuevas versiones los cumplen.
  • Planificar y llevar a cabo un calendario de pruebas que cubra todas las funcionalidades registradas para el servicio.

7. Validación y Pruebas

  • Diseñar y mantener un entorno de pruebas, es decir, una réplica exacta del escenario en el que el servicio desarrolla su actividad.
  • Conocer a fondo las funcionalidades del servicio y mantener listados actualizados de todos los casos de uso para poder hacer chequeos completos.
  • Conocer a fondo los requisitos de calidad del servicio acordados con el cliente para poder garantizar que las nuevas versiones los cumplen.
  • Planificar y llevar a cabo un calendario de pruebas que cubra todas las funcionalidades registradas para el servicio.

Proceso

Las principales actividades de la Validación y Pruebas del Servicio se resumen en:

  • Validación de paquetes de servicios, ofertas y contratos. Definición del modelo de pruebas, la planificación y los protocolos de testeo.
  • Construcción del escenario de pruebas y acceso a los elementos a probar.
  • Pruebas de las nuevas versiones en un entorno idéntico al entorno real de desarrollo del servicio nuevo o mejorado.
  • Aceptación de los datos y elaboración de informes de resultados que registren los errores, de haberse producido.
  • Limpieza del entorno de pruebas y cierre del proceso.

Evaluación

El objetivo principal de la Evaluación consiste en proporcionar la información suficiente para determinar con seguridad si un aspecto del servicio es útil para el negocio, ya sea porque incrementa su calidad o porque proporciona una mejora en la productividad.

Las actividades de la Evaluación se resumen en:

Planificación de la evaluación, que consiste en analizar los efectos, tanto previstos como imprevistos, de la puesta en marcha de un cambio o nuevo servicio.

Evaluación del rendimiento previsto. Se realiza antes de implementar el cambio y consiste en predecir los efectos que éste tendrá una vez esté operativo.

Evaluación del rendimiento real. Se realiza una vez el cambio ha sido ya implementado, y consiste en analizar los efectos que ha provocado su puesta en marcha.

El proceso de Evaluación puede medirse a través de los siguientes indicadores:

  • Número de evaluaciones solicitadas para nuevos servicios o cambios en un periodo determinado.
  • Número de evaluaciones entregadas en un periodo determinado.
  • Número de evaluaciones que permanecen en la cola de tareas.
  • Tiempo medio de elaboración de una evaluación desde que ésta es solicitada hasta que se entrega.
  • Desviación de las evaluaciones de rendimiento previsto respecto de las evaluaciones reales.

8 Gestión del Conocimiento

  • Garantizar que el personal hace uso de las herramientas, tanto para registrar como para consultar los datos disponibles.
  • Evaluar los datos recogidos, velando por que estén permanentemente actualizados.
  • Analizar las necesidades de información de ciertos departamentos y coordinar la correcta transferencia de conocimiento desde aquellos que poseen los datos

Proceso

Las principales actividades de la Gestión del Conocimiento se resumen en:

  • Definir una estrategia de Gestión del Conocimiento y difundirla a toda la organización TI.
  • Ayudar a la transferencia de conocimiento entre personas, equipos y departamentos.
  • Gestionar la información y los datos para garantizar su calidad y utilidad.
  • Uso del SKMS.

Control del proceso.  Indicadores.

  • Número de solicitudes de entradas nuevas recibidas en un periodo específico.
  • Número de solicitudes de modificaciones enviadas en un periodo específico.
  • Número de entradas nuevas publicadas en la base de datos en un periodo específico.
  • Número de entradas modificadas en la base de conocimiento en un periodo específico.
  • Número de incidentes que recurrieron a entradas existentes en la base de conocimiento en un periodo específico.
  • Tiempo ahorrado gracias al uso de la base de conocimiento.
  • Número de peticiones de autoayuda que declararon que la base de conocimiento ayudó en la resolución de un asunto en un periodo determinado.

Para que la implementación sea un éxito:

  • Se deben analizar los problemas surgidos en el pasado debidos a una deficiente implementación de los cambios.
  • Se debe comunicar adecuadamente a clientes y miembros de la organización TI las ventajas asociadas y como una correcta gestión de la Transición podría haber evitado estas situaciones.
  • La puesta en marcha debe ser incremental incorporando la fase de Transición principalmente a nuevos servicios y proyectos evitando en lo posible interferencias con proyectos ya consolidados o en marcha.

ITIL: FASE TRANSICIÓN DEL SERVICIO (PRIMERA PARTE)

Fase:  Transición del Servicio

  • Planifique todo el proceso de cambio.
  • Cree los entornos de pruebas y preproducción necesarios.
  • Realice todas las pruebas necesarias para asegurar la Adecuación del nuevo servicio a los requisitos predefinidos.
  • Establezca planes de roll-out (despliegue) y roll-back (retorno a la última versión estable).
  • Cierre el proceso de cambio con una detallada revisión post-implementación.

¿Cuáles son los Subprocesos a evaluar en esta fase?:

  • Planificación y soporte a la Transición
  • Gestión de Cambios
  • Gestión de la Configuración y Activos del Servicio
  • Gestión de Entregas y Despliegues
  • Validación y pruebas
  • Evaluación
  • Gestión del Conocimiento
  1. Planificación y Soporte a la Transición

Transicion1.png

Estrategia de transición

  • Contexto de prestación del servicio.
  • Requisitos externos que deban tenerse en cuenta (estándares, legislación vigente, acuerdos contractuales, etc.).
  • Organizaciones y terceros interesados (socios estratégicos, proveedores, etc.)
  • Marco de trabajo a adoptar (políticas, protocolos de autorización, etc.)
  • Roles y responsabilidades. Requisitos de formación de la plantilla involucrada.
  • Planificación de hitos y entregables. Frecuencia de entrega.
  • Convenios de nomenclatura que se han adoptado para denominar las entregas (p. ej. “versión 1.1.3.65”)
  • Criterios de evaluación y de aceptación de las RFCs.
  • Criterios para dar por concluido el soporte post-implantación (ELS).

La preparación consiste en una revisión general de toda la información recabada, así como de los elementos (recursos materiales, personal interno, proveedores, etc.) que intervendrán en la ejecución de los cambios.

  • Revisión y aceptación de los inputs procedentes del resto de procesos del Ciclo de Vida.
  • Revisión y comprobación del paquete de diseño del servicio (SDP) creado en la fase de Diseño.
  • Revisión de los SACs.
  • Identificación, desarrollo y planificación de las peticiones de cambio (RFCs).
  • Comprobación de que la Gestión de la Configuración está actualizada.
  • Comprobación de que la Transición está preparada para llevarse a cabo.

Transicion2

Control del proceso

El propietario de este proceso es el Jefe de Proyecto (Project Manager). En él recae la responsabilidad de controlar y medir los siguientes indicadores:

Número de proyectos gestionados. Es decir, el número de versiones desplegadas (rollout) que han sido objeto de planificación y soporte.

Porcentaje de entregas (respecto al total de entregables) que se ajustaron a lo acordado con el cliente en cuanto a coste, calidad y alcance.

Ajuste al presupuesto del proyecto, comparando el consumo de recursos humanos y financieros previstos con los que se usaron realmente.

Retrasos en proyectos, comparando las fechas de entrega reales con las que en un principio se habían definido en la planificación

 

2. Gestión del Cambio

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.
  • Pueden deshacerse mediante planes de “retirada del cambio” (back-outs) en caso de un incorrecto funcionamiento tras su implementación.

Transicion3.png

  • Registrar, evaluar y aceptar o rechazar las RFCs recibidas.
  • Planificación e implementación del cambio
  • Convocar reuniones del CAB, excepto en el caso de cambios menores, para la aprobación de las RFCs y la elaboración del FSC.
  • Evaluar los resultados del cambio y proceder a su cierre en caso de éxito.

3. Registro de Peticiones

Transicion4

Para su aprobación, el cambio se debe evaluar minuciosamente:

  • ¿Cuáles son los beneficios esperados del cambio propuesto?
  • ¿Justifican esos beneficios los costes asociados al proceso de cambio?
  • ¿Cuáles son los riesgos asociados?
  • ¿Disponemos de los recursos necesarios para llevar a cabo el cambio con garantías de éxito?
  • ¿Puede demorarse el cambio?
  • ¿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?

4. Gestión del Cambio

Control de Proceso:

  • RFCs solicitados.
  • Porcentaje de RFCs 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

5. Gestión de la Configuración y Activos del Servicio}

  • Proporcionar información precisa y fiable al resto de la organización de todos los elementos que configuran la infraestructura TI.
  • Mantener actualizada la Base de Datos de Gestión de Configuración y Activos TI:
  • Registro actualizado de todos los CIs: identificación, tipo, ubicación, estado…
  • Interrelación entre los CIs.
  • Servicios que ofrecen los diferentes CIs.
  • Servir de apoyo a los otros procesos, en particular, a la Gestión de Incidencias, Problemas y Cambios.

Proceso

Las principales actividades de la Gestión de la Configuración y Activos TI son:

  • Planificación.
  • Clasificación y Registro.
  • Monitorización y Control.
  • Realización de auditorías.
  • Elaboración de informes.

Planificación

  • Designar un responsable: una descentralización excesiva puede generar descoordinación y llevar al traste todo el proceso.
  • Invertir en alguna herramienta de software adecuada a las actividades requeridas: una organización manual es impracticable.
  • Realizar un cuidadoso análisis de los recursos ya existentes: gestión de stocks, activos, etc.
  • Establecer claramente:
  • El alcance y objetivos.
  • El nivel de detalle.
  • El proceso de implementación: orden de importancia, cronograma…
  • Coordinar el proceso estrechamente con la Gestión de Cambios, Gestión de Entregas y Despliegues y los Departamentos de Compras y Suministros.

Clasificación y Registro

  • Los objetivos sean realistas: una excesiva profundidad o detalle puede sobrecargar de trabajo a la organización y resultar, a la larga, en una dejación de responsabilidades.
  • La información sea suficiente: debe existir, al menos, un registro de todos los sistemas críticos para la infraestructura TI.

Monitorización

Transicion5.png

Las tareas de control Cis, deben centrarse en:

  • Asegurar que todos los componentes están registrados en la CMDB.
  • Monitorizar el estado de todos los componentes.
  • Actualizar las interrelaciones entre los CIs.
  • Informar sobre el estado de las licencias

Auditorías

El objetivo de las auditorías es asegurar que la información registrada en la CMDB coincide con la configuración real de la estructura TI de la organización.

Las auditorías deben dedicar especial atención a aspectos tales como:

  • Uso correcto de la nomenclatura en los registros de los CIs.
  • Comunicación con la Gestión de Cambios: información sobre RFCs , cambios realizados, etc.
  • Estado de los CIs actualizado.
  • Cumplimiento de los niveles de alcance y detalle predeterminados.
  • Adecuación de la estructura de la CMDB con la de la estructura TI real.

Documentación

  • Alcance y nivel de detalle de la CMDB.
  • Desviaciones entre la información almacenada en la CMDB y la obtenida de las auditorias de configuración.
  • Información sobre CIs que han estado involucrados en incidentes.
  • Costes asociados al proceso.
  • Sistemas de clasificación y nomenclatura utilizados.
  • Informes sobre configuraciones no autorizadas y/o sin licencias.
  • Calidad del proceso de registro y clasificación.
  • Información estadística y composición de la estructura TI.

ITIL Diseño del Servicio (segunda parte)

Gestión del Riesgo

Identificar, evaluar y controlar riesgos. Esto incluye el análisis del valor de los activos de la empresa, la identificación de amenazas a dichos activos y la evaluación de su vulnerabilidad ante esas amenazas.

Términos ITIL para Gestión del Riesgo

Análisis del Impacto y Riesgo al Negocio: El Análisis de Impacto Empresarial (Business Impact Analysis, BIA) identifica las Funciones Empresariales Vitales (Vital Business Functions, VBF) y sus dependencias. Estas dependencias pueden incluir Proveedores, individuos, otros procesos de negocio, servicios, etc. El Análisis del Riesgo identifica las amenazas y vulnerabilidades de los activos de la empresa e indica el nivel de vulnerabilidad de cada activo ante determinadas amenazas.

Valoración de Procesos y Activos: Es el estimado del valor que un proceso u otro activo representa para la empresa. Este valor es importante para el Análisis del Riesgo.

Registro de Riesgos: Es una herramienta usada en el proceso de Gestión del Riesgo para tener una idea general de ciertos riesgos y sus respectivas contramedidas.

Subproceso_riesgo

Gestión de la Capacidad

Sistema de Información de Gestión de la Capacidad (CMIS) es un depósito virtual de todos los datos de Gestión de la Capacidad, usualmente almacenados en varias localidades físicas.

Plan de Capacidad Se usa para gestionar los recursos requeridos para prestar los servicios de TI requeridos. Contiene escenarios de posibilidades según distintas predicciones de demanda de servicios, así como opciones y sus costos para cumplir con los niveles de servicio acordados.

Informe de la Capacidad Provee información relacionada con factores de uso y desempeño a otros procesos de Gestión de Servicios y la dirección de TI.

Sugerencia para Influir en la Demanda de Servicios Se trata de una sugerencia para influir en la demanda de capacidad de servicios. Usualmente la propone el Gestor de la Capacidad y se lleva a cabo durante la revisión del servicio.

Gestion_capacidad

Gestión de la Disponibilidad

Gestion_Disponibilidad1

Gestion_Disponibilidad2

Gestion_continuidad

Gestion_continuidad2

Gestión de la Seguridad de la Información

Gestion_seguridad.png

Gestion_seguridad2

Términos ITIL para Gestión de la Seguridad

Política de Seguridad de TI Establece reglas vinculantes para el uso de servicios y de sistemas con miras a mejorar la seguridad de TI.

Informe de Seguridad de TI  Provee información sobre asuntos de Seguridad de TI a los procesos de Gestión de Servicios y la dirección de TI.

Estrategia de Seguridad de TI  Contiene una guía de acercamiento para procurar la seguridad de los sistemas y servicios de TI. Incluye una lista de riesgos de seguridad y de Controles de Seguridad existentes o planificados para el manejo de riesgos.

Advertencias de Seguridad Es una lista de vulnerabilidades de seguridad conocidas y compiladas gracias a la aportación de proveedores de productos externos. La lista contiene instrucciones para medidas preventivas y para el manejo de infracciones de seguridad una vez ocurran

Alerta de Seguridad Se trata de una advertencia producida por la Gestión de la Seguridad de TI que generalmente se hace pública cuando se prevé el surgimiento de infracciones de seguridad o cuando ya están ocurriendo. Se busca asegurar que los usuarios y el personal de TI sean capaces de identificar cualquier ataque y de tomar medidas de precaución.

Sistema de Información de Gestión de la Seguridad (SMIS) Es un depósito virtual de todos los datos de Gestión de la Seguridad de TI, generalmente almacenados en varias localidades físicas.

Gestión de Proveedores (Suministradores)

Gestion_Proveedores1.png

Gestion_Proveedores2.png

Términos ITIL para Gestión de Proveedores

Orden de Compra Es una orden para comprarle artículos a algún suministrador. Si se trata de un pedido para un Servicio de Soporte cuyas provisiones son de origen externo, la orden de compra debe estar acompañada de un Contrato de Apoyo (UC) en el que se definan los niveles de servicio propuestos.

Requisición de Compra Es un pedido para la compra de un producto o de un servicio a un suministrador externo. Puede ser emitido, por ejemplo, por Gestión de Ediciones durante la Construcción de Servicios. El procesamiento de una Requisición de Compra por lo general se lleva a cabo sólo si el solicitante cuenta con una partida presupuestaria aprobada para la compra.

Modificaciones Requeridas a los Contratos de Apoyo Es un pedido generado en algún proceso de Gestión de Servicios para hacer cambios a un Contrato de Apoyo (UC). Esta requisición casi siempre es enviada de la Gestión de Nivel de Servicio a la Gestión de Proveedores si se requiere un servicio nuevo o la modificación de Servicios de Soporte externos.

Términos y Condiciones Estándar Generalmente, este conjunto de términos y condiciones va unido a contratos y pedidos cuando se solicitan servicios o productos nuevos.

Base de Datos de Proveedores y Contratos (SCD) Es una base de datos o documento estructurado que se usa para gestionar contratos a proveedores a lo largo de su ciclo de vida. La Base de Datos de Proveedores y Contratos (Supplier and Contract Database, SCD) contiene atributos clave de todos los contratos y Proveedores, por lo que debe formar parte del Sistema de Gestión del Conocimiento en Servicios (SKMS).

Revisión de Proveedores y Contratos La revisión de Revisión de Proveedores y Contratos evalúa el rendimiento logrado vs. acordado por parte de los proveedores. También contiene deficiencias o problemas identificados en el suministrador, así como sugerencias para mejorar la situación.

Evaluación a Proveedores El documento resultante de la Evaluación a Proveedores describe detalladamente los criterios usados para la evaluación y selección de un proveedor adecuado.

Estrategia de Proveedores Establece guías para la obtención de bienes y servicios. Incluye criterios de selección de Proveedores adecuados y una lista de Proveedores preferidos.

Contrato de Apoyo (UC) Es un contrato entre el proveedor de servicios de TI y un tercero. El tercero brinda apoyo en los servicios ofrecidos a clientes. El Contrato de Apoyo (Underpinning Contract, UC) define objetivos y responsabilidades necesarias para cumplir con los niveles de servicio acordados en un Acuerdo de Nivel de Servicio.

 

ITIL FASE II: DISEÑO DEL SERVICIO (PRIMERA PARTE)

Metas y Objetivos:

Diseñar nuevos servicios de TI. Esto incluye el diseño de servicios nuevos, así como cambios y mejoras de los existentes

Valor para el Negocio:

  • Contribuir a los objetivos del negocio
  • Contribuir al ahorro de tiempo y dinero
  • Minimizar o prevenir riesgos
  • Contribuir a satisfacer necesidades presentes y futuras del mercado
  • Evaluar y mejorar la eficacia y eficiencia de los servicios de TI.
  • Apoyar el desarrollo de políticas y estándares para los servicios de TI
  • Contribuir a mejorar la calidad de los servicios de TI

Diseñar nuevos servicios de TI. Esto incluye el diseño de servicios nuevos, así como cambios y mejoras de los existentes . Que debemos resolver:

  1. ¿Cuáles son los requisitos y necesidades de nuestros clientes?
  2. ¿Cuáles son los recursos y capacidades necesarias para prestar los servicios propuestos?
  3. ¿Los servicios son seguros, ofrecen la disponibilidad necesaria y se garantiza la continuidad del servicio?
  4. ¿Son necesarias nuevas inversiones para prestar los servicios con los niveles de calidad propuestos?
  5. ¿Están todos los agentes involucrados correctamente informados sobre los objetivos y alcance de los nuevos servicios o de las modificaciones a realizar en los ya existentes?
  6. ¿Se necesita la colaboración de proveedores externos?

4p.png

A fin de garantizar e integrado entorno coherente en los procesos de TI y las actividades y, básicamente, en toda la organización un enfoque holístico debe ser desarrollada y aprobada en el servicio de diseño. Tal actitud se asegurará de alta calidad de los servicios prestados, así como a extremo de continuidad de negocio de gama.

Para asegurarse de que el diseño de servicios esté debidamente aprobada hay cuatro P que deben ser considerados cuando se trata de diseño de servicios:

La gente (People)tiene que tener las habilidades y competencias poper posee con el fin de participar en la prestación de servicios de TI

Productos (Products)que están en la gestión de los sistemas de tecnología utilizada en el proceso de prestación de servicios de TI

Procesos (Processes )de funciones y actividades tienen que estar en estrecha relación el uno al otro

Socios (Partners) que son los principales proveedores, 3 empresas de software, fabricantes, proveedores involucrados en la prestación de servicios de TI

diseño del servicio.png

Habíamos explicado en el post anterior sobre Service Strategy (Estrategia del Servicio) que se encargaba primordialmente de analizar lo que le vamos a brindar al cliente (Gestión del Portafolio del Servicio), cuanto demanda el servicio brindado (Gestión Financiera) y analizar a cuantos clientes se provee el servicio (Gestión de la demanda); pues bien después de haber analizado el rubro de la organización y de decidir ¿Cómo? le vamos a brindar el servicio ahora toca diseñar el servicio, es aquí donde entra en acción: Service Design (SD).

Definición

Service Design (SD) diseña los servicios de TI que se va a brindar, esto incluye: arquitecturas, procesos, políticas y documentación; para cubrir con el actual SLA y las futuras necesidades (Integración con el negocio), es decir y para entenderlo mas claro aun, lo que hace SD es trasladar los planes estratégicos y objetivos que se decidió en SS, hacia la creación de diseños y especificaciones (procesos y políticas) que luego serán ejecutados en las fases de Transición y Operaciones.

Vamos a poner un ejemplo : Una organización que necesita almacenar información de sus clientes y nosotros como expertos en TI mediante la Estrategia del Servicio hemos decidido brindar los siguientes servicios: un SGBD (Sist. Gestor de BD) y un sistema web en la nube; después de haber tomado esta decisión entra Diseño del Servicio y su trabajo es:

Crear políticas: Por ejemplo, el backup de la BD se hace al medio día y a la media noche y se almacena en un lugar externo al de la empresa (obviamente se deben crear mas políticas).

Diseño de arquitectura

Apoyar al diseño del portafolio: SD apoya a SS en la creación del portafolio, imagínense que el jefe de IT que esta negociando el servicio que va a brindar (SS) y el cliente solicita un servicio bajo Red Hat Linux para su BD y aplicación, entonces el jefe de IT acepta pero luego se da cuenta que ellos no cuentan con personas especialistas en Red Hat, es obvio que esto no puede pasar, por eso SD  apoya en el diseño del portafolio advirtiendo que no se puede brindar servicios de Linux debido a que no se cuenta con personal capacitado para esta actividad.

Tecnología efectiva: ¿Qué usamos? un switch CISCO o un switch no administrable.

Diseño de proceso y sus métricas: El proceso son los pasos detallados para implementar el servicio, por ejemplo:

Paso 1: Instalar el SO bajo ciertas caracterices

Paso 2: Instalar JAVA o PHP de la siguiente manera

Paso 3: Instalar la BD: MySQL o Oracle con los siguientes parámetros

Paso 4: ……..

¿Y todo esto para qué es necesario?

Obviamente tener todo organizado tiene sus ventajas económicas y esto se refleja en el TCO (Costo total de la propiedad), por ejemplo el TCO de una computadora es:

Hardware + Software + Servicio recibido.

Tener documentado paso por paso MEJORA LA CALIDAD DEL SERVICIO, MEJORA LA CONSISTENCIA DEL SERVICIO y MEJORA EL GOBIERNO CORPORATIVO.

Actividades de SD

Gestión del Portafolio del Servicio

Identificación de los requerimientos del negocio, definición y diseño del servicio

Diseño de la arquitectura tecnológica

Diseño del proceso

Diseño de las métricas

¿QUE VAMOS A GESTIONAR EN ESTA FASE?

DISEÑO2.png

DISEÑO3

Gestión del Portafolio del Servicio (SPM): El dueño de este proceso no es SD sino SS, es decir SS aprueba el portafolio de servicio que se va a brindar al cliente pero es obvio que necesita del apoyo de SD para conocer precios, fortalezas, oportunidades, debilidades y amenazas del servicio.

Identificación de los requerimientos del negocio, definición y diseño del servicio: Para poder apoyar a la SPM primero necesitamos saber que requiere el negocio con exactitud y recién sabiendo que quiere el cliente podemos diseñar el servicio, evaluar las alternativas de diseño y conocer los costos que este implica.

Diseño de la arquitectura tecnológica: Hace referencia al diseño arquitectónico y la arquitectura empresarial.

Diseño del proceso: El proceso responde a la pregunta: ¿Qué hago primero? ¿Qué hago en segundo lugar?, un proceso es conjunto estructurado de actividades para cumplir un objetivo. No olvidemos que un proceso incluye cosas muy importantes como: roles, responsabilidades, herramientas y el control del proceso.

Un proceso incluye no solo los pasos generales a seguir sino también las normas a seguir en caso de excepciones, además de dueños del proceso y salidas cuantificables. ITIL exige que todo resultado de un proceso sea medible para poder incluirlo en la mejora continua.

Diseño de las métricas: Si un proceso no puede ser medido no puede ser gestionado ni mejorado por lo que lo importante aquí no es el concepto de medición sino saber ¿Cómo medir? y no existe una respuesta exacta a esta pregunta porque saber como medir un proceso depende del servicio implementado y del rubro del negocio, es decir debe estar alienado con los objetivos del negocio.

DISEÑO4

DISEÑO5

DISEÑO6

DISEÑO7

DISEÑO8

Hablemos de ITIL – Introducción #ITIL #Servicio #ProcesosTI

1

Las organizaciones hoy se preparan para escenarios donde la flexibilidad y el dinamismo son cruciales para sobrevivir a los cambios en el mercado; lo que implica que al apoyarnos en las Tecnologías de la Información  busquemos beneficios tangibles a corto plazo como: reducción de costos en la integración de múltiples sistemas, estandarizar procesos y mejorar la calidad de los servicios que se entregan al negocio. ITIL nos enfoca a centrarnos y alinearnos con el negocio. ITIL es un marco de mejores practicas para la entrega de Servicios. No es una metodología paso a paso,  Es un framework del que tomas las piezas que quieras utilizar y obvias el resto si quieres. Es importante destacar que en un marco económico como el actual la adopción de ITIL se ve como una forma de buscar eficiencia operacional.

Con Itil Versión 3 se fortaleció el enfoque de profundizar las problemáticas de los departamentos de TI y se proporcionó métricas de rendimiento y ejemplos de flujos de trabajo.  La actualización 2011 aborda mejor el registro de control de cambios y resuelve los errores de texto y diagramas de proceso

Que hace ITIL para que lo considere tan mágico?

  • Alinea TI con el negocio
  • Mejora la calidad del servicio de TI.
  • Reduce los costos de provisión del servicio
  • Promueve el trabajo en equipo

ITIL Considera los 4 elementos básicos de toda organización (People, processes, products and partners) disculpen el Ingles, las 4Ps son mas fáciles de recordar. Según el Gartner Group, su implantación puede dar ahorros de mas del 20% en los gastos de operaciones de TI.

2

No cabe duda que las tecnologías son un factor fundamental para alcanzar los objetivos corporativos de las organizaciones, donde es notable la dependencia que se ha generado en torno a ellas debido a que las tecnología se involucran con mas frecuencia en los procesos core del negocio.

Desde este punto de vista justificamos que el negocio demanda un cambio en la forma de trabajar en esta área; un cambio que genere  la calidad, confiablidad, consistencia pero sobre todo el eficacia que el negocio exige para poder seguir funcionando en un mercado tan dinámico como el actual.

Claro esta que todo esto se debe brindar  costos aceptables para el negocio.

Es por lo anterior que las áreas de tecnología en las compañías ya no pueden seguir desempeñándose desde la informalidad.  Es el momento de entender que los departamentos de tecnología son un departamento mas de la empresa que requiere una forma organizada de trabajo, estructurada y capas de ser medida así como  lo puede ser perfectamente el departamento financiero, un departamento de mantenimiento e incluso un departamento de ventas.

Razones que nos empujan a un cambio de paradigma, dejar de pensar que la tecnología es un producto, mientras veamos la tecnología como producto siempre será un comodín perdiendo el valor estratégico para la empresa, para dar paso a un pensamiento alrededor de las tecnologías que se base justamente en ver estas áreas de tecnología como una compañía prestadora de servicio al interior de otra compañía.

Ahora que ya hemos mencionado a las áreas de TI como un prestador de servicios podemos definir servicio de tecnología como la entrega de valor para el cliente visto en función de todas aquellas facilidades tecnológicas que le permiten alcanzar los resultados que quieren pero sin que el sea el dueño del riesgo ni el costo asociado que puede manejar este servicio

Ejemplo Servicio Publico

Las empresas de Servicio publico agua, electricidad, aseo nos brindan un servicio que se traduce en un costo, no comparte con nosotros los riesgos de fallas de equipos, mantenimientos, reparaciones, pero nos brindan el servicio tratando de estar operativos en un 100%, siendo para nosotros transparentes su funcionamiento interno.

3

Esta forma de pensar ha creado toda una disciplina que se denomina la gestión de servicios de tecnología IT Service managment, no es mas que la gestión optimizada que se realiza sobre un conjunto de capacidades organizacionales especiales que trabajan juntos para proveer valor al cliente en términos de servicios de tecnología llamen a estas capacidades de software, capacidades de comunicaciones, capacidades de infraestructura, etc, es la forma de gestionar todas estas capacidades de forma optima.

Resumen de Historia de ITIL:

4

 

5

Certificación ITIL:  Cabe destacar que existen tres niveles de certificación ITIL para profesionales:

Certificación ITIL Fundamentos:

El nivel de Fundamentos de ITIL® hace foco en las fases de los servicios del Ciclo de Vida y en sus procesos y funciones. La certificación de Fundamentos es un pre-requisito para el siguiente nivel de cursos: Niveles Intermedios. La obtención de la certificación de Fundamentos equivale a 3 créditos dentro del esquema ITIL® para poder alcanzar el Nivel ITIL® Expert.

Certificación ITIL Niveles Intermedios

El Nivel Intermedio de ITIL ofrece dos rutas principales de Formación: El Ciclo de Vida (Lifecycle) y de Capacidad (Capability) – cada uno cuenta con su propia serie de certificaciones y un módulo final de la racionalización: Managing Across the Lifecycle (MALC).

Certificación ITIL Expert

El nivel de Certificación ITIL® Expert se dirige a aquellas personas que están interesadas en demostrar un nivel superior de conocimientos de ITIL® en su totalidad.

7

Ahora bien, antes debemos responder lo que en muchas organizaciones nos preguntan ¿ITIL o Cobit?:  Eso va a depender de quien este remando dentro de la organización.  Generalmente ITIL viene de la mano de la dirección de Tecnologia y Cobit viene de la mano de los auditores, si estamos en una organización que se esta siendo auditados, donde se deben  presentar estados financieros, análisis de posibilidades de fraude entre otros se debe implementar Cobit.

Los procesos de Cobit se enfocan en los requerimientos de la empresa y proporcionan una guía para determinar lo que se necesita para cumplir con esos requerimientos.  ITIL define los procesos considerados “mejores prácticas” para la administración de las TIC, se enfoca en el método y define un conjunto de procesos más detallado que COBIT ya que nos indica una ruta para la construcción de procesos.

ITIL  es parte de la base de COBIT, el cual define los objetivos de control de TI los cuales a su vez dan soporte a los procesos de negocio.

Con la combinación de ITIL y COBIT, las organizaciones de TIC dentro de las empresas pueden lograr cumplir con los objetivos que les plantea la empresa y lo hacen al mismo tiempo que entregan servicios de alta calidad a bajo costo.

ITIL es el conjunto de practicas de administración de los Servicios.  Estas practicas para dar soporte a la entrega de los servicios pueden ayudar a una compañía a documentar sus procesos de TIC

ITIL Proporciona unas guias acerca de lo que debe hacerse para lograr la mejor practica y COBIT tiene mas que ver con probar y establecer un conjunto de objetivos para asegurar el control.

COBIT es como una herramienta de auditoria y monitoreo para determinar si las cosas se han hecho bien.

ITIL fortalece los procesos de entrega y soporte; describe como estructurar los procesos operativos pero su debilidad principal son los controles de seguridad.

COBIT se enfoca en los controles y métricas.  Tambien le hace falta la seguridad, pero proporciona una visión mas global de los procesos de TI que la proporciona ITIL.

La Direccion de TIC en las empresas actualmente tienen mucha presión en cuanto a la aportación que hacen a las metas del negocio.

Aprender ITIL y COBIT te permitirá:

Administrar las TIC desde una perspectiva de negocio para lograr las metas de la empresa

Establecer metas claras para los procesos, basándose en las metas de la empresa

Asegurar un gobierno de TIC efectivo

Establecer controles a nivel de procesos

Habilitar a los departamentos de TIC a demostrar como cumplen o exceden los requerimientos.

Al formar nuestro equipo de trabajo con ITIL serán capaces por ejemplo de diferenciar entre un incidente (que requiere de atención inmediata y restauración del servicio para que el negocio continue operando) de un problema (que debe ser analizado hasta encontrar la causa raíz y su acción correctiva irreversible).

¿Que tal si este mismo grupo diseña e implementa un mapa tecnológico (CMDB) de todos los componentes involucradosen la prestación del servicio? por lo que es muy fácil detectar que parte del servicio es afectada cuando un componente falla. El resultado de implementar y ejecutar los procesos ITIL siempre será una muy alta calidad en operación y prestación delservicio así como reducción de costos durante todo el ciclo de vida del servicio. Es muy importante revisar a fondo estas estrategias especialmente en estos tiempos de crisis

8

Si TI se va a gestionar como un negocio dentro del negocio, el concepto de gobierno (proceso en el que se ayuda la gerencia para conseguir sus objetivos) es también aplicable a la gestión de TI. En muchas organizaciones, TI es fundamental para mantener y hacer que crezca el negocio. Como consecuencia, la gerencia necesita entender la importancia estratégica de TI y debería tener en su agenda el gobierno de TI. El principal objetivo del gobierno de TI es entender las cuestiones y la importancia estratégica de TI para permitir a la organización que mantenga sus operaciones e implemente las estrategias necesarias para sus proyectos y actividades futuras

El Gobierno de TI provee las estructuras que unen los procesos de TI, los recursos de TI y la información con las estrategias y los objetivos de la empresa. Además, el Gobierno de TI integra e institucionaliza buenas (o mejores) prácticas de planificación y organización, adquisición e implementación, entrega de servicios y soporte, y monitoriza el rendimiento de TI para asegurar que la información de la empresa y las tecnologías relacionadas soportan sus objetivos del negocio. El Gobierno de TI conduce a la empresa a tomar total ventaja de su información logrando con esto maximizar sus beneficios, capitalizar sus

oportunidades y obtener ventaja competitiva.

9

El Ciclo de Vida del Servicio consta de cinco fases que se corresponden con los nuevos libros de ITIL:

Estrategia del Servicio: propone tratar la gestión de servicios no sólo como una capacidad sino como un activo estratégico.

Diseño del Servicio: cubre los principios y métodos necesarios para transformar los objetivos estratégicos en portafolios de servicios y activos.

Transición del Servicio: cubre el proceso de transición para la implementación de nuevos servicios o su mejora.

Operación del Servicio: cubre las mejores prácticas para la gestión del día a día en la operación del servicio.

Mejora Continua del Servicio: proporciona una guía para la creación y mantenimiento del valor ofrecido a los clientes a traces de un diseño, transición y operación del servicio optimizado.

 

Ejemplo: Recolección de Datos Catalogo de Servicios

Compartiendo con participantes en adiestramientos, al momento de conversar sobre el catalogo de servicios se hacen generalmente la misma pregunta, ¿que consideramos al momento de comenzar a construir el catalogo de servicios? que preguntas debemos respondernos.

A continuación algunos de los elementos que me han sugerido mis estudiantes a considerar a la hora de crear un formato para recabar información inicial para crear un catalogo de servicio:

1. Nombre del Servicio

2. Descripcion del servicio

3. Fechas de Versión / Revisión

4. Quien usa el servicio (clientes)

5. Existen otros involucrados (¿quienes?)

6. Quien es el propietario del servicio (de la unidad quien lo administra)

7. Quien es el proveedor de servicio

8. Cual es el acuerdo que el proveedor de servicio tiene con la empresa (acuerdos de atencion) SLA

9. Cual es el acuerdo del administrador del servicio con el cliente (tiempos de respuestas) OLA

10. Cuales son los precios de mantenimiento soporte de este servicio (contrato con proveedor)

11. Quien evalua los cambios sobre el servicio (Control de Cambios Involucrados)

12. En que servidor esta instalado ese servicio, detalles técnicos de configuración

13. Cual es el minimo requerimiento de hardware que demanda el software

14. Todo el entorno de software que acompana a la aplicacion, configuracion inicial

 

Definición de la estructura de servicios ITIL V3

Cualquier iniciativa ITIL debe comenzar determinando los servicios. Después de todo, la razón principal para introducir ITIL es lograr un mayor enfoque en los servicios.

Servicios de negocios y servicios de soporte

La mejor manera de tener un cuadro claro de los mismos es desarrollar una estructura que incluya los servicios de negocios y los de soporte. Esto refleja uno de los principios más importantes de ITIL: Los servicios de negocios (ofrecidos a clientes) se construyen en una base de servicios de soporte (visible sólo internamente en la organización de TI).

Con frecuencia, hay confusión en las organizaciones de TI en cuanto a qué se considera un servicio de negocios. Los servicios de negocios se caracterizan por representar un valor directo para el cliente, por ejemplo, el hecho de proveer correo electrónico y acceso a Internet.

Los servicios de soporte, por el contrario, no son de valor directo para los clientes sino que sirven de base para sostener los servicios de negocios.

En otras palabras, lo que el cliente quiere es acceso confiable a Internet, no algún tipo específico de infraestructura de redes (de hecho, es irrelevante para el cliente que sea necesaria una infraestructura de redes para proveerle acceso a Internet).

Creando una lista de servicios de negocios

Una buena manera de empezar es crear una lista de los servicios de negocios existentes, usando, si fuera posible, acuerdos e información previamente establecidos. Si no está disponible la información relacionada con los servicios, se debe crear una lista básica, que incluya al menos descripciones breves de servicios y clientes que los utilizan.

Determinando los servicios de soporte

Tan pronto esté claro cuáles son los servicios de negocios que se proveen a los clientes, es posible identificar los servicios de soporte necesarios.

Lo principal al definir los servicios de apoyo es asignar responsabilidades para el suministro de tales servicios. Se espera que los Propietarios de Servicios responsables se aseguren de que sus servicios cumplan con las metas de los niveles de servicio, según lo acordado.

Los servicios de soporte, con frecuencia, están relacionados estrechamente con ciertas partes de la infraestructura de TI, por ejemplo, con los sistemas principales de aplicaciones o componentes de la infraestructura: Un ejemplo típico sería “Proveyendo un ambiente de SAP”.

Definiendo la estructura de servicios

Ejemplo – La estructura de servicios.  Al haber identificado los servicios de negocios y soporte, la tarea que falta es crear una estructura de servicios determinando la interrelación entre ambos.

 

En ella se puede ver que los servicios de soporte están a menudo en escalas; por ejemplo, un servicio que es responsable de manejar cierto sistema de aplicaciones puede que dependa de otro servicio de soporte para proveer un sistema operativo básico.

Esta estructura servirá luego como una aportación valiosa para diseñar el Catálogo de Servicios.

Objetivos de este paso del proyecto

  1. Identificar los servicios de negocio y de soporte
  2. Crear la estructura de servicios determinando la interde-pendencia entre servicios de negocios y de soporte

Prerequisitos

  • Acuerdos e información existentes
  • Clientes participantes para definir los servicios de negocios

Resultados / Entregables

  1. Una lista de servicios de negocios, incluyendo al menos descripciones breves de servicios y clientes que las usan
  2. Una lista de servicios de soporte, incluyendo al menos descripciones breves de los servicios y los Propietarios de Servicios responsables de los mismos
  3. Estructura de servicios

Factores de éxito

Firmar con clientes Acuerdos de Nivel de Servicio (SLA) formales no tiene mucha importancia en esta etapa temprana del proyecto. Los SLA se concluyen como parte de Gestión del Nivel de Servicio (SLM), un proceso que se implementará más tarde, durante el curso del proyecto.

Para la mayoría de las organizaciones de TI, un número aproximado de 5 a 15 servicios de negocios debe ser adecuado. La estructura de servicios combina típicamente diferentes componentes de servicios relacionados para crear servicios de negocios. Así se pueden negociar paquetes completos con el cliente. De esta manera, por ejemplo, el servicio “Proveer PCs a clientes” puede contener, entre otros componentes:

  • instalación inicial
  • resolución de incidentes
  • asistencia para el usuario
  • actualizaciones de aplicaciones
  • actualizaciones de equipo
  • etc.

La estructura de servicios de TI que se definirá, sólo puede ser viable si se crea en estrecha coordinación con los clientes de la organización de TI. En las conversaciones iniciales con el cliente, los representantes de TI deben enfatizar su objetivo de mejorar la calidad del servicio, como meta del proyecto. Se debe evitar dar la falsa impresión de imponerle a un cliente un contrato que no le conviene.

Los servicios internos se deben estructurar de manera que sea posible asignar responsabilidades claras a los Propietarios de Servicios. Luego habrá Acuerdos de Nivel Operacional (OLA) con estos Propietarios de Servicios.