8/18/2016 ITIL v3: Service Design (Diseño del Servicio) | Blog de Omar

RSS |

Blog de Omar
Just another WordPress weblog

Home
Acerca de MI
FAQ
MIS VIDEOS

Search  Search

ITIL v3: Service Design (Diseño del Servicio)
Enero 17, 2010 | 10 comments | ITIL

Twittear

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

http://www.el­palomo.com/2010/01/itil­v3­service­design­diseo­del­servicio/ 1/11
8/18/2016 ITIL v3: Service Design (Diseño del Servicio) | Blog de Omar
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

http://www.el­palomo.com/2010/01/itil­v3­service­design­diseo­del­servicio/ 2/11
8/18/2016 ITIL v3: Service Design (Diseño del Servicio) | Blog de Omar
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

http://www.el­palomo.com/2010/01/itil­v3­service­design­diseo­del­servicio/ 3/11
8/18/2016 ITIL v3: Service Design (Diseño del Servicio) | Blog de Omar
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.

http://www.el­palomo.com/2010/01/itil­v3­service­design­diseo­del­servicio/ 4/11
8/18/2016 ITIL v3: Service Design (Diseño del Servicio) | Blog de Omar

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)

Popularity: 12% [?]

Si te gusto este post, asegurate de suscribirte a mi RSS feed!
Like ­ Dislike

http://www.el­palomo.com/2010/01/itil­v3­service­design­diseo­del­servicio/ 5/11