• Author / Uploaded
• Miguel Angel Rivera Aguilar

Citation preview

Introducción a ITIL y ITSM

La clásica imagen del MODELO DEL CICLO DE VIDA de ITIL v3 es la rueda que se muestra al lado derecho, cabe resaltar que ITIL v3 cuenta con sólo 5 libros:     

Service Strategy (Estrategia del Servicio) Service Design (Diseño de servicio) Service Transition (Transición de servicio) Service Operation (Operación de servicio) Continual Service Improvement (Servicio de Mejoramiento contínuo)

Certificación ITIL Algo no menos importante de mencionar es acerca de los niveles de certificación de ITIL, existen 3 niveles: 

ITIL FOUNDATION: La visión general de ITIL

 

Service Capability (Capacidad de Servicio): Focalizado en agrupamiento y expertice Service Manager (Gerente de Servicio): Focalizado en áreas de proceso

¿Qué es un servicio? Un servicio es un medio de entregar valor a los clientes a través de facilitar los resultados que ellos quieren lograr (los clientes) sin tener responsabilidad de los riesgos, administración y costos específicos. ¿Qué es Service Management (Gestión De Servicios)? ITSM (Information Technology Service Management - Servicio de Gestión de Información Tecnología) es un conjunto de capacidades que gestionan servicios en el ciclo de vida para entregarle al cliente servicios con un valor agregado; es decir ITSM es un conjunto de

procesos que son usados para administrar (estrategia, diseño, transición, operación y mejora continua) el servicio que le vamos a entregar al cliente. ¿Qué es un proceso? Es un conjunto coordinado de actividades, que combinan e implementan recursos y capacidades para producir un resultado que crea un valor en el cliente. Otras características de un proceso son: - Cambia una o mas entradas en salidas bien definidas. - Tiene roles, responsabilidades, herramientas y controles de gestión - Consta de políticas, actividades, estándares, procedimientos e instrucciones Además para ITIL todo proceso debe: - Ser Medible: Debe ser medible desde 2 puntos de vista, debe ser medible en calidad y costo para el IT Manager con el objetivo de imputar costos a distintas áreas y debe ser medible en tiempo y productividad para el usuario y cliente. - Dar Resultados Específicos: Identificable y contable. - Debe responder a eventos específicos

El ciclo de vida del Servicio (CV) El ciclo de vida es un término nuevo de ITIL v3 donde el servicio es retroalimentado por el conocimiento obtenido para llegar a un resultado deseado y mejorado, es obvio que para lograr esto se necesita un feedback (realimentación) muy bien documentado, así como un control y medición de los procesos. La imagen muestra claramente como todo comienza por la solicitud del cliente, pasa por el Service Stategy, luego por el Service Design, Service Transition, Service Operation y por último el Servicio de Mejora continua que retroalimenta a todos los demás servicios. Service Strategy: Eje de rotación del CV ( Ciclo de vida ) y es donde se dan las políticas, estándares y objetivos. Service Design, Service Transition y Service Operation: Estos implementan la estrategia y representan el cambio y transformación Continual Service Improvement: Incorpora el aprendizaje y mejoramiento, se basa en el modelo (PDCA): Plan, Do , Check and Act (Planificar, Hacer , Verificar y Actuar).

Conceptos y Definiciones Genéricas para ITIL v3 Portafolio de Servicios: Hace referencia a todos los servicios de IT (Tecnologías de la información), la descripción de cada servicio, su status en el CV, etc. El portafolio incluye los servicios de terceros. Catalogo de Servicios: Sub conjunto del portafolio de Servicio, representa los servicios ACTIVOS Y APROBADOS, muestra el precio del servicio, SLA (Acuerdo de Nivel de Servicio), términos del servicio, así como políticas y responsabilidades. BusineEstrategia de servicio Service Catalogue (Catálogo de Servicios de Negocios): Es la vista que tiene el cliente del Catalogo de Servicios y la relación que tienen los procesos de negocio con los servicios que ofrece IT. Technical Service Catalogue (Catálogo de Servicios Técnicos): Relación de servicios, componentes y CI (Item de Configuración - Elemento de configuracion ) para soportar el servicio.

BusineEstrategia de servicio Case: Indica el motivo del servicio, su objetivo y lo que quiere lograr; justifica si el servicio debe seguir en curso o como podemos mejorarlo. Además debe presentar costos y los beneficios esperados. Riesgo: Presenta oportunidades y amenazas y define un marco de trabajo con pasos bien definidos para analizar y minimizar los riesgos. Service Knowledge Management System - Servicio Sistema de Gestión del Conocimiento (SKMS): Es la forma de guardar la información generada por los eventos, incidentes, experiencias, etc para convertir la data en información para toma de decisiones. Dueño del proceso: Responsable que el proceso sea ejecutado de acuerdo al SLA, así como de cumplir las metas definidas. Dueño del Servicio: Responsable ante el cliente de la iniciación, transición, mantenimiento y soporte del servicio. Aquí entra en detalle la matriz RACI (Responsible (Encargado), Accountable (Responsable), Consulted (Consultado), Informed (Informado)) donde se asignan responsabilidades.

Service Strategy (Estrategia del Servicio) Metas y Objetivos



ESTRATEGIA DE SERVICIO busca mejorar el impacto estratégico (utilidad del servicio y percepción del cliente) a través del diseño, desarrollo, implementación y práctica de la Gestión del Servicio (ITSM).



Transformar la gestión del servicio en un activo estratégico: Pensar como puedo mejorar el servicio.



Proveer principios de soporte (solo principios) para asistir en el desarrollo de: políticas, guías y procesos.



Gestión Financiera: ¿Cuanto me cuesta dar el servicio ofrecido?

Introducción En otras palabras, ESTRATEGIA DE SERVICIO analiza el tipo de cliente para decidir que deberíamos ofrecerle y como deberíamos ofrecérselo para que esto permita realizar el negocio con éxito. La estrategia esta basada en las 4Ps: - Perspectiva: La visión de la situación ¿Qué se necesita? - Posición: ¿Dónde estoy? ¿Funcionaría? - Plan: ¿Cómo lo hago? - Patrón: Así lo voy hacer. ¡Si se dan cuenta es como un juego de ajedrez! así como el que pienso jugar mas tarde con mi amigo Pepe. ¡ESTRATEGIA DE SERVICIO busca dar valor!!!! a través de RECURSOS (dinero, hardware, software) y HABILIDADES (gestión, organización, procesos, knowledge y LAS PERSONAS). Desde el punto de vista del cliente el valor significa: UTILIDAD (¿me sirve o no me sirve?) y garantía (¿Es confiable?). Un ejemplo para entenderlo mejor…. ¡Pongámoslo más simple aun!! analicemos un ejemplo clásico de TI. Una organización quiere almacenar información importante de sus clientes, es solo un ejemplo, entonces ellos que no saben de Sistemas Gestores de Bases de Datos y hasta ahora lo están almacenando en archivos XLS en la computadora de 2 personas del área de logística. Hasta hace algún tiempo guardarlo en archivos XLS no estaba nada mal porque tenían pocos clientes pero este ultimo año han crecido en un 200% y sus usuarios se han triplicado y durante el ultimo año tuvieron algunos problemas: una de las computadoras de las personas de logística que tenia el listado de clientes se malogro y con ello perdieron muchos usuarios, para mala suerte de la organización la otra persona que tenia el listado de clientes (desactualizado) estaba de vacaciones y no tenían como entrar a su computadora y cuando lograron entrar a la bendita computadora no sabían cual era el archivo porque habían muchos files que tenían los siguientes nombres: clientes-ultimo.xls, clientes-actualizado.xls, clientes-ok.xls y clientes-usar-este.xls.

ESTRATEGIA DE SERVICIO aquí entra en acción!! les ofrece un SGBD (Sistema Gestor de BD) con tablas relacionales, con un sistema Web para que cualquier usuario con un simple browser pueda usar el sistema y con un sistema de backup diario. Todo perfecto!!!! pero… de que sirve todo esto si el cliente no advierte las ventajas que todo esto puede tener para la organización, ¿Que pasa si el sistema arroja información poco relevante? de inmediato el cliente pensará: “Mi archivo XLS era igualito y hasta me mostraba mas información”, ¿Que pasa si el sistema esta mal programado y esta lento? nuevamente el usuario pensara: “Mi archivo XLS era mas rápido”, entonces de nada habrá servido colocarles ORACLE, MySQL o MESTRATEGIA DE SERVICIOQL, de nada habrá servido haber comprado un buen servidor y el sistema de aire acondicionado para ese servidor; es decir el cliente tendrá la impresión de que todo el dinero fue una estafa y se tiro a la basura!. TODO GIRA ALREDEDOR DE LA IMPRESION y PERSPECTIVA DEL CLIENTE. Pero si por el contrario, el sistema le ofrece al cliente: - Mayor información del cliente (dirección, rubro del negocio, etc), además información mejor organizada y resaltando la información mas relevante; el cliente notara la diferencia porque así puede ganar mas dinero. - Sistema Web rápido y utilizable desde cualquiera sitio y a cualquier hora (porque esta colgado en la nube), el cliente siente la diferencia entre este sistema y un XLS porque ahora puede hacer negocios a cualquier hora y desde cualquier parte del mundo (se supone que el sistema ofrece una GARANTIA de Seguridad). - Un usuario borro casualmente los datos de un cliente y el backup entra acción en solo 15 minutos, entonces el cliente ya no tendrá dudas y sabe que lo adquirido si vale la pena y se ha convertido en un ACTIVO ESTRATEGICO. - Para el cliente el valor depende de la UTILIDAD Y GARANTIA. Todo esto fue planeado por ESTRATEGIA DE SERVICIO, la ejecución e instalación fueron hechas por otras personas que mas adelante veremos pero la idea fue planeada por ESTRATEGIA DE SERVICIO, creo que el ejemplo esta sencillo y claro, verdad?. Actividades de ESTRATEGIA DE SERVICIO 

Actividad 1: Definición del mercado



Actividad 2: Desarrollo de ofertas



Actividad 3: Desarrollo de los activos estratégicos.



Actividad 4: Preparación para la ejecución

Procesos de ESTRATEGIA DE SERVICIO 

Gestión del portafolio de Servicios



Gestión de la demanda



Gestión Financiera

Tengo la impresión que después del ejemplo las actividades y procesos se explican por si solos pero voy ahondar un poco mas. ACTIVIDADES DE ESTRATEGIA DE SERVICIO ACTIVIDAD 1: Definición del mercado 

Define la estrategia para los servicios y servicios para la estrategia: Regresemos al ejemplo de líneas arriba, la estrategia del servicio es entregar un servicio rápido, que tenga los mismos usuarios que ya cuenta la empresa y pueda ser accedido desde cualquier parte del mundo y los servicios para la estrategia es contactar con un ISP que nos brinde una IP pública.



La definición del mercado se puede resumir en una frase: ENTENDER AL CLIENTE, es decir entender que necesita y que es lo mejor que se le puede brindar, obviamente eso depende de otras cosas como por ejemplo cual es el rubro de la organización.

ACTIVIDAD 2: Desarrollo de ofertas 

Basado en Market Space: Todas las oportunidades que el proveedor de servicios de TI puede explotar para satisfacer las necesidades del negocio de los clientes.



Es la lista de servicios que vamos a entregar y soportar. Es aquí donde aparece un nuevo termino: Portafolio de Servicios, con un gráfico lo explico mejor.

Portafolio de Servicios ITIL nos dice que el área de IT debe tener bien en claro cuales son los servicios que estamos brindando y cuales NO!, depende del acuerdo que se ha llegado con el cliente (SLA). ¿Por qué hay que tener esto bien en claro? Porque es clásico y recurrente que en una organización los clientes quieren que absolutamente todo sea soportado por el área de IT, por ejemplo: usuarios que tienen problemas para usar WORD llaman automáticamente al área de IT para que le solucionen el problema, clientes que desean que el correo les llegue a su black berry (esto nunca se acordó), clientes que desean usar el nuevo OFFICE 2007 porque les parece mas bonito; pero si el cliente y el área de IT tienen en claro cual es el servicio que se brinda y se soporta no tendremos problemas en este aspecto. En el portafolio de servicios consta de las siguientes partes: 

Catálogo de Servicios: Son los servicios ofrecidos y soportadas por el área de IT.



Pipeline de Servicios: Servicios en desarrollo pero que aun no son soportados por el área de IT.



Servicios retirados y SERVICIOS DE TERCEROS.

ACTIVIDAD 3: Desarrollo de Activos Estratégicos Para desarrollar un Activo Estratégico debemos responder a la siguiente pregunta: ¿Qué es de vital importancia para el cliente? Cuando sepamos eso sabremos que es un “Activo Estratégico” y podremos desarrollarlo, monitorearlo y analizarlo de la manera correcta. Quizás para una organización el servicio de correo electrónico es un activo estratégico debido a la importancia que tiene este en negocio, entonces podremos desarrollar manuales de contingencia ante una posible caída del servicio para que este siga funcionando (por ejemplo una imagen del servidor), además de un análisis de la demanda de este y mejoramiento continuo del servicio.

ACTIVIDAD 4: Preparación para la Ejecución En esta actividad se hace una evaluación estratégica de la situación actual y de COMO VAMOS A DAR EL SERVICIO. Aquí se definen métricas de éxito, objetivos, definición de los factores críticos de éxito (CSF: Critical SucceEstrategia de servicio Factor), análisis potencial del negocio (Análisis FODA) y un análisis competitivo (una anticipación a futuros cambios). GESTION DE ESTRATEGIA DE SERVICIO Gestión del Portafolio de Servicio (SPM: Service Portfolio Management) : Un portafolio de servicios indica todos los servicios de IT que tiene una organización, estos servicios cuentan con una descripción, busineEstrategia de servicio case, nivel de prioridad, riesgos, ofertas de IT y obviamente un costo y precio del servicio; debido a esto el portafolio de servicios es un método dinámico para gobernar inversiones y busca maximizar el valor mientras se administra riesgos y costos. SPM se establece con los siguientes métodos de trabajo: 

Define: Recolecta datos de los servicios existentes y propuestos que van en el portafolio de servicio.



Analiza: Responde a las preguntas: “¿Cómo mejoro el servicio?”, “¿Qué servicios necesita la organización para cumplir sus metas?”, “¿Como conseguiremos esas metas?”.



Aprobación: Aprueba el status del servicio, por ejemplo que el servicio pase del status de desarrollo al de producción (muy importante!!)



Comunicación: Comunica a los clientes del cambio de status.



Refresco: Analiza las revisiones del SPM, cambios regulatorios dependiendo de un nuevo requerimiento.

Aquí surge un rol: GERENTE DE PRODUCTO, esta persona se encarga de coordinar el Portafolio de Servicios, trabaja frecuentemente con los gerentes para analizar los cambios

del portafolio, es un experto de la línea de servicios, evalúa nuevas oportunidades y tecnologías para las futuras necesidades del cliente. Como se darán cuenta esta persona no es un Administrador en todo el sentido de la palabra sino que debe de conocer de IT para poder desempeñar el cargo con éxito. Gestión Financiera: ITIL tiene como objetivo financiero poder imputar costos al cliente y para poder hacerlo necesita conocer al detalle el costo del valor del servicio ofrecido y no solo el costo del servicio sino que debe conocer en mayor detalle los gatos que este servicio implica, como por ejemplo sabe el valor de los activos subyacentes que proveen dichos servicios. La Gestión Financiera se encarga de: 

Valoración del servicio y análisis de la demanda: ¿Quienes usan el servicio?



Coloca en el portafolio la velarización del servicio.



Busca hacer servicios mas competitivos en términos de costo y calidad.



Planeamiento confiable: Analiza la futura demanda y los futuros costos.



Contabilización: Identifica todos los gastos que el servicio demanda.



Análisis de la inversión: Obtiene un indicar entre el valor recibido por el cliente y el costo del servicio.

Aquí surge otro rol: GERENTE FINANCIERO esta persona se encarga de documentar y acordar el valor del servicio, analiza la demanda, provee de costos y se encarga del cumplimiento financiero de los clientes. Y por último…… Gestión de la demanda: Este tiene como objetivo reducir la indisponibilidad del servicio por una excesiva demanda, además tiene como objetivo asegurar la calidad del servicio a través de un balanceo entre los recursos ofrecidos y la demanda. Aquí surge el ultimo rol de este post: GERENTE DE DEMANDA, esta persona participa en la creación de los acuerdos (SLA), esto es evidente debido a que si se pacta un servicio que será usado por 50 personas y luego es usado por 200 el SLA debe ser modificado; además esta persona siempre debe estar monitoreando la demanda y capacidad general del servicio para responder a patrones de cambio de la actividad del negocio (PBA: Patterns of BusineEstrategia de servicio Activity)

Service Design (Diseño del Servicio) Aunque siempre tengo mil cosas por hacer me he dado un tiempo hoy domingo por la noche para escribir EL TERCER POST DE ITIL, para aquellos que han llegado a este post sin antes haber leído los dos primeros post sobre ITIL les recomiendo leer el primer post y el segundo post. 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 (que serán los 2 siguientes posts). Vamos a poner un ejemplo y para seguir una misma idea voy a usar el ejemplo colocado en el post de Service Stategy, el ejemplo trata de una organización que necesita almacenar información de sus clientes y nosotros como expertos en TI mediante el Service Strategy 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 SD 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: o Paso 1: Instalar el SO bajo ciertas caracterices o Paso 2: Instalar JAVA o PHP de la siguiente manera o Paso 3: Instalar la BD: MySQL o Oracle con los siguientes parámetros o 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 1. Gestión del Portafolio del Servicio 2. Identificación de los requerimientos del negocio, definición y diseño del servicio 3. Diseño de la arquitectura tecnológica 4. Diseño del proceso 5. Diseño de las métricas Voy a explicar cada punto:

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. Procesos de SD 

Gestión del Nivel de Servicio (SLM)



Gestión del Catalogo de Servicios (SCM)



Gestión de la Capacidad



Gestión de la Disponibilidad



Gestión de la Continuidad del Servicio



Gestión de la Seguridad de la Información



Gestión de Proveedores Externos

Gestión del Nivel de Servicio (SLM) Antes de que SS tome la decisión y acuerde con el cliente un SLA, SD tiene que asegurar un claro entendimiento entre el cliente y TI, tener bien en claro lo que el cliente desea tiene un nombre y se llama Requerimiento del Nivel de Servicio (SLR). Las siguientes 2 imágenes resumen lo que hace la “Gestión del Nivel del Servicio”, la primera imagen muestra el proceso lineal desde que llega una solicitud del cliente, identificación de los requisitos, definición de lo que se puede brindar, firma del contrato que incluye: Acuerdo del Nivel del Servicio (SLA), OLA (Acuerdo de Nivel Operacional) y UC (Underpinning Contract), por ultimo la fase de monitoreo e informes para la mejora continua. Nota: Un ejemplo de OLA es un acuerdo entre TI y el área de logística para poder cumplir con los requerimientos del usuario, un caso practico podría ser la entrega de equipos de computo en 24 horas de haber llegado a la organización. Un UC es un contrato formal con proveedor de servicios de IT (un tercero) para cumplir con los requerimientos del usuario, por ejemplo el contrato con un ISP. Solo para aclarar, es obvio que no todos los pedidos deben ser aceptados, por ejemplo si un cliente solicita el cambio de versión de Office 2003 a Office 2007 porque le gusta mas el color y el diseño de la nueva versión, ¿conviene hacer el cambio? es obvio que NO. La gestión del Nivel de Servicio tiene como fin armar el SLA y las métricas que estarán incluidas en el SLA, es obvio que existen distintos tipos de SLA y enfocados de distinta manera, por ejemplo puede ser basado en el servicio o basado en el cliente. 

Basado en el Servicio Un SLA basado en el servicio es cuando solo existe un SLA para un servicio pero que involucra a muchos clientes, por ejemplo un SLA para el Email corporativo indica que todos los usuarios cuentan con un correo.



Basado en el Cliente En SLA basado en el cliente es cuando existe un SLA que cubre muchos servicios pero solo para un cliente o área en especifico.

¿Qué contiene un SLA? 

Descripción, horario, disponibilidad y fiabilidad del servicio



Tiempo de respuesta del servicio, vía de comunicación y cambios



Continuidad, seguridad, costo, informes y penalizaciones.

Gestión del Catalogo de Servicio SD es quien sabe que podemos brindar y que no podemos brindar, es decir brindar la información de lo que podemos poner en el catalogo y lo que no podemos. Gestión de la Capacidad Cuando hablamos de capacidad debemos asociar esta palabra con “performance”, la Gestión de la capacidad se encarga de evaluar el impacto de cambios, incidentes y problemas para generar un plan de capacidad. Las tareas de la Gestión de la capacidad son: 

Monitorear el rendimiento



Monitorear Cargas



Previsión de recursos



Pronosticar demanda

Una imagen explica mejor todo lo que yo puedo escribir, en la imagen se muestran las entradas, los sub-procesos que ocurren en la gestión de la Capacidad y los resultados, donde resaltan 2 muy importantes: Plan de Capacidad y la Base de Datos de Capacidad (CDB). Por ejemplo de ambos es: el año 2008 el uso del procesador del servidor web en promedio fue un 50% durante las campañas de venta, el año 2009 el uso del procesador subió a 75% debido a que la organización ha crecido, el año 2010 el procesador estará en un 95% y las transacciones estarán lentas perjudicando las ventas, el plan de capacidad debería indicar que para el 2010 se debió haber reemplazado el servidor por uno mas potente. Gestión de la Disponibilidad La capacidad y disponibilidad son temas muy comprometidos, no se puede hablar de disponibilidad sin antes haber tocado capacidad; por ejemplo… si un servidor ha excedido su capacidad y producto de eso sufre una caída afectando el negocio llegamos a la conclusión de que el servidor NO ESTA DISPONIBLE, sin embargo hay otros aspectos importantes que tocar y debido a eso ITIL v3 hace una separación entre capacidad y disponibilidad. Sus tareas son: 

Generar un plan de disponibilidad



Evaluar el impacto de cambios en el plan de disponibilidad



Explicar a los usuarios la importancia de la información y su disponibilidad, esto incluye el manejo de backups, lugar físico adecuado para el procesamiento de información (DataCenter) y obviamente esto afecta también el performance.

Como todo proceso, la gestión de la disponibilidad tiene sus entradas y salidas, destacando como salida los reportes y el monitoreo, es decir que debemos tener un reportes de la caída de un servidor, la fecha, la duración, descripción, componente fallado e impacto en el numero de usuarios. Gestión de la Continuidad La gestión de la continuidad aparece cuando un incidente se ha convertido en un problema y negocio debe seguir andando, por ejemplo cuando cae un servidor. Es decir deben planear y recuperarse ante una crisis de TI de modo que los usuarios no se vean perjudicados. Sus objetivos son: 

Mantener un plan de continuidad y plan de recuperación



Completar Business Impact Analysis (BIA)



Revisar la gestión del riesgo



Al igual que la gestión de la disponibilidad, evalúa el impacto de un cambio

Esto que nos ofrece:

1. Mejor administración de los riesgos 2. Credibilidad organizacional 3. Recuperación de los sistemas de TI de manera controlada 4. Interrupción mínima del negocio Algunos Conceptos Imaginemos que el DataCenter sufrió un incendio y debemos recuperar la información en otro ambiente, la recuperación recibe un nombre dependiendo de donde se haga: 

Recuperación gradual o Cold Standby: Colocar un ambiente de computo en otro ambiente NO de computo.



Recuperación intermedia o Warm Standby: Recuperación en un ambiente y equipo adecuado



Recuperación inmediata o Hot Standby: Sistemas en paralelo, es decir cae un ambiente y automáticamente entra a trabajar el otro.

Maximun Tolerable Downtime (MTD): Periodo máximo de tiempo entre que el sistema cayo y todo vuelve a funcionar con normalidad. Recovery Time Objetive (RTO): Tiempo de recuperación de sistemas y/o recursos. Recovery Point Objetive (RPO): Tiempo durante los datos se perdieron. Work Recovery Time (WRT): Tiempo para recuperar datos perdidos. Para que todo esto funcione correctamente debemos tener en cuenta algunos factores críticos: 

Realizar análisis de riesgo



Plan de contingencia en términos del negocio (no es lo mismo el plan de contingencia de un banco que de un empresa convencional)



Pruebas del plan de contingencia

Gestión de la Seguridad de la Información La seguridad es analizada de manera muy somera y superficial por ITIL, ¿por qué? Porque la seguridad es un campo muy grande para tratar y es prácticamente otro curso. Sin embargo ITIL da unos conceptos generales. La seguridad tiene 3 pilares: Confidencialidad, Integridad y Disponibilidad. Aquí surge una pregunta muy importante, ¿qué tanto debo asegurar mi información? la respuesta depende del rubro del sistema, por ejemplo los bancos en el Perú están obligados a cumplir con la norma ISO 27000, mientras que otros tipos de organizaciones no lo están. Actividades de la Gestión de la Seguridad

Mantener una política de seguridad, que incluye un comité de seguridad, un responsable de seguridad (CISO: Chief Information Security Officer) y un gerente de seguridad (CSO: Chief Security Officer). Planear, implementar y evaluar la seguridad periódicamente Hacer informes conforme a las métricas Gestión de Proveedores Externos Objetivos: Obtener y negociar el dinero a pagar a los UC Negociar el acuerdo y contrato con los UC Mantener una política con proveedores externos, así como una BD de esos proveedores (SCD: Supplier Contract Database)

Service Transition (Transición del Servicio)

Cuarto post sobre ITIL v3, en donde hablaremos sobre la transición del servicio. Para poder entender correctamente este post y relacionar correctamente todos los temas deberíamos haber leído antes: Introducción a ITIL v3, Estrategia del Servicio (SE) y Diseño del Servicio (SD).

ITIL se baja en algo tan simple como la lógica!!! no hay nada misterioso o que nunca hayamos hecho antes los que estamos metidos en el mundo de TI, analicemos un poco; primero analizamos la estrategia para saber como podemos enfrentar una solución de TI, luego diseñamos los pasos a seguir es decir los procedimientos y ahora lo que debe continuar es IMPLEMENTAR EL SERVICIO, es decir la TRANSICION de lo pensado hacia sistemas tangibles. Entonces Service Transition (ST) se encarga de coordinar los procesos y funciones para empaquetar, construir, probar y desplegar una versión del servicio según lo acordado en el SLA, con el objetivo de llevar un control e información de los cambios realizados, mejorar el impacto sobre el ambiente de producción e incrementar la satisfacción del cliente durante el proceso de transición. Algunos conceptos y definiciones de ITIL v3 

Ítem de configuración (CI): Es todo activo, servicio, componente de servicio o cualquier ítem que es o esta bajo el control de la gestión de la configuración, aunque el termino parece sencillo el examen de certificación de ITIL trae siempre preguntas sobre esta definición.



Sistema de congestión de la configuración (CMS): Gestiona todos los CIs.



Definitive Media Library (DML): Biblioteca segura que almacena y protege las versiones autorizadas y definitivas de todos los CIs.



Unidad de liberación (Release Unit): Porción de un servicio o infraestructura de TI que es liberada o desplegada según las políticas de la organización.

Como ya habíamos comentado en las primeras líneas, la “Transición del Servicio” ejecuta y plasma el diseño del servicio en un servicio táctil y utilizable; sin embargo no es están simple como “hacerlo o ejecutarlo” sino que hay toda una gestión y procesos detrás de estos, estos procesos son: 

Gestión del Cambio



Gestión del Activo servicio y la configuración (SACM)



Gestión de la liberación y el despliegue

GESTION DEL CAMBIO

La gestión del cambio se asegura que todos los cambios sean registrados, evaluados, autorizados, priorizados, planeados, probados, implementados, documentados y revisados de manera controlada, para que el impacto en los usuarios sea confortable. Conceptos en la gestión del cambio 

Políticas y estándares: reglas que proveen una cultura y ambiente que soporta el cambio. Por ejemplo una política de cambio es que todo cambio debe ser probado por el periodo de 15 días hábiles como mínimo.



Requerimientos de cumplimiento regulatorio: Este se aplica a disposiciones legales, por ejemplo si el estado decide aplicar un aumento al IGV, el sistema informático debe cambiar, a esto se le llame un cumplimiento regulatorio.



Pruebas y procedimientos de post evaluación: La gestión encargada de evaluar que el cambio ha sido implementado con éxito es la GESTION DEL CAMBIO (pregunta de certificación)



CAB (Comité de Cambio) y ECAB (comité de cambio de emergencia)



Stakeholders: Involucrados en la planeación y preparación del cambio, aconsejan cronograma de cambios.

¿Que es para ITIL un cambio? 

Un cambio en el estado de un CI



Un cambio de un CI en las relaciones con otro CI



UN NUEVO CI (pregunta de certificación)



Un nuevo propietario o cambio de ubicación de un CI

Actividades del proceso

La imagen superior resume todo lo que hace la gestión del cambio, voy ahondar un poco tratando de no caer en la redundancia: 1. Registro: Registrar todos los RFC (Request for change – Solicitud de cambio) y cambios en la CMDB, registrar el tipo de cambio, si fue un cambio estándar (planeado) o fue un cambio no estándar (un cambio de emergencia por ejemplo).

2. Aceptación: Evaluación inicial del RFC donde se puede rechazar RFC poco claras e ilógicas y hasta innecesarias. Esto es muy importante porque si el RFC es rechazada por ser poco clara hará que el solicitante sea mas explicito y mejore el entendimiento del cambio. 3. Clasificación: Especifica la prioridad (importancia del cambio frente a otro cambio) y la categoría (en base del impacto y recursos). Asignación de la prioridad 

Inmediato: Un cambio que origina que el servicio este caído o el impacto en la organización sea muy grande, esto debe hacer que el ECAB deba reunirse.



Alto: Afecta un buen numero de usuarios.



Medio: No hay un impacto severo.



Bajo: Cambio justificado y necesario, puede esperar la calendarización.

La imagen muestra procedimientos de cambio de emergencia y es evidente que este no sigue procedimientos normales, debe tener la mayor prioridad y debe contar con la reunión del ECAB. 4. Planificación: Los cambios se planifican usando utilizando un Calendario de Cambio a futuro (FSC: Forward Schedule of Changes) Políticas de Cambio Las políticas determina si se combinan RFCs, horarios y fechas de cambio. Reuniones del CAB RFCs que deben ser evaluadas por el comité, cambios abiertos y cerrados, evaluación de cambios pasados, cambios autorizados que no han sido remitidos al cab y revisar los cambios que no han sido autorizadas son las tareas del comité de cambio (CAB). 5. Coordinación: Los cambios aprobados se comunican con los especialistas para que implementen el cambio. Aquí hay algo importante que decir, la gestión del cambio NO IMPLEMENTA EL CAMBIO (pregunta de certificación), entonces…. ¿quién implementa el cambio? la respuesta esta en este mismo post así que sigue leyendo. 6 Evaluación: Se encargan de cerrar el RFC si el cambio fue exitoso y se registra en el PIR (Post – Implementation Review) y si el cambio no fue exitoso se retorna al punto de error. Todo creo que esta claro hasta aquí y para aquellos que ya han leído los primeros posts sobre ITIL saben que todos los procesos para ITIL deben ser cuantitativos, es decir que a partir de esto nosotros debemos hacer reportes donde se indique lo siguiente:



Métricas de Salida: o Numero de interrupciones, incidente y problemas que hubo con el servicio. o Numero de cambios no autorizados que se han llevado a cabo. o Numero de cambios forzosos o de emergencia que se realizaron o Tiempo, esfuerzo y costo que ocasiono el cambio



Métricas de trabajo o Frecuencia de cambios o Volumen de cambios



Proceso de medición o Satisfacción del usuario

Si olvidan que para ITIL todo debe ser medido y por ende registrado, están olvidando la esencia de ITIL. GESTION DEL ACTIVO SERVICIO Y LA CONFIGURACION ¿Suena raro el nombre verdad? Pues cuando yo escuche por primera vez esto no entendí muy bien a lo que se refería pero luego lo entendí fácilmente y eso es lo que voy a tratar de hacer aquí, que los que lo lean lo entiendan fácilmente. Entonces… un ACTIVO SERVICIO es todo lo que se pueda registrar referente a TI, desde un switch, software, dueños de hardware/software hasta documentación. Teniendo esto en cuenta LA GESTION DEL ACTIVO SERVICIO Y LA CONFIGURACION define y controla todos los componentes de los servicios brindados, así como la infraestructura con el objetivo de mantener los registros actualizados y exactos, aun no lo entendiste? OK digámoslo mas sencillo aun y con un ejemplo, si mañana se reemplaza un switch no administrable por un switch cisco administrable, la configuración y la relación de este switch con los demás switches debe ser actualizada y registrada por este proceso. Esto obviamente tiene sus ventajas, por ejemplo…. si tenemos toda la configuración debidamente registrada la GESTION DEL CAMBIO puede tomar la decisión de un cambio de manera mas sencilla y con mejor precisión, además se puede resolver problemas con mayor rapidez y además tenemos un control de todos los activos. Conceptos en la Gestión del Activo Servicio y la Configuración (SACM)



Sistema de Gestión de la configuración (CMS) La CMS mantiene toda la información relativa al activo servicio y a la gestión de la configuración.

Nota: CMDB –> CMS –> SERVICE KNOWLEDGE MANAGEMENT SYSTEM, este es el modo evolutivo de almacenamiento de información de ITIL. [Aquí pueden leer acerca de esta evolución] 

Definitive Media Library (DML) Sobre DML vienen muchas preguntas de certificación, la DML es el sitio FISICO donde se almacena el software que se utiliza en la organización, pero no cualquier software sino la versión final y de uso del software; es decir no una versión incompleta del software sino la versión autorizada por el equipo de desarrollo por ejemplo.



Línea base de configuración (Baseline) Es una solo una línea de referencia para configuraciones, por ejemplo la “baseline” de las computadoras de una organización es para todos igual (sistema operativo Windows, drivers, codecs, etc.) y dependiendo del área donde trabaje se le instalan otras aplicaciones.



Gestión de Configuración Por un lado esta Gestión del activo servicio que se encarga de almacenar la información de un CI y por otro lado esta la Gestión de la Configuración que no solo almacena la configuración de un CI también almacena la relación que tiene el CI con otros CIs.

La grafica superior muestra como actúa la gestión de la configuración, aplicando ITIL nosotros debemos ser capaces de saber cuantos usuarios y de que departamentos serán afectados sin un servidor de Base de Datos falla y la respuesta debe ser en un periodo corto de tiempo sin necesidad de ir preguntado usuario por usuario por el problema. Nota: Es obvio que llegar a este punto no es sencillo, si me preguntaran a mi cuantos usuarios y que servicios se ven afectados si se cae determinado switch tendría que revisar la ubicación física, los tipos de usuarios, etc; por lo tanto para llegar al nivel que recomienda ITIL me falta aun bastante (pero voy rumbo a ese objetivo). En conclusión lo que hace la GESTION DEL ACTIVO SERVICIO Y LA CONFIGURACION almacenar los atributos de un CI y su relación con otros CI, que almacenar de un CI? pues eso depende lo que sea relevante para una organización, aunque ITIL recomienda algunos atributos básicos,

Es evidente que esto no es todo lo que se debe de almacenar de un CI, existen otros datos importantes como el numero de serie, numero de modelo, fabricante, categoría, ubicación, propietario responsable, licencia, estado actual, costos y algunos otros comentarios. ¿Existe relación entre la Gestión del Cambio y la Gestión de la Configuración? Evidentemente existe una relación, cuando se realiza un cambio en un CI la información de ese CI y la relación con otros CI debe ser almacenada, la grafica inferior lo explica mejor.

No hay mucho que comentar acerca de la grafica y es que es evidente que la Gestión de la Configuración esta relacionada directamente con la Gestión del Cambio debido a que todo cambio debe ser almacenado y esa es la función de la Gestión de la configuración. Definitivamente almacenar todos los atributos de un CI, el status y sus relaciones con otros CI no es tarea sencilla pero tiene sus beneficios como una mejor gestión de los componentes de TI, se reduce errores y costos, eficacia en la solución de problemas, cambios mas veloces, mejor control de hardware y software. Gestión de las Versiones y el Despliegue (RDM – Release and Deployment Management) Lo primero que hay que saber aquí es que los gringos utilizan la palabra “RELEASE” y nosotros no hemos encontrado una mejor traducción que “VERSION”, quizás una mejor traducción hubiera sido “LANZAMIENTO” aunque no se…. ya me acostumbre a decir “Gestión de las Versiones” y así pienso dejarlo. Un release es un conjunto de elementos de configuración nuevos y/o modificados que están evaluados (gestión del cambio) y se introducen en el entorno de producción, en conclusión la gestión de versiones es quien implementa los cambios en los servicios de TI y dirige todos los aspectos técnicos y no técnicos de los cambios.

La imagen superior que parece tan inofensiva es una “caserita” de examen de certificación de ITIL, ¿quién implementa el cambio? ¿quién verifica el cambio? lo han preguntado mil veces y lo seguirán preguntando. Objetivos - Hace los planes de liberación y despliegue - Construir, instalar, hacer las pruebas y desplegar los paquetes de liberación - Diseñar e implementar los procedimientos para instalar los cambios en los servicios de TI - SACM es el responsable de todos los CIs, sin embargo RDM debe de apoyar que todas las copias de software estén en el DSL y el hardware necesario esta en el DHS. Nota: En ITIL v2 hay dos términos importantes, DSL (Definitive software library) y DHS (Definitive hardware store), en ITIL v3 esos dos términos carecen de sentido porque existe un nuevo concepto llamando DML (Definitive media library) y que esta bajo la gestión de SACM. Pueden leer un poco mas sobre eso [AQUI]. Conceptos de RDM - Entornos de Software: ITIL v3 recomienda tres entornos o tres ambientes de software 

Entorno de desarrollo: Aquí se puede instalar de todo y todos los usuarios tienen acceso.



Entorno de pruebas: Ambiente idéntico al de producción donde solo tienen acceso los tester, aquí se hacen pruebas técnicas, de performance, funcionales y es aquí donde se recibe la aceptación final por el grupo de usuarios para pasar el software a producción.



Entorno de producción: Aquí se ponen los servicios a disposición de los usuarios, este ambiente no se sin antes haber pasado por desarrollo y pruebas.

Tipos de versiones: 

Versión delta: sólo se testean e instalan los elementos modificados. Esta opción tiene como ventaja su mayor simplicidad pero conlleva el peligro de que puedan aparecer problemas e incompatibilidades en el entorno de producción.



Versión completa: Se distribuyen todos los elementos afectados ya hayan sido modificados o no. Aunque esta opción es obviamente más trabajosa es más improbable que se generen incidentes tras la instalación si se han realizado las pruebas pertinentes.



Paquete de Versiones: La Gestión de Cambios puede optar por distribuir de forma sincronizada diferentes paquetes de versiones, de esta forma se ofrece una mayor estabilidad al entorno TI. En algunos casos esta opción es obligada por incompatibilidades entre una nueva versión con software o hardware previamente instalado. Pensemos, por ejemplo, en la migración a un nuevo sistema operativo que requiere hardware más avanzado y/o nuevos versiones de los programas ofimáticos.

Llegado a este punto, debemos ser capaces de entender todo el proceso que ITIL propone y la siguiente grafica lo explica claramente.

Hasta este punto y si han leído los primeros post de ITIL, ya comprenden acerca del Nivel de Servicio, la Gestión del Cambio, la Gestión de la configuración y pueden notar que todo ITIL esta relacionado, ahora lo que falta ahondar mas es en la Gestión de Versiones y sus actividades internas, ¿ven el cuadrito que dice “Gestión de Versiones” en la imagen superior? pues vamos hacerle un zoom y hablar sobre eso.

Este es el zoom del recuadro, la imagen muestra todas las actividades que realiza la gestión del release y los respectivos ambientes donde se realiza la actividad. Vamos a explicar las actividades y con esto términos este extenso post. 1.- Política y planificación de liberación de versiones: Define políticas que responden a preguntas: ¿cómo y cuando se configura y despliega una versión?, define horarios de liberación, horas/hombre. 2.- Diseño, construcción y configuración: Desarrollo procedimientos para construir y configurar. 3.- Prueba y aceptación de le versión: Pruebas funcionales de los usuarios, prueba operativa del personal de TI (la gestión del cambio debe coordinar la aceptación final por parte del usuario) 4.- Planificación del despliegue: Detalla recursos y responsabilidades, además analiza las formas de implementación (una implementación total – Big Bang- o una implementación por partes) 5.- Comunicación, preparación y capacitación: Capacitación e información al usuario. 6.- Distribución e instalación de versiones: Finalmente poner en producción todo lo probado.

Service Operation (Operación del Servicio) Ha pasado casi un mes desde que escribí mi ultimo post sobre ITIL y si alguno pensó que estaba vagando o simplemente me había aburrido de escribir, déjenme decirles que uno de mis principales defectos (o quizás virtud….) es estar siempre estudiando algo, lo que me resta tiempo para cosas como escribir en mi blog y demás actividades de ocio. Bueno hoy pienso dar un paso mas para ir concluyendo mis posts sobre ITIL v3; hasta el momento ya he escrito 4 posts y no quiero caer pesado pero les recomiendo leer los posts anteriores para entender todo el contexto de ITIL. Si quieres darle un review a los post anteriores, aquí lo puedes hacer: - Introducción a ITIL v3 - Estrategia del Servicio - Diseño del Servicio - Transición del Servicio Habíamos dejado la “acción” en la implementación del servicio (Transición del Servicio – ST), acuérdense que en la ST habíamos visto la gestión del cambio, gestión del activo servicio y configuración, y la gestión del despliegue, ¿lo recuerdan, verdad?. Pues la lógica me indica que después de implementar el servicio en un cliente viene algo que cae por su propio peso…. MANTENER EL SERVICIO SIEMPRE FUNCIONANDO.

¿Acaso existe un sistema de TI que funcione completamente solo y sin necesidad de algún mantenimiento? Analicemos un poco, los desarrolladores siempre tienen nuevos requerimientos por parte de los usuarios, los DBA siempre tienen que monitorear que sus BDs estén funcionando, los sysadmin revisar que todo el sistema corporativo este funcionando y así podría pasarme todo el día diciendo que este trabajo nunca tiene fin, por eso en ITIL v3 existe algo que se llama MEJORA CONTINUA que será el tema del siguiente y ultimo post. Con esas cuantas líneas arriba he tratado de resumir lo que hace la Operación del Servicio y que entramos a analizar en este mismo instante: Definición, metas y objetivos SO (Service Operation), conduce, gestiona y controla las operaciones del día a día de los procesos, con la finalidad de tener los servicios estables, registrar incidentes, registrar problemas y sugerir el uso de nuevos procesos. Seamos sinceros …. muchas personas desmerecen este tipo de trabajo, no? pero por el contrario este trabajo tiene una importancia estrategia importante! porque estas son las personas que dan la cara frente al usuario, son los que dicen: “Buenos días, el área de TI le habla; ¿en que puedo ayudarlo?” y nunca debemos olvidar que el área de TI brinda servicios a los clientes y son estos quienes perciben el valor del servicio.

Cuando hablamos de gente que esta constantemente monitoreando los servicios, atendiendo llamadas y dando soluciones temporales, hablamos de nuevos conceptos como: impacto, urgencia y prioridad. Imaginemos….. llama un usuario de logística indicando que no puede abrir un archivo PDF y llama el director general indicando que no le funciona el outlook, ¿a quien se atiende primero? ¿al que llamo primero?, pues…. eso depende de muchos factores como la cantidad de gente con la que se cuente, la cantidad de recursos y de tiempo. Terminología: En este tema existen muchos términos nuevos y definiciones muy técnicas así que me gustaría explicarlo mejor con un ejemplo para que quede bien claro: Se tiene una aplicación llamada “ABC” programada en Java que utiliza una BD Oracle, esta aplicación es accedida mediante un browser por los clientes quienes agregan información de manera diaria. Cierto día, los chicos de SO reciben un correo de sistema CACTI (sistema que monitorea el ancho de banda de la red) indicando que el consumo del ancho de banda de la red se ha

incrementando en un 40% desde las 12pm hasta las 4pm. A los 2 días de recibido este correo, llega otro correo del sistema CACTI indicando que el disco duro del servidor de BD ha pasado el 80% de su capacidad y que se recomienda liberar espacio. Al tercer día (y justo fin de mes) llama un cliente indicando que el sistema “ABC” no funciona y que no puede adjuntar información y que necesita hacerlo lo antes posible porque tiene que terminar su trabajo de fin de mes, a los 10 minutos de esta llamada se reciben 5 nuevas llamadas de otros usuarios con el mismo inconveniente.

De este pequeña historia que es totalmente real, tenemos: Evento: Aumento del consumo del ancho de banda en un 40% (lo mas seguro es que algún usuario estaba agregando bastante información) Alerta: Uso del disco duro en un 80% Incidente: Primera llamada del usuario que no puede adjuntar archivos Problema: 5 clientes que no pueden usar el sistema el fin de mes Workaround (Solución temporal): Montar nuevo disco duro para aumentar el espacio en disco KnowError (Error conocido-KE): Este error se ha presentado con anterioridad y el procedimiento de solución y causa del problema esta documentada. Reactivo: Personas que actúan solo frente a un aviso o problema. Proactivo: Personas que están en búsqueda de la mejora continua A partir de este punto se crean nuevos paradigmas: Calidad del Servicio Vs. Costo del servicio. Es que nosotros como TI podríamos decirle al cliente que el tiempo de respuesta frente a la caída de un servicio será de solo 10 minutos pero necesitamos:

- Herramientas costosas de monitoreo, con un valor aprox de 30 mil dólares anuales - 25 personas dedicadas al área de TI, con un valor de 100 mil dólares anuales - ETC ¿Es esto posible? la mejor idea es siempre buscar un equilibrio entre la calidad del servicio y el costo de modo que se pueda cumplir con los requerimientos del negocio. Los procesos en la Operación del servicio son: - Gestión de Incidentes - Gestión de Eventos - Cumplimiento de Solicitudes - Gestión de Problemas - Gestión de Accesos GESTION DE INCIDENTES El objetivo principal de la Gestión de incidentes es restaurar los niveles normales del servicio lo mas rápido posible, asegurando el cumplimiento del SLA (calidad, tiempo y disponibilidad)

El diagrama explica la relación entre un incidente, problemas, KE (error conocido), workaround (solución temporal) y un RFC (solicitud de cambio). Cuando hablamos de incidentes es inevitable hablar de escalamiento, imaginemos que llaman por un problema de red, la persona que le contesta no puede ayudarlo entonces pasa a otra persona que conoce mas del asunto y si esta persona no puede, pasa a un certificado en CCNA y así sucesivamente; a este proceso se le llama ESCALAMIENTO y existen 2 tipos: - Escalamiento funcional (horizontal): Cuando se involucra a otra persona con mayores conocimientos en el tema. - Escalamiento jerárquico (vertical): Cuando se necesita de autoridad para realizar una acción. Sobre los tipos de escalamiento, siempre vienen preguntas en el examen de ITIL.

Lo que hace la gestión de incidentes se puede resumir en un solo grafico.

La gestión de incidentes tiene un proceso bastante grande y por consiguiente complejo, voy a describir al detalle cada uno de las actividades del proceso: Detección, comunicación y registro Parece sencillo poder describir “la detección de incidentes” y en efecto la descripción es sencilla pero la implementación no lo es, ITIL recomienda herramientas automatizadas para la detección de un incidente; cuando hablamos de herramientas automatizadas estamos hablando de SOFTWARE que nos ayude en dicha función. En el mercado existen diversas herramientas, desde OpenSource como CACTI o NAGIOS hasta herramientas de pago como TIVOLI o UNICENTER, lo ideal es que el principal mecanismo de detección de un incidente no sea la llamada de alerta de un usuario sino que sea un mecanismo de alerta automatizado. Entonces la “detección” debería ser automatizada en primera instancia, recibida por el personal del centro de servicios, reportada por el mismo personal de TI o directamente reportada por el usuario final; cualquiera que sea el mecanismo de detección TODO INCIDENTE DEBE SER REGISTRADO Y DEBE SER ASIGNADO UN NUMERO.

¿Absolutamente todo debe ser registrado? Sí!!! absolutamente todo incidente debe ser registrado, ITIL insiste en registrar todo incidente por mas insignificante que podría resultar y parecer. ¿Dónde lo registro? ITIL v3 no especifica donde registrarlo pero se recomienda tener una herramienta de registro de incidentes que nos ayudara para los reportes y futuras auditorias de TI. No quiero irme por las ramas con el tema de auditoria pero en empresas serias existe algo que se llama CONTROL INTERNO (Auditoria Interna) que registra todos los incidentes que deberían concordar con nuestra BD de incidentes. ¿Qué registro? Pues absolutamente todo!!! ITIL recomienda registrar lo siguiente: Numero de identificación, clasificación, fecha, quien detecto el incidente, síntomas, categorías, IMPACTO, PRIORIDAD, CIs, KnowError, fecha de resolución y notas de seguimiento. Como habrán notado el éxito de la implementación de ITIL esta en NO SUPONER u OBVIAR DETALLES. ¿A quién comunico el incidente? Los incidentes de gran impacto deben ser comunicados a todo el personal de TI con el objetivo de mantenerse informado y alerta y no registrar 2 veces el mismo incidente. Registrar 2 veces el mismo evento es uno de los principales errores que se comente en la GESTION DE INCIDENTES.

Clasificación, comparación y apoyo inicial La imagen superior muestra un ejemplo de clasificación, ITIL no te dice como debes clasificarlo eso depende de los procesos de la organización, de la misma manera la clasificación por prioridad debe regirse a políticas particulares dentro de la organización. Después de haber detectado el problema la gestión de incidentes debe tratar de resolver de manera rápida, ellos son la primera línea de defensa, son EL APOYO INICIAL. Para tratar de resolver el incidente y restablecer el funcionamiento correcto se ayuda de la BD de

Errores conocidos y la BD de Workarounds (soluciones temporales), si a pesar de ello no se puede solucionar el incidente se procede a escalar el incidente. Hay que tener cuidado en NO REPETIR EL TRABAJO y esto pasa por una COMPARACION de síntomas de otros incidentes. Investigación y diagnostico Después de haber sido detectado, registrado, clasificado y no haber podido resolver el problema de manera rápida, pasamos a la investigación del incidente hasta dar con la causa del problema. Este proceso puede pasar por distintos niveles de escalamiento y de expertos. Resolución y Recuperación Se dio con la causa del problema y se provee de un workaround y se restablece el servicio; si es necesario un cambio se le comunica a la GESTION DE CAMBIOS. Cierre del incidente Se confirma que el incidente ha sido resuelto y se documenta el cierre del caso. Hay otros temas que también hay tener en cuenta como por ejemplo MANTENER AL USUARIO SIEMPRE INFORMADO!, ¿cómo piensa el usuario? el usuario cuando nadie lo llama piensa que nadie se esta encargando de resolver su problema y luego vienen las quejas!!! es mejor mantener al usuario siempre informado. Otro tema muy importante es el MAL ESCALAMIENTO, muchas veces se abusa del escalamiento y cualquier problema es ESCALADO rápidamente distrayendo a los especialista en temas que no son importantes. (ESTA ES PREGUNTA DE CERTIFICACION ITIL). Y por ultimo y quizás el mayor problema que presenta la gestión de incidentes es la falta de un SLA y Catalogo de servicios, cuando estos documentos no están presentes cualquier problema relación con tecnología va ser automáticamente asignado al área de TI sin importar temas como tiempo y recursos.

No olvidar que ITIL cuantifica todo, por ello nosotros debemos ser capaces de tener reportes de la gestión de incidentes que respondan a las siguientes preguntas: - ¿Cuántos incidentes se han presentado en un periodo de tiempo? - ¿Cuántos incidentes de software hemos tenido? - ¿Cuántos incidentes han sido escalados hasta los especialistas? - ¿Cual es el tiempo de respuesta ante un incidente? ¿Cumplo con el SLA? - ¿Qué área presenta mayores incidentes? - Etc GESTION DE EVENTOS La principal diferencia entre evento e incidente radica en que TODO INCIDENTE es un evento pero NO TODO EVENTO es un incidente, por ejemplo en el primer ejemplo de este post (que esta casi al comienzo) se tiene un evento en la red, un aumento del 40% del ancho de banca, este evento no es un INCIDENTE porque el aumento de 40% del ancho de banda en un red LAN esta dentro del rango de lo permitido. Sin embargo un incidente como la caida de un servicio definitivamente es un evento perjudicial. Sobre los evento ITIL v3 no hace demasiado hincapié pero debemos tener bien claro lo siguiente: - ITIL v3 no se puede implementar sin herramientas que monitoreen los eventos, necesariamente necesitamos herramientas que automaticen el trabajo! - Todos los eventos deben ser registrados, absolutamente todos, para la rápida y presta detección de incidentes u acontecimientos irregulares dentro de la organización. CUMPLIMIENTO DE SOLICITUDES ITIL v3 establece un proceso para atender las solicitudes de los usuarios. Los objetivos de este proceso es: - Establecer un procedimiento estándar de solicitud de servicios, por ejemplo el estándar podría ser ingresar a una pagina web y responder ciertas preguntas. - Realizar cambios menores que no sean críticos en la organización y que tampoco puedan tener un impacto en el servicio, por ejemplo la solicitud de cambio de contraseña de un usuario para algún sistema especifico; por lo general este tipo de cambios no necesitan un RFC (Request For Change). - Establecer mecanismos y protocolos de respuesta a inquietudes y preguntas de usuarios. GESTION DE PROBLEMAS La Gestión de problemas administra todo el ciclo de vida del problema, desde que se inicia hasta que se tiene una solución al problema, entonces aquí salta una pregunta: “¿Que es un problema para ITIL?”. ITIL hace un diferencia importante entre incidente y problema, un incidente es algo

pequeño, algo asilado quizás o cuyo impacto es menor; en cambio un problema es un incidente recurrente, un incidente que afecta a muchos usuarios o un incidente de un gran impacto. Algunos conceptos: KnowError (KE – Error conocido): ITIL apunta a que todo problema debe ser resuelto y dar como resultado un KE, un KE es entender la causa de la falla y no necesariamente conocer la solución, es decir ITIL recomienda tener registrado todos los errores en una BD, Base de Datos de Errores conocidos (KEDB).

ITIL v3 lo ve de la siguiente manera, todo comienza en la Gestión de incidentes, el incidente es repetitivo (se convierte en un problema) y por ende pasa a la Gestión de problemas, se investiga las causas del problema hasta dar con el origen del mismo, cuando se tiene el conocimiento necesario de las causas del problema se genera un Workaround (solución temporal) y el problema sufre un cambio, una mutación!!; pasa de ser un problema a un Know Error (KE). Por ultimo KE debe generar un RFC para hacer el cambio correspondiente y solucionar el problema, La Gestión del Cambio se encargara de este proceso. Como habremos notado la Gestión de Incidentes y la Gestión de Problemas van de la mano y están muy relacionados. ¿De qué manera están relacionados? Lo primero que debemos notar es que la gestión de problemas no va a estar preocupándose

por todos los incidentes que ocurren en la organización, la Gestión del Problema NO SOLUCIONA INCIDENTES!!!, la gestión de problemas no busca una solución rápida sino que toma cierto tiempo para investigar la causa del problema para poder eliminarla en la Gestión del Cambio. La única manera en que la Gestión de Problemas apoya a la Gestión de Incidentes es proporcionándole soluciones temporales (workarounds).

La Gestión de Problemas tiene los siguientes procesos: Control de problemas - Define e investiga los problemas y su principal función es transformar los problemas en KE. - La principal fuente de información para el registro de problemas es la BD del registro de incidentes.

Control de Errores - Se ocupa de resolver Errores Conocidos (KE) mediante la Gestión de Cambios, la Gestión de problemas se encarga de todo el ciclo de vida del problema lo que quiere decir que debe estar monitoreando el cambio que sera realizado por la Gestión de Cambios.

Como en todos los procesos de ITIL con la BD de los Errores Conocidos nosotros debemos poder sacar informes de gestión: cantidad de problemas resueltos, tiempo tomado para resolver problemas, costos asociados con los problemas, etc. GESTION DE ACCESO Hablar de seguridad de la información es un tema demasiado relevante en la actualidad e ITIL v3 no puede estar totalmente aislado de este tema. Si bien es cierto que el negocio de ITIL no es la seguridad porque para eso existen ISOs como la 27001, ITIL de alguna manera quiere contribuir con la Gestión de Acceso. La gestión de acceso lo que hace es brindar derechos a los usuarios para facilitarles el uso de uno o varios servicios. Por ejemplo el día de mañana va ingresar un nuevo Director General a la organización, esta persona debe tener acceso a ciertos sistemas que normalmente no son accedidos por cualquier trabajador convencional, ESTO ES EL TRABAJO DE LA GESTION DE ACCESO. Mantenimiento al Catálogo de Roles de Usuarios y Perfiles de Acceso Asegurar que el Catálogo de Roles de Usuarios y los Perfiles de Acceso de Usuarios sean apropiados para los servicios ofrecidos a los clientes, y prevenir una acumulación indeseada de derechos de acceso.

Procesamiento de Solicitudes de Acceso al Usuario Procesar pedidos para agregar, cambiar o revocar derechos de acceso, y asegurar que sólo los usuarios autorizados tengan derecho a usar determinados servicios.

Voy a tratar de ser breve porque el primer post sobre Service Operation me explaye bastante pero creo que valía la pena. Hasta ahora hemos tocado los siguiente capítulos de ITIL v3: - Introducción a ITIL v3 - Estrategia del Servicio - Diseño del Servicio - Transición del Servicio - Service Operation – Parte I Es evidente que para poder entender en su totalidad este post, les recomiendo antes haber leído los posts arriba mencionados. La Operación del Servicio (SO) se encarga de mantener que todos los servicios funcionen correctamente siempre, se encarga de las operaciones del día a día y son los que tienen contacto directo con los usuarios. ¿Quienes son los que realizan este trabajo? Existe un grupo humano encargado de realizar esta laboriosa y a veces tedioso trabajo, ellos son los chicos de SERVICE DESK. Si alguien pensó que la respuesta a la pregunta era HELP DESK, no lo culpo porque es la respuesta mas lógica y la que seguro la mayoría de las personas, que inclusive están envueltos en el mundo de IT, hubieran respondido.

¿Service Desk o Help Desk? Para comenzar a despejar el panorama sobre la diferencia entre ambos es importante recalcar que la principal diferencia radica en una nueva manera de atender a los usuarios finales. En términos prácticos Service Desk esta un nivel mas arriba que Help Desk ya que contiene nuevas funciones que mejoran todo el proceso de Service Operation. No desesperen que mas abajo lo explico mejor y prometo que al terminar de leer esto van a entender claramente la diferencia. ¿Donde trabaja Service Desk? ITIL v3 indica que Service Desk actúa sobre la Gestión de eventos, Gestión incidentes y cumplimiento de solicitudes. ¿Actúa sobre la Gestión de problemas y la Gestión de Acceso? La respuesta es obvia, NO!! la Gestión de problemas se toma cierto tiempo para poder encontrar la causa del problema y generar un Know Error y un RFC por lo que se infiere que en la Gestión de problemas actúan los especialistas; de la misma manera en la Gestión de Acceso son personas con cierto nivel de autorización quienes son capaces de poder dar los privilegios correspondientes a los usuarios. Service Desk es un punto rápido de contacto donde se resuelven incidentes de la manera mas rápida posible, esto nunca lo olviden!!! (lo voy a poner en negrita y de rojo).

Entonces…. ¿Qué hace Service Desk? - Resuelve incidentes - Escalamiento adecuado, no todo debe ser escalado lo ideal es que Service Desk pueda resolver un 70% u 80% de todos los casos. - Mantener a los usuarios informados del status de su incidente o problema. - Cumplir el acuerdo de atención del SLA. Service Desk además cumple un ROL importante, Service Desk es el único punto de contacto para atender servicios, a esto ITIL llama SPOC. Aquí entra un poco de cultura organizacional, aquí unos ejemplos: - Llama directo al Administrador de Base de Datos, el sabe como solucionar el problema. - Llama a este chico porque es mi amigo y nos va atender rápido. - Dame tu numero de anexo para llamarte cualquier cosa. - ¿Aló Helpdesk? Pásame con el que sepa mas de Outlook.

Estoy seguro que alguna vez han escuchado estas frases,verdad? y ¿como resolver este problema? la solución no están sencilla y tomar la decisión de cambiar esto y no contestar llamadas personalizadas pasa por un cambio en la cultura organizacional y de los usuarios, un cambio gradual es lo ideal; además de un cambio de tecnología también como por ejemplo agregar mas números telefónicos a la central de Service Desk. No debemos olvidar que no es posible implementar ITIL v3 si no contamos con las herramientas debidas. ¿Por qué es malo que llamen a una persona de IT de manera individual? Existen una infinidad de respuestas para esta pregunta pero para muestra un botón, cuando llaman directamente a un Administrador de BD o Servidores lo que esta haciendo es distraerlo de sus verdaderas funciones y le resta tiempo; además que estos casos o incidentes no son registrados en la CMDB por lo que no podemos llevar un control cuantitativo de todos los casos atendidos por el Service Desk. ITIL debe ser capas de registrar todo para poder estimar tiempos, costos y mejorar el servicio. Tipos de Service Desk Service Desk Local: Es el clásico service desk de una empresa, donde existe un grupo de usuarios locales y un solo centro de servicio. Service Desk Centralizado: El mejor ejemplo aquí son las organizaciones que prestan servicios de Service Desk a otras organizaciones, por ejemplo las organizaciones que brindan soporte a los Bancos. Aquí existen múltiples usuarios y un solo centro de servicio. Service Desk Virtual de Servicios Centralizados: Aquí el ejemplo son las grandes empresas de Internet, por ejemplo MySQL Support (La versión Enterprise de MySQL brinda este servicio) tiene diferentes centros de Servicio: uno para Latinoamérica, otro para China, etc etc pero todos son contactados por un único medio, mediante la creación de un ticket mediante su pagina web.

La imagen superior explica las maneras en como Service Desk recibe solicitudes de atención: correo, vía telefónica, vía web, etc y además no olvidemos que cualquier tipo de servicio, CUALQUIER!!! debe ser recibido por Service Desk. IMPLEMENTAR UN SERVICE DESK La implementación no es tan simple como parece, requiere una dedicada planificación y debe responderse las siguientes preguntas: - ¿Cuáles son las necesidades? - ¿Cuáles serán sus funciones? - ¿Que calificaciones profesionales poseerán sus integrantes? - ¿Qué tipo de Service Desk necesitamos: local, centralizado o virtual? - ¿Qué herramientas tecnológicas necesitamos? - ¿Qué métricas determinaran el rendimiento? El factor humano juega aquí un rol muy importante, el factor humano debe: - Establecer estrictos protocolos de interacción con el cliente, estándares de comunicación desde el saludo hasta las preguntas de rutina a realizar. - Informar a los clientes de los beneficios del Service Desk. Estructura lógica del Service Desk - Conocer los protocolos de comunicación con el cliente, conoces los cheklists (preguntas de rutina a realizar para determinar la causa del incidente). - Disponer y conocer las herramientas de software para el registro e interacción con el

usuario. - Conocer cuando hacer un escalado a instancias superiores. - Tener rápido acceso a la base del conocimiento para ofrecer un mejor servicio a los usuarios. Indicadores Claves de Rendimiento La manera de saber si mi Service Desk esta funcionando adecuadamente para por responder las siguientes preguntas: - ¿Se atiende rápido el teléfono? - ¿Cumplo con los tiempos acordados en el SLA? - ¿Cuanto tiempo pasa hasta escalar la llamada a un segundo nivel? - ¿Cuantos casos escalo a un segundo o tercer nivel? - ¿Los usuarios reciben consejos de como prevenir incidentes? - ¿Se atiende el teléfono con educación? Informes de Gestión Como en todos los procesos de ITIL, debemos ser capaces de poder tener informes detallados sobre nuestro Service Desk. - % de incidentes que pueden resolverse sin recurrir a otros niveles de soporte. - Numero total de llamadas recibidas. - Tiempo total de resolución y promedios de tiempo de resolución. - Etc Factores Críticos de Éxito Existen factores que determinan el éxito o fracaso de un Service Desk, estos factores son: - Difícil manera de contactar a Service Desk, si los usuarios encuentran complicado contactar con Service Desk simplemente no verán los beneficios de este y buscaran otro tipo de soporte. - Si los usuarios tratan de contactar directamente a los especialistas, automáticamente deben ser remitidos al Service Desk. ¿Cuál es el objetivo principal de Service Desk? Resolver el mayor numero de incidentes, ser la primera línea de defensa de TI de manera que los especialistas puedan concentrarse en su verdadero trabajo.

Existen además diversas políticas de como implementar un Service Desk y depende de las necesidades de la organización y del SLA, por ejemplo en algunas organizaciones como las publicas se tiene un Service Desk con personas especializas y dedicas en brindar ayuda a personas de alto cargo como ministros o embajadores; es decir su único trabajo es brindarles servicio a ellos mientras que otros atienden al resto de usuarios; todo esto depende obviamente de las políticas de la organización.