Documentos de Académico
Documentos de Profesional
Documentos de Cultura
2 INTRODUCCIÓN AL DISEÑO
2.1 DISEÑO DEL SERVICIO: En la fase del Diseño del Servicio se deben de seguir
las pautas establecidas en la fase de Estrategia para conseguir:
2.2 PROPÓSITO DE DISEÑO DEL SERVICIO: Es diseñar servicios de TI, junto con
las prácticas, procesos y políticas requeridas, para implementar la estrategia del
proveedor de servicios y facilitar la introducción de dichos servicios al entorno
operativo.
Durante la etapa de diseño debe generarse un 'Paquete de Diseño del Sen/icio' o SDP
para cada nuevo servicio, cambio importante o retirada de un servicio o cambios en el
propio 'Paquete de Diseño del Servicio'. Este paquete pasa de Diseño del Servicio a
Transición del Servicio y detalla los aspectos del servicio y de sus requisitos a través
de las etapas posteriores de su ciclo de vida. El SDP debe contener:
● Proceso de negocio: Para definir las necesidades funcionales del servicio que se
está proporcionando, p.ej., telemarketing, facturación, pedidos, comprobación de
crédito.
● Servicio: El propio servicio que se está entregando a los clientes y al negocio
mediante el proveedor de servicio, por ejemplo, correo electrónico, facturación.
● SLAs/SLRs: los documentos acordados con los clientes que especifican el nivel,
ámbito y calidad del servicio a proveer.
● Infraestructura: Todos los equipos de TI necesarios para entregar el servicio a los
clientes y usuarios, incluyendo servidores, circuitos de red, switches, PCs, teléfonos.
● Entorno: El entorno requerido para asegurar y operar la infraestructura, por
ejemplo, centros de datos, alimentación, aire acondicionado.
● Datos: Los datos necesarios para dar soporte al servicio y proporcionar la
información requerida por los procesos de negocio, por ejemplo, registros de
clientes, libro mayor de contabilidad.
● Aplicaciones: Todas las aplicaciones de software requeridas para manipular los
datos y proporcionar los requisitos funcionales de los procesos de negocio, por
ejemplo, ERM, Financieros, CRM.
● Servicios de Soporte Cualquier servicio que sea necesario para dar soporte a la
operación del servicio entregado, por ejemplo, un servicio compartido, un servicio de
red gestionado.
● Acuerdos de Nivel Operativo (OLA) y contratos Cualquier acuerdo de soporte
necesario para entregar la calidad del servicio acordada dentro del SLA.
● Equipos de Soporte Cualquier equipo de soporte interno que proporciona soporte
de segunda y tercera línea para cualquiera de los componentes requeridos para
proporcionar el servicio, por ejemplo, Unix, mainframe, redes.
● Suministradores Cualquier tercero externo necesario para proveer soporte de
tercera y cuarta línea para cualquier componente requerido para proveer el servicio,
por ejemplo, redes, hardware, software.
3.2 LAS 4 Ps: Muchos diseños, planes y proyectos fallan por la falta de preparación y
gestión. La implementación de Gestión del Servicio de ITIL como práctica trata sobre
la preparación y planificación del uso eficaz y eficiente de las cuatro P: las Personas,
los Procesos, los Productos (servicios, tecnología y herramientas) y los Socios
(Partners) (suministradores, fabricantes y proveedores).
Diseño del Servicio deberá considerar todos los elementos del mismo asumiendo un
método integral para el diseño de un nuevo servicio. Este método debería considerar
el servicio y sus componentes y sus interrelaciones, garantizando que los servicios
entregados cumplan la funcionalidad y calidad esperadas por el negocio en todas las
áreas:
● La escalabilidad del servicio
● Los procesos de negocio
● El servicio de TI
● El propio servicio y su Requisito de Nivel de Servicio (SLR) o Acuerdo de Nivel
de Servicio (SLA).
● Los componentes tecnológicos
● Los servicios y componentes a los que se les da soporte internamente (OLAs)
● Los servicios y componentes a los que se les da soporte externamente
● Las medidas y métricas de rendimiento requeridas.
● Los niveles de seguridad requeridos o legislados
Las arquitecturas y diseños deberán ser claros, concisos, simples y pertinentes. Con
suma frecuencia, los diseños y arquitecturas son complejos y teóricos y no se
corresponden con el mundo real.
Las áreas que es necesario considerar dentro del diseño de la solución del servicio
deberán incluir:
● Analizar los requisitos de negocio acordados
● Revisar los servicios e infraestructura de TI existentes
● Diseñar las soluciones del servicio para los nuevos requisitos
● Garantizar que se incorporen los contenidos de los Criterios de Aceptación del
Servicio (SAC)
● Evaluar y calcular el coste de diseños alternativos
● Acordar el gasto y los presupuestos
● Reevaluar y confirmar los beneficios para el negocio
● Acordar la solución elegida y sus resultados y objetivos planificados (Requisito de
Nivel de Servicio (SLR)).
● Comprobar que la solución está equilibrada con todas las estrategias, políticas,
planes y documentos de arquitectura corporativos y de TI.
● Garantizar que se incluyan con la solución todos los controles adecuados de
seguridad y gobierno corporativos y de TI.
● Completar una 'evaluación de la buena disposición organizativa' de TI para
garantizar que el servicio pueda operarse eficazmente.
● El montaje de un Paquete de Diseño del Servicio (SDP) para la posterior
transición, operación y mejora de la solución del servicio nueva o modificada.
● Cada proceso deberá contar con un propietario del proceso que será
responsable del proceso y de su mejora y asegurará que el proceso cumpla sus
objetivos.
● Los objetivos de cualquier proceso de TI deberán definirse en términos
medibles y deberán expresarse en términos de beneficios para el negocio y
sustentar los objetivos y estrategia del negocio.
● Diseño del Servicio debería ayudar a cada propietario del proceso en el diseño
de procesos, para garantizar que todos los procesos usen términos y plantillas
estándar, que sean consistentes y se integren con los demás para proveer una
integración extremo a extremo en todas las áreas.
● La salida generada por un proceso tiene que cumplir las normas operativas que
se deriven de los objetivos de negocio.
● Si los productos cumplen la norma establecida, el proceso podrá considerarse
eficaz (ya que puede repetirse, medirse y gestionarse).
● Si las actividades se llevaran a cabo con un uso mínimo de recursos, el proceso
también se puede considerar eficiente.
● El análisis, resultados y métricas del proceso deberán incorporarse en informes
regulares de gestión y en mejoras del proceso.
● El trabajo con procesos definidos ha sido la base de ITIL desde el principio.
● Con la definición de cuáles son las actividades de la organización, qué entradas
son necesarias y qué salidas resultarán del proceso, es posible trabajar de una
forma más eficiente y eficaz.
● La medición y dirección de las actividades incrementa esta eficacia.
Finalmente, si se añaden normas al proceso será posible añadir medidas de
calidad a la salida.
● Este método sustenta el ciclo Planificar-Hacer-Verificar-Actuar de la mejora
continua para cualquier sistema de gestión de la calidad.
● Planificar el propósito del proceso de tal forma que se puedan revisar, evaluar
o auditar las acciones del proceso para lograr mejoras y el éxito.
El cuadro RACI muestra la estructura y posibilidades del modelado RACI. Incluye las
actividades en el lado izquierdo con las acciones necesarias que deben acometerse y
las decisiones que deben tomarse. En la parte superior el cuadro se indican los roles
funcionales responsables de llevar a cabo la iniciativa o de tomar parte de la toma de
decisiones.
ANÁLISIS DE ACTIVIDADES
Cuando se haya diseñado la solución del servicio deseada, más tarde deberán
completarse las actividades posteriores con la etapa Diseño del Servicio antes de que
la solución pase a la etapa de Transición del Servicio.
● Evaluación de soluciones alternativas
● Aprovisionamiento de la solución elegida
● Desarrollo de la solución del servicio
Siempre que sea posible, las organizaciones del proveedor de servicios de TI deberán
utilizar SOA y sus fundamentes para desarrollar servicios de TI flexibles y reutilizables
que sean comunes y puedan compartirse y explotarse entre muchas áreas diferentes
del negocio. Cuando se utiliza este método, es fundamental que TI:
Estrategia de entrega:Descripción
4 PROCESOS
4.1.3- OBJETIVOS
4.1.6- POLITICAS
Las políticas y estándars de coordinación del diseño deben producir los mejores SDPs
posibles para la menor inversión posible en tiempo y esfuerzo. Las políticas de
coordinación del diseño deben incluir:
4.1.12 INTERFACE
G. Evaluación del Cambio Coordinación del diseño asegura que los recursos
estén disponibles para la evaluación de los cambios. Esto también incluye la
evaluación del diseño del servicio para asegurar que éste cumple con los
requisitos previstos.
G. Nivel del Servicio Coordinación del diseño desarrolla las prácticas, junto
con Gestión de Nivel de Servicio, para de manera constante definir y acordar
los aspectos de la garantía del diseño del servicio, asegurando que se abordan
de forma adecuada todas las partes del diseño de la solución del servicio y del
SDP.
CSF: KPIs:
SDPs precisos y • Reducción en el número de revisiones del contenido del SDP.
coherentes. • Porcentaje de reducción en los subsiguientes trabajos en las nuevas
soluciones de servicio.
4.1.14 DESAFIO
4.2.3- OBJETIVOS
4.2.6- POLITICAS
● Los servicios incluidos en el Catálogo de servicios estarán basados en políticas
predefinidas de la organización.
● Cada organización debe desarrollar una política sobre cómo definirán sus servicios.
El éxito de la política se mide por el grado en que ésta facilita una provisión de
servicios eficaz y eficiente.
4.2.10 ENTRADAS
● Información del negocio (estrategia, planes y planes financieros, requerimientos).
● BIA - información sobre el impacto, prioridad y riesgos asociados a cada servicio.
● Los requisitos de negocio: información sobre los requisitos de negocio acordados,
nuevos o modificados desde la cartera de servicios
● Portfolio de servicios, CMS y RFCs
● Retroalimentación proveniente de todos los otros procesos.
4.2.12 INTERFACES
● G. Relaciones Negocio BRM asegura que la relación entre el serv y el cliente está
claramente definida en términos de cómo el serv apoya las necesidades del cliente.
● G. Nivel del Servicio SLM negocia los niveles de garantía del servicio que se
entregarán y que figurarán en el Catálogo de servicios.
CSF: KPIs:
4.2.14 DIFICULTADES
Las mayores dificultad a las que se enfrenta gestión del Catálogo de servicios son:
● Mantener un Catálogo de servicio preciso.
● Incorporar las vistas del Catálogo en el CMS y el SKMS.
4.2.15 RIESGOS
● Imprecisión de los datos en el catálogo y que no estén sometidos a un control de
cambios riguroso
● Deficiente aceptación del Catálogo de Servicios y su uso en todos los procesos
operativos.
● Mientras más activo sea el catálogo, más probable es que sea preciso en su
contenido Imprecisión en la información recibida del negocio, de TI y del
Porfolio de Servicios en relación con la información del servicio
● Las herramientas y recursos requeridos para mantener la información
● Acceso deficiente a información y procesos precisos de Gestión de Cambios
● Acceso y soporte deficiente de CMS y SKMS actualizados y apropiados
● Elusión del uso del Porfolio de Servicios y del Catálogo de Servicios.
● La información es o demasiado detallada para mantenerla de forma precisa o
está a un nivel demasiado alto para tener algún valor.
● Debería ser consistente con el nivel de detalle dentro del CMS y del SKMS.
4.3.2- PROPÓSITO del proceso de SLM es garantizar que todos los servicios
operativos y su rendimiento se midan de forma profesional y consistente en toda la
organización de TI, y que los servicios y los informes generados satisfagan las
necesidades del negocio y de los clientes.
4.3.3- OBJETIVOS
4.3.4- ALCANCE
SLM debería proporcionar una comunicación y punto de contacto regular con los
clientes y gestores de negocio de una organización.
4.3.9 DISPARADORES
4.3.10 ENTRADAS
4.3.11 SALIDAS
4.3.12 INTERFACES
CSF: KPIs:
4.4.3- OBJETIVOS:
4.4.4- ALCANCE
4.4.6- POLITICAS
Para lograr eso, Gestión de la Disponibilidad debe llevar a cabo actividades reactivas y
proactivas representadas en la Figura anterior.
4.4.7- CONCEPTOS BÁSICOS
MTRS debe utilizarse para evitar la ambigüedad del término más habitual de la
industria Tiempo Medio de Reparación (MTTR), que en algunas definiciones incluye
sólo el tiempo de reparación, pero que en otras incluye el tiempo de recuperación.
El tiempo de caída en MTRS cubre todos los factores que hacen que el servicio,
componente o Cl no esté disponible: Tiempos de registro, de respuesta, de
resolución, de reparación o sustitución física, de recuperación,...
4.4.10 ENTRADAS
4.4.11 SALIDAS
CSF: KPIs:
4.4.14 DIFICULTADES
4.4.15 RIESGO
4.5.1- INTRODUCCIÓN
● Gestión de la Capacidad es un proceso que se extiende a través del Ciclo de
Vida del Servicio. Un factor clave del éxito es gestionar la capacidad para
garantizar que sea incluida durante la etapa de diseño.
● Gestión de Capacidad se apoya inicialmente en Estrategia del Servicio donde
las decisiones y el análisis de los requisitos del negocio y de los resultados del
cliente influyen en el desarrollo de los modelos de actividades de negocio
(PBA), niveles de servicio (LOS) y paquete del nivel de servicio (SLP). Esto
proporciona indicadores de capacidad predictivos y continuos necesarios para
alinear la capacidad con la demanda.
4.5.3- OBJETIVO
4.5.4- ALCANCE
4.5.6- POLITICAS
Plan de capacidad:
● Contiene información sobre el uso actual de servicios y componentes.
● Contiene planes para el desarrollo de la capacidad de TI para satisfacer las
necesidades en la expansion tanto de servicios existentes como de cualquier
nuevo servicio acordado.
● Debe utilizarse activamente como base para la toma de decisiones. Éste se
basa en tres subprocesos.
● Gestión de la capacidad del Negocio → Gestión de la capacidad del Servicio →
Gestión de la capacidad del Componente
4.5.8 ACTIVIDADES