ITIL V3: SERVICE DESIGN (DISEÑO DEL SERVICIO)

Post gracias a Omar Palomino. (http://www.el-palomo.com/)

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:
  • 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

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)

Post gracias a Omar Palomino. (http://www.el-palomo.com/)