Está en la página 1de 56

DISEÑO

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:

o Que los servicios se adecuen a las necesidades del mercado.


o Que los servicios cumplan el estándar de calidad
o Que los servicios sean rentables
o Que los servicios aporten valor a los clientes

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.

2.3 OBJETIVOS DE DISEÑO DEL SERVICIO


● Diseñar servicios de TI que requieran una mínima mejora en el futuro.
● Diseñar servicios que satisfagan los objetivos del negocio y que estén alineados
con las necesidades del negocio.
● Diseñar infraestructuras y aplicaciones de TI que satisfagan las necesidades del
negocio y del cliente.
● Diseñar procesos
● Diseñar métricas y métodos de medición para la evaluación de los procesos de
diseño y sus entregables.
● Producir y mantener procesos, políticas, arquitecturas, marcos de trabajo y
documentación de TI para el diseño de soluciones de TI.
● Coordinar las actividades de diseño para servicios de TI.
● Diseñar servicios que se puedan desarrollar y mejorar de forma sencilla y
eficiente.
● Identificar y gestionar los riesgos.

2.4 ALCANCE DE DISEÑO DEL SERVICIO


● Nuevos servicios o servicios modificados.
● Sistemas y herramientas de Gestión del Servicio, especialmente el Porfolio de
Servicios, incluyendo el Catálogo de Servicios.
● Arquitectura tecnológica y sistemas de gestión.
● Los procesos requeridos.
● Métricas y métodos de medición.
2.5 VALOR DE DISEÑO DEL SERVICIO

● Reducción del Coste Total de Propiedad (TCO): El coste de propiedad sólo se


puede minimizar si todos los aspectos de los servicios, procesos y tecnología se
diseñan e implementan adecuadamente con respecto al diseño.
● Mejora de la calidad del servicio: Se mejorará la calidad del servicio y la calidad
operativa.
● Mejora de la consistencia del servicio: Dado que los servicios se diseñan dentro
de la estrategia, arquitecturas y restricciones corporativas.
● Mejora de la facilidad de implementación de servicios nuevos o
modificados: Dado que existe un Diseño del Servicio completo e integrado y la
producción de SDPs integrales.
● Mejora del alineamiento del servicio: Implicación desde la concepción del
servicio, garantizando que los servicios nuevos o modificados se correspondan con
las necesidades del negocio, y que los servicios diseñados cumplan los Requisitos
de Nivel de Servicio.
● Rendimiento del servicio más eficaz: Con la incorporación e identificación de la
Capacidad, Disponibilidad Financiera y Planes de Continuidad del Servicio de TI.
● Mejora del gobierno de TI: Ayudar a la implementación y comunicación de un
conjunto de controles para el gobierno eficaz de TI.
● Procesos de Gestión del Servicio y de TI más eficaces: Los procesos se
diseñarán con la rentabilidad y calidad óptimas.
● Mejora de la información y de la toma de decisiones: Medidas y métricas más
integrales y eficaces permitirán una mejor toma de decisiones y una mejora
continua de las prácticas de Gestión del Servicio en la etapa de diseño del Ciclo de
Vida del Servicio.
2.6 EL CONTEXTO DEL DISEÑO DE SERVICIO EN EL CICLO DE VIDA DEL
SERVICIO DE ITIL

● Estrategia del Servicio Definir las políticas, objetivos y espacios de mercados.


Estrategia del servicio es el eje alrededor del cual gira el ciclo de vida del servicio.
● Diseño del Servicio Diseño y desarrollo de servicios y prácticas de gestión
● Transición del Servicio Desarrollar capacidades para la introducción de los
servicios al entorno operativo.
● Operación del Servicio Gestión de los servicios en entornos operativos.
● Mejora Continua del Servicio Crear y mantener el valor para los clientes a través
de una mejor estrategia, diseño, transición y operación de los servicios.

2.5 PAQUETE DE DISEÑO DEL SERVICIO

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:

2.6 CRITERIOS DE ACEPTACIÓN DEL SERVICIO - SAC representan un conjunto


de criterios que sirven para garantizar que el servicio cumpla su funcionalidad y
calidad esperadas y que el proveedor de servicio esté preparado para entregar el
nuevo servicio una vez haya sido desplegado.

Criterios (Pregunta) - Responsabilidad (Respuesta)


● ¿Se han acordado la fecha de lanzamiento' y el período de garantía con todas las
partes interesadas, junto con los criterios de aceptación finales? Cambios, Nivel
de servicio
● ¿Se han acordado y documentado el proyecto de despliegue y la programación y
se han hecho públicos a todo el personal afectado? Cambios, Incidencias
● ¿Se ha revisado, repasado y acordado el SLA/SLR con todas las partes
interesadas? Nivel de servicio
● ¿Se han identificado a todos los clientes e interesados y se han registrado en el
CMS? Nivel de servicio, BRM
● ¿Se han evaluado todos los riesgos operativos asociados con la operación del
nuevo servicio y se han completado las acciones de mitigación en caso necesario?
Continuidad del Negocio
● ¿Se han identificado/aprobado a todos los usuarios y sus cuentas
correspondientes creadas para ellos? Gestión de Cuentas
● ¿Se han acordado, probado, documentado y aceptado todos los trabajos por lotes
y requisitos de impresión? Operaciones
● ¿Se han completado satisfactoriamente todos los planes de prueba? Gestor de
Pruebas
● ¿Se han completado satisfactoriamente todas comprobaciones y pruebas de
seguridad? Conformidad con la Seguridad
● ¿Incidencias, Problemas y todos los equipos de soporte de TI han proporcionado y
aceptado la documentación de soporte técnico? Incidencias, Problemas

3 PRINCIPIOS DE DISEÑO DEL SERVICIO


● Es importante que existan las interfaces y vínculos correctos para las actividades
de diseño. Al diseñar servicios nuevos o modificados, es vital que todo el Ciclo de
Vida del Servicio y procesos de ITSM se impliquen desde el principio.
● Para asegurar que las soluciones satisfacen los requerimientos del negocio, se
necesitan llevar a cabo ciertas acciones desde las fases iniciales del diseño del
servicio:
○ La nueva solución del servicio deberá añadirse al Porfolio de Servicios general
desde la fase de concepto, y el Porfolio de Servicios deberá actualizarse para
reflejar el estado actual a través de cualquier desarrollo incremental o iterativo
○ Dentro del análisis inicial del servicio/sistema, existirá la necesidad de entender
los Requisitos de Nivel del Servicio (SLRs) del servicio cuando pase a estar
activo.
○ A partir de los SLR, el equipo de Gestión de la Capacidad puede modelar esto
dentro de la infraestructura actual hasta cerciorarse de que podrá dar soporte
al nuevo servicio. Si el tiempo lo permite, los resultados de las actividades de
modelado podrán formar parte del Plan de Capacidad.
○ Si se requiriera una nueva infraestructura para el nuevo servicio, o ampliar el
soporte, Gestión Financiera necesitará implicarse para establecer el
presupuesto.
○ Deberá realizarse un Análisis de Impacto en el Negocio y una evaluación del
riesgo sobre los servicios antes de la implementación como entrada inestimable
en Estrategia de la Continuidad del Servicio de TI, Diseño de Disponibilidad y
Planificación de la Capacidad.
○ El Centro de Servicio al Usuario necesitará ser consciente de los nuevos
servicios antes de la operación real para preparar y formar al Centro de
Servicio al Usuario y potencialmente al personal del cliente de TI.
○ Transición del Servicio puede iniciar la planificación de la implementación e
incorporar la planificación de cambios.
○ Gestión de Suministradores necesitará implicarse si fuera necesario involucrar
a Compras para el nuevo servicio.
3.1 COMPOSICIÓN DEL SERVICIO

● 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).

3.3 DISEÑO EQUILIBRADO:


Este concepto es
extremadamente importante
para las actividades de Diseño
del Servicio y para el equilibrio
entre el esfuerzo que se dedica
en el diseño, desarrollo y
entrega de servicios como
respuesta a los requisitos de
negocio.

Para cualquier requisito de negocio, el diseño de servicios es un acto de equilibrio


delicado, garantizando que se cumplan los requisitos funcionales además de los
objetivos de rendimiento. Todo esto deberá equilibrarse en relación con los recursos
disponibles dentro de los plazos de tiempo requeridos y de los costes para los nuevos
servicios.

● Funcionalidad: el servicio o producto y sus instalaciones, funcionalidad y


calidad, incluyendo todas las funcionalidades operativas y de gestión
requeridas.
● Recursos: las personas, tecnología y dinero disponibles.
● Programa: los plazos de tiempo.
3.4 IDENTIFICACIÓN REQUISITOS DEL SERVICIO

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

Dentro del área específica de tecnología, existen cuatro dominios tecnológicos


independientes que será necesario abordar ya que son los componentes de soporte de
todo servicio y contribuyen a su rendimiento general:

● Infraestructura La gestión y control de todos los elementos de la


infraestructura, incluyendo mainframes, servidores, equipo de red, sistemas de
bases de datos, redes de área de almacenamiento (SANs), almacenamiento
acoplado a la red (ÑAS), software de sistemas, utilidades, sistemas de backup,
firewalls, entornos de desarrollo y prueba, herramientas de gestión, etc.
● Entorno La gestión y control de todos los aspectos del entorno de todas las salas
de equipos principales, incluyendo el espacio físico y distribución, alimentación,
aire acondicionado, cableado, seguridad física, etc.
● Datos la gestión y control de todos los datos e información y su acceso asociado,
incluyendo datos de prueba si fuera aplicable.
● Aplicaciones La gestión y control de todo el software de aplicaciones, incluyendo
aplicaciones compradas y software de aplicaciones desarrolladas internamente.

Información sobre los requisitos de servicios existentes:

o Requisitos funcionales y nuevas instalaciones.


o Cambios en procesos, dependencias, prioridades, criticidad e impacto en el
negocio.
o Cambios en los volúmenes de transacciones del servicio.
o Aumento de los niveles de servicio y objetivos de nivel de servicio debido a nuevas
directrices de negocio, o reducción de éstos para servicios antiguos, reduciendo la
prioridad para aquellos que se sustituirán.
o Necesidades adicionales para la información de Gestión del Servicio.

Información sobre los requisitos de nuevos servicios:

o Instalaciones y funcionalidades requeridas.


o Información de gestión requerida y necesidades de gestión.
o Procesos soportados, dependencias, prioridades, criticidad e impacto en el negocio.
o Ciclos de negocio y variaciones estacionales.
o Requerimientos de Nivel de Servicio y objetivos de nivel de servicio. o Niveles de
transacción del negocio, niveles de transacción del servicio, números y tipos de
usuarios y crecimiento futuro anticipado.
o Los resultados financieros y no financieros del caso de negocio.
o Nivel previsto de cambio, por ejemplo, futuros requisitos conocidos del negocio o
mejora.
o Nivel de capacidad del negocio o soporte a proveer, por ejemplo, soporte local
basado en el negocio.

Información sobre los requisitos de servicios a retirar:

o Alcance: las características y funcionalidad a ser retiradas.


o Caso de negocio, incluyendo los aspectos financieros y estratégicos.
o El servicio que reemplazará al servicio a ser retirado.
o Interfaces y dependencias: servicios, componentes, configuraciones.
o Requerimientos del negocio relacionados a la estrategia y plan de retirada del
servicio (ej. Retirada gradual o en fases).
o Archivar la estrategia y acceder a los requerimientos de datos del negocio.
o Eliminación o reutilización de requerimientos para activos y CIs del servicio.
En la etapa de requisitos de negocio se debe:

o Nombramiento de un jefe de proyecto, creación de un equipo de proyecto y


acuerdo de gobierno del mismo con la aplicación de una metodología de proyecto
formal y estructurada.
o Identificación de todos los interesados, incluyendo la documentación de todos sus
requisitos y o los beneficios de éstos que se obtendrán de la implementación.
o Análisis de requisitos, priorización, acuerdo y documentación.
o Determinación y acuerdo de presupuestos detallados y de los beneficios para el
negocio. La dirección deberá comprometerse con el presupuesto ya que es una
práctica normal decidir el presupuesto del año siguiente en el último trimestre del
año anterior, por lo que cualquier plan deberá enviarse dentro de este ciclo.
o Resolución de conflictos potenciales entre unidades de negocio y acuerdo dé los
requisitos corporativos.
o Procesos aprobados para los requisitos acordados y un método para acordar y
aceptar cambios en los mismos. En muchas ocasiones el proceso de desarrollo de
requisitos es un método iterativo o incremental que necesita controlarse
detenidamente para gestionar el aumento imprevisto del alcance.
o Desarrollo de un plan de compromiso que describa las relaciones principales entre
TI y el negocio y cómo se gestionan estas relaciones y la comunicación necesaria
para ampliar el número de interesados.

3.5 ACTIVIDADES DEL DISEÑO

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.

Actividades de los procesos de diseño:


● Recopilación de requisitos, análisis e ingeniería para garantizar que los requisitos
de negocio se documenten y acuerden claramente.
● Diseño adecuado de servicios, tecnología, procesos, información y medidas de
procesos para satisfacer requisitos de negocio.
● Revisión de todos los procesos y documentos implicados en Diseño del Servicio,
incluyendo diseños, planes, arquitecturas y políticas. Vinculación con los demás
roles y actividades de planificación y diseño, por ejemplo, diseño de solución.
● Producción y mantenimiento de políticas de TI y documentos de diseño,
incluyendo diseños, planos, arquitecturas y políticas.
● Revisión de todos los documentos de diseño, y planificación para el despliegue e
implementación de estrategias de TI con el uso de 'hojas de ruta', programas y
planes de proyecto.
● Evaluación del riesgo y gestión de todos los procesos y entregables del diseño.
● Garantizar el alineamiento con todas las estrategias y políticas corporativas y de
TI.

Las entradas a las diversas actividades de diseño:


● Visiones, estrategias, objetivos, políticas y planes, tanto corporativos, como del
negocio, incluyendo Planes de Continuidad del Negocio (BCPs).
● Restricciones y requisitos para adecuarse a las regulaciones y estándares
legislados.
● Estrategias de TI y documentos estratégicos (desde Estrategia del Servicio).
● Herramientas y técnicas de medida

Los entregables a partir de las actividades de diseño:


● Revisiones sugeridas para estrategias y políticas de TI. Diseños revisados,
planes y tecnología, y arquitecturas de gestión.
● Diseños para servicios, procesos y tecnologías nuevos o modificados.
● Informes de revisión y análisis del proyecto, con procesos y procedimientos
revisados y mejorados.
● Procesos y métodos revisados de medición.
● Niveles gestionados de riesgo, e informes de evaluación y gestión del mismo.
● Casos de negocio y estudios de viabilidad, junto con Declaración de Requisitos
(SORs) y Convocatorias de Licitación (ITTs).
● Comentarios y retroalimentación sobre los demás planes.
● Beneficio para el negocio y realización de revisiones e informes.

3.6 LOS 5 ASPECTOS DEL DISEÑO

3.6.1 DISEÑO DE SOLUCIONES DEL SERVICIO

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.

3.6.2 DISEÑO DEL PORTFOLIO DE SERVICIOS

Al actuar como la base fundamental para un marco de trabajo, un Portfolio de


Servicios clarifica o ayuda a clarificar las siguientes preguntas estratégicas:
● ¿Por qué debería adquirir un cliente estos servicios?
● ¿Por qué deberían comprar estos servicios?
● ¿Cuáles son los modelos de establecimiento de precios o reintegro?
● ¿Cuáles son mis fortalezas y debilidades, prioridades y riesgo?
● ¿Cómo deberían asignarse mis recursos y capacidades?

● Requisitos se ha recibido un conjunto de requisitos descritos del negocio o de


TI para un servicio nuevo o modificado.
● Definido se está evaluando, definiendo y documentando el conjunto de
requisitos para el nuevo servicio, y se está generando el SLR.
● Analizado se está analizando y priorizando el conjunto de requisitos para el
nuevo servicio.
● Aprobado se están finalizando y autorizando el conjunto de requisitos para el
nuevo servicio.
● Instituidos se está comunicando los requisitos del nuevo servicio y se están
asignando los recursos y presupuestos.
● Diseñado se está diseñando el nuevo servicio y sus componentes, y
aprovisionando si fuera necesario.
● Desarrollado se está desarrollando o recopilando el servicio y sus
componentes, si fuera aplicable.
● Construido se está construyendo el servicio y sus componentes.
● Probado se está probando el servicio y sus componentes.
● Entregado se está entregando el servicio y sus componentes.
● Operativo el servicio y sus componentes están operativos dentro del entorno
de producción.
● Retirado el servicio y sus componentes se están retirando.

El contenido debería incluir:


● Nombre, descripción, metricas y estado del servicio.
● Clasificación del servicio y criticidad.
● Aplicaciones usadas.
● Datos y/o esquema de datos usados.
● Procesos de negocio soportados.
● Propietarios y usuarios del negocio.
● Propietarios de TI.
● Referencias al Nivel de Garantía del Servicio, SLA y SLR.
● Servicios y recursos de soporte.
● Servicios dependientes.
● OLAs, contratos y acuerdos de soporte.
● Costes, cargos e ingresos del servicio (si fuera aplicable).

3.6.3 DISEÑO DE ARQUITECTURAS

Las actividades de diseño de la arquitectura dentro de una organización de TI están


implicadas con la provisión de las 'guías' estratégicas generales para el desarrollo y
despliegue de una infraestructura de TI, un conjunto de aplicaciones y datos que
satisfacen las necesidades actuales y futuras del negocio.

'Arquitectura' es un término usado en muchos contextos diferentes. En este contexto,


se define como: La organización fundamental de un sistema, materializado en sus
componentes, en sus relaciones con los demás y con el entorno, y en los principios
que guían su diseño y evolución.

En esencia, el diseño de la arquitectura puede definirse como: 'El desarrollo y


mantenimiento de políticas, estrategias, arquitecturas, diseños, documentos, planes y
procesos de TI para el despliegue y posterior operación y mejora de servicios y
soluciones adecuados de TI a través de una organización'.

El trabajo debería asegurar que:


● Las infraestructuras, entornos, datos, aplicaciones y servicios externos de TI
satisfagan las necesidades del negocio, sus productos y servicios. Esta
actividad no sólo incluye los componentes tecnológicos, sino también su
gestión.
● El equilibrio correcto se logra entre los aspectos de innovación, riesgo y coste
mientras se busca una ventaja competitiva.
● Haya conformidad con marcos de trabajo, estrategias, políticas, regulaciones y
estándares de la arquitectura.
● Se provee una interfaz coordinada entre diseñadores y planificadores de TI,
estrategas, diseñadores de negocio y planificadores

La Arquitectura de la Empresa es definida por Gartner como: 'el proceso de


traducción de la visión y estrategia del negocio en un cambio empresarial eficaz,
creando, comunicando y mejorando principios y modelos clave que describen los
futuros estados de la empresa y que permiten su evolución'.
Arquitectura del Servicio: Que traduce aplicaciones, infraestructura, organización
y actividades de soporte en un conjunto de servicios.
Arquitectura de Aplicaciones: Que proporciona una guía para el desarrollo y
despliegue de aplicaciones individuales.
Arquitectura de Datos/Información: Que describe los activos de datos lógicos y
físicos de la empresa y los recursos de gestión de datos.
Arquitectura de la Infraestructura de TI: Que describe la estructura,
funcionalidad y distribución geográfica de los componentes de hardware, software y
comunicaciones que apoyan y dan soporte a toda la arquitectura, junto con los
estándares técnicos que se les aplican.
Arquitectura del Entorno: Que describe todos los aspectos, tipos y niveles de los
controles del entorno y su gestión. En el Apéndice E se incluye un ejemplo del tipo
requerido de información del entorno.

3.6.3.1. Arquitecturas Tecnológicas: Las Arquitecturas son necesarias en todas


las áreas de la infraestructura de TI. Cuando sea pertinente, será necesario
desarrollarlas en las siguientes áreas:
● Aplicaciones y software de sistemas
● Información, datos y base de datos
● Arquitectura y diseño de la infraestructura
● Equipos y sistemas del entorno, incluyendo su monitorización y gestión

3.6.3.2. Arquitecturas Gestión: Existen 2 métodos independientes para desarrollar


una arquitectura de gestión:

● Selección de una arquitectura de gestión propietaria: Esto se basa en la


selección de un único conjunto de productos y herramientas de gestión a partir de
un único proveedor de soluciones propietarias de gestión.
● Selección de una arquitectura 'de la mejor clase': Este método implica la
selección de un conjunto de herramientas y productos de gestión 'de la mejor
clase' de varios proveedores de soluciones de gestión y a continuación integrarlas
para proveer una solución de gestión integral.

3.6.3.3 Gestión Integrada de la tecnología dirigida al negocio

● Negocio • Las necesidades, requisitos, procesos, objetivos y metas de las


unidades de negocio y gestores dentro de la organización.
● Personas • El ámbito, tareas y actividades de los gestores y del personal
implicado en la gestión de la provisión de servicios de TI.
● Procesos • Los procesos y procedimientos usados para gestionar servicios de TI
para el negocio y para sus clientes.
● Herramientas • Las herramientas de gestión y soporte requeridas para
gestionar de forma eficiente la infraestructura de TI.
● Tecnología • Los productos y tecnología de TI usados para entregar el servicio
e información a la persona correcta, en el lugar y momento adecuados.

● Diseño de arriba a abajo • Garantizando que los procesos, herramientas e


información de Gestión del Servicio y de gestión de la tecnología se alineen con
las necesidades y metas del negocio.
● Implementación de abajo a arriba: Garantizando que procesos eficientes y
eficaces de Gestión del Servicio y de gestión de la tecnología se integren
completamente con las herramientas y la tecnología en uso dentro de la
organización.
● Integrar procesos y herramientas: Asegurando la máxima explotación de las
herramientas en la gestión y soporte de la tecnología y de los procesos extremo
a extremo.

3.6.4 DISEÑO DE PROCESOS

● Un proceso es un conjunto estructurado de actividades diseñadas para cumplir


un objetivo determinado.
● Toma una o más entradas y las convierte en salidas definidas.
● Un proceso incluye todos los roles, responsabilidades, herramientas y controles
de gestión necesarios para entregar las salidas de forma eficaz.
● Un proceso también podría definir o revisar políticas, estándares, directrices,
actividades, procesos, procedimientos e instrucciones de trabajo si se
requirieran.

El control de procesos puede definirse como:


● La actividad de planificación y regulación de un proceso, con el objetivo de
garantizar el desarrollo de un proceso de forma eficiente, eficaz y coherente.
● Los procesos, una vez definidos, deberán documentarse y controlarse.
● Una vez bajo control, pueden repetirse y es posible gestionarlos.
● Se pueden definir grados de control sobre los procesos, y a continuación se
pueden integrar las métricas y medidas del proceso en el propio proceso para
controlar y mejorar el proceso.

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

3.6.4.1 Diseño de Roles – Modelo RACI

El modelo RACI proporciona un método compacto, conciso y fácil para hacer un


seguimiento de quién hace qué en cada proceso y permite una toma de decisiones
más rápida. RACI es un acrónimo de los cuatro roles principales de:
● Responsable La persona o personas encargadas de la ejecución correcta
(conseguir que se realice el trabajo). Debe haber al menos uno para cada
actividad o decisión.
● Autorizador La persona que tiene la propiedad de la calidad y resultado final.
Sólo una persona puede ser responsable de cada tarea.
● Consultado Las personas a las que se consulta y cuyas opiniones se buscan
(expertos). Proporcionan conocimientos e información.
● Informado: Personas a las que se mantiene al día sobre los progresos
pertinentes. Reciben información sobre la ejecución y calidad del proceso.

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.

Para construir un cuadro RACI se requieren los siguientes pasos:


● Identificar las actividades/procesos Identificar/definir los roles funcionales
● Dirigir reuniones y asignar los códigos RACI
● Identificar cualquier gap o solape - por ejemplo, si hubieran dos Rs o ninguna
R (vea el análisis siguiente).
● Distribuir el cuadro e incorporar retroalimentación
● Garantizar que se sigan las asignaciones.

ANÁLISIS DE ROLES FUNCIONALES


● Muchas As: ¿Las tareas se han segregado adecuadamente? ¿Alguien más debe
ser responsable de alguna de estas actividades? ¿Esto está causando un cuello
de botella en algunas áreas que retrasará la toma de decisiones?
● Muchas Rs: ¿Esto es demasiado para una función?
● No hay espacios vacíos: ¿Es necesario implicar a este rol en tantas tareas?
● Además, ¿el tipo o grado de participación se ajusta a las cualificaciones de este
rol?

ANÁLISIS DE ACTIVIDADES

● Más de una A: Sólo se puede justificar un rol


● Ninguna A: Al menos debe asignarse una A a cada actividad.
● Más de una R:Demasiados roles responsables con frecuencia implica que
ninguno asume la responsabilidad. La responsabilidad puede compartirse, pero
sólo si los roles están claros.
● Ninguna R: Al menos debe ser responsable una persona.
● Muchas C: ¿Existe un requisito a consultar con tantos roles? ¿Cuáles son los
beneficios y se puede justificar el tiempo extra?
● No hay Cs ni Is: ¿Los canales de comunicación están abiertos para permitir a
las personas y departamentos hablar unos con los otros y mantenerse
actualizados?

Problemas con el modelo RACI:

● Tener más de una persona como responsable último de un proceso equivale a


que nadie es en realidad responsable ultimo.
● Delegar la responsabilidad de ejecución o la responsabilidad última sin la
autorización requerida.
● Centrarse en relacionar los procesos y actividades con departamentos.
● Inadecuada división/combinación de funciones; metas y agendas en conflicto.
● Combinación de responsabilidades en procesos estrechamente relacionados.

3.6.5 DISEÑO DE MÉTRICAS Y SISTEMAS DE MEDICIÓN

“Si no puede medirlo entonces no puede gestionarlo”

● La gestión y control de los procesos de diseño requiere que estos se monitoricen y


midan.
● Solo se deben elegir medidas que fomenten el logro de los objetivos del negocio o
que faliciten el cambio organizacional deseado.
● Las medidas y métricas deben reflejar la calidad y éxito de los procesos de diseño
de la organización desde la perspectiva de negocio, cliente y usuario.
Existen 4 tipos de métricas que se pueden usar para medir la capacidad y rendimiento
de los procesos:
● Progreso: Hitos y entregables en la capacidad del proceso.
● Conformidad: Conformidad del proceso con requisitos de gobierno, requisitos
regulatorios y conformidad de las personas con respecto al uso del proceso.
● Eficacia: La precisión y exactitud del proceso y su capacidad para entregar el
'resultado correcto'.
● Eficiencia: La productividad de los procesos, su velocidad, rendimiento y
utilización de recursos.
● El método más eficaz de medida consiste en establecer un 'Árbol de Métricas' o un
'Árbol de KPIs'.
● Demasiadas organizaciones recopilan medidas en áreas individuales, pero fallan a
la hora de añadirlas en conjunto y obtener el máximo beneficio de las mismas, y
por lo tanto se ven perjudicadas porque:
○ Las medidas no se alinean con los objetivos y necesidades del negocio.
○ No hay una visibilidad general de la imagen de 'nivel superior'.
○ Existen brechas en áreas en las que no se registran las medidas.
○ Algunas áreas individuales se miden adecuadamente mientras que otras se
miden deficientemente o no se miden.
○ No hay consistencia en el método, presentación y cálculo de las medidas. Las
decisiones y acciones de mejora se basan en información incompleta o
imprecisa.

● Los Cuadros de Mando Integrales representan un sistema de gestión que


permite cada vez a un mayor número de organizaciones clarificar su visión y
estrategia. Proporcionan retroalimentación sobre los procesos de negocio
internos y los resultados externos para mejorar de forma continua el
rendimiento y los resultados estratégicos.
● Esto permite a todos dentro de la organización obtener una imagen del
rendimiento de la organización al nivel apropiado:
○Los gestores del negocio y los clientes pueden obtener un 'panel de control'
del negocio de 'alto nivel', alineado con las necesidades y procesos de
negocio.
○Los directores de TI sénior y los clientes se pueden centrar en el panel de
control de gestión de TI de alto nivel.
○Los Gestores del Servicio y clientes pueden centrarse en el rendimiento de
servicios particulares.
○Los Propietarios del proceso y gestores pueden ver el rendimiento de sus
procesos.
○Los especialistas técnicos pueden ver el rendimiento de componentes
individuales.
○El panel de control también presenta la oportunidad de analizar tendencias a
lo largo del tiempo en lugar de meros datos estáticos, por lo que se podrá
identificar la potencial degradación del rendimiento y rectificar este hecho en
una etapa anterior.

3.8 – LAS ACTIVIDADES DE DISEÑO POSTERIORES

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

Evaluación de soluciones alternativas


● Seleccionar un conjunto de proveedores y completar el proceso de oferta.
● Evaluación y revisión de respuestas de proveedores y selección de proveedores
elegidos y sus soluciones propuestas. Esto también podría implicar la ejecución de
pruebas o incluso creación de prototipos o actividades de pruebas de conceptos si
se vieran implicados nuevos conceptos o tecnologías importantes en el nuevo
servicio para garantizar que los nuevos componentes cumplan sus expectativas.
● La evaluación y el coste de diseños alternativos, incluyendo posiblemente la
identificación de proveedores potenciales y la evaluación de sus propuestas,
tecnologías, soluciones y contratos alternativos. Existe la necesidad de garantizar
que los costes cubran los costes puntuales y los costes continuos de operación y
propiedad, incluyendo el soporte y mantenimiento.

Aprovisionamiento de la solución elegida: Es posible que no se requiera ningún


elemento externo para la solución. Sin embargo, esto es inusual ya que es muy
probable que se vean implicados proveedores de software. Si se vieran implicados
proveedores externos en la solución elegida, las etapas consisten en:
● Completar todas las comprobaciones necesarias con respecto al proveedor
elegido.
● Firmar los términos y condiciones de cualquier nuevo contrato, garantizando que
se implementen todas las políticas corporativas
● La compra de la solución seleccionada.
Desarrollo de la solución del servicio: La etapa de desarrollo consiste en la
traducción del Diseño del Servicio en un plan para el desarrollo, reutilización o
renovación de los componentes requeridos para entregar el servicio y la posterior
implementación del servicio desarrollado. Cada plan o proyecto dentro del programa
será responsable de la entrega de uno o más componentes del servicio e incluirá:
● Las necesidades del negocio
● La estrategia a adoptar para el desarrollo y/o compra de la solución Los plazos de
tiempo implicados
● Los recursos requeridos, teniendo en cuenta instalaciones, infraestructura de TI y
las habilidades adecuadas del personal para garantizar que la entrega del servicio
satisfaga las necesidades del cliente
● El desarrollo del servicio y sus componentes, incluyendo la gestión y otros
mecanismos operativos, como por ejemplo, monitorización y generación de
informes
● Planes de prueba de servicios y componentes.
3.9 – RESTRICCIONES DEL DISEÑO

● Todas las actividades de diseño se encuentran sometidas a muchas


restricciones.
● Estas restricciones proceden del negocio y de la Estrategia del Servicio y
cubren muchas áreas diferentes.
● Muchas de estas influencias externas proceden de la necesidad de un buen
gobierno corporativo y de TI, y otras proceden de los requisitos de conformidad con
las regulaciones, legislación y estándares internacionales.
● Es fundamental que todos los diseñadores reconozcan esto y se aseguren que los
diseños y soluciones que propongan tengan todos los controles y capacidad
necesarios.

3.10 – ARQUITECTURA ORIENTADA A SERVICIOS

● El proceso de negocio y las soluciones deberán diseñarse y desarrollarse utilizando


un método de Arquitectura Orientada a Servicios (SOA).
● El método SOA está considerado como mejor práctica y muchas organizaciones lo
utilizan para mejorar su eficacia y eficiencia en la provisión de servicios de TI.
● SOA se define por OASIS (www.oasis-open.org) como:'Un estándar para
organizar y utilizar capacidades distribuidas que pudieran estar bajo el control de
diferentes dominios propietarios. Proporciona un medio uniforme para ofrecer,
descubrir, interactuar y usar capacidades para producir efectos deseados
consistentes con las condiciones previas y las expectativas medibles'.

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:

○ Defina y determine lo que es un servicio


○ Entienda y defina claramente ¡nterfaces y dependencias entre servicios Utilice
estándares para el desarrollo y definición de servicios
○ Use tecnología y conjuntos de herramientas comunes
○ Investigue y entienda el impacto de los cambios en los 'servicios compartidos'
Asegure que se haya planificado y llevado a cabo la formación asociada con
SOA para las personas de TI con el objetivo de establecer un lenguaje común y
mejorar la implementación y soporte de los servicios nuevos o modificados.

● Cuando la organización del proveedor de servicios de TI utiliza los fundamentos de


SOA, es crítico que se mantenga un Catálogo de Servicios preciso como parte de un
Porfolio de Servicios global y de un Sistema de Gestión de la Configuración (CMS).
● La adopción de este método puede reducir significativamente el tiempo dedicado en
la entrega de nuevas soluciones al negocio y para avanzar hacia una capacidad de
Gestión del Servicio de Negocio (BSM).
● El Catálogo de Servicios también mostrará la relación entre servicios y aplicaciones.
● Una única aplicación podría formar parte de más de un servicio, y un único servicio
podría utilizar más de una aplicación.

3.11 – MODELOS DE DISEÑO DEL SERVICIO

● El modelo seleccionado para el diseño de servicios de TI dependerá principalmente


del modelo seleccionado para la provisión de servicios de TI.
● Antes de adoptar un modelo de diseño para un nuevo servicio importante, deberá
realizarse una revisión de la capacidad y de las provisiones actuales con respecto a
todos los aspectos de la entrega de servicios de TI.
● Esta revisión deberá considerar todos los aspectos del nuevo servicio, incluyendo:
○ Directrices y requisitos de negocio.
○ Ámbito y capacidad del proveedor de servicio existente.
○ Demandas, objetivos y requisitos del nuevo servicio.
○ Ámbito y capacidad de proveedores externos.
○ Madurez de las organizaciones que están actualmente implicadas en sus
procesos.
○ Cultura de las organizaciones implicadas.
○ Infraestructura de TI, aplicaciones, datos, servicios y otros componentes
implicados.
○ Grado de gobierno corporativo y de TI y el nivel de propiedad y control
requerido.
○ Presupuestos y recursos disponibles.
○ Habilidades y capacidades del personal.

Opciones de modelos de entrega

Estrategia de entrega:Descripción

● Intemalización: Este método se basa en el uso de recursos organizativos


internos en el diseño, desarrollo, transición, mantenimiento, operación y/o
soporte de servicios nuevos, modificados o revisados o en operaciones del centro
de proceso de datos
● Externalización: Este método utiliza los recursos de una organización u
organizaciones externas en un acuerdo formal para proveer una parte bien
definida del diseño, desarrollo, mantenimiento, operaciones y/o soporte de un
servicio. Esto incluye el consumo de servicios de Proveedores de Servicios de
Aplicación (ASP), gue se describen más adelante
● Subcontratación: En muchas ocasiones se trata de una combinación de
internalización y externalización, empleando diversas organizaciones gue
colaboran para subcontratar elementos clave del ciclo de vida. Esto
generalmente implica el uso de varias organizaciones externas gue trabajan
juntas en el diseño, desarrollo, transición, mantenimiento, operación y/o soporte
de una parte del servicio
● Asociación y aprovisionamiento Múltiple: Acuerdos formales entre dos o
más organizaciones para trabajar juntas en el diseño, desarrollo, transición,
mantenimiento, operación y/o soporte de servicios de TI. El enfogue aguí tiende
a estar en asociaciones estratégicas gue se aprovechan de experiencia crítica u
oportunidades del mercado.
● Outsourcing de Procesos de Negocio (BPO): La tendencia creciente de
reubicación de todas las funciones de negocio con acuerdos formales entre
organizaciones, en los gue una organización proporciona y gestiona los procesos
o funciones de negocio de la otra organización en una ubicación de bajo coste.
Los ejemplos habituales son contabilidad de costes, nóminas y operaciones del
centro de llamadas.
● Provisión de Servicios de Aplicación: Implica acuerdos formales con la
organización de un Proveedor de Servicios de Aplicación (ASP) gue proveerá
servicios basados en eguipos compartidos a organizaciones del cliente a través
de una red. A las aplicaciones ofrecidas de esta forma también se las denomina
software/ aplicaciones bajo demanda. A través de las ASP, las complejidades y
costes del software compartido pueden reducirse y proveerse a organizaciones
gue, de lo contrario, no podrían justificar la inversión.
● Outsourcing del Proceso de Conocimiento (KPO): KPO, la forma más
novedosa de externalización, es un paso adelante de BPO en un aspecto. Las
organizaciones de KPO ofrecen experiencia de negocio y procesos basados en
dominios en lugar de únicamente experiencia de proceso, y reguieren
habilidades especializadas y analíticas avanzadas de la empresa de outsourcing.

Estrategia de la Ventajas Desventajas


entrega

Internalización Control directo Libertad de elección. Limitaciones de escala


Creación rápida de prototipos de Coste y tiempo de comercialización
servicios de vanguardia para servicios ya disponibles
Familiarizarse con políticas y Dependiente de recursos internos y
procesos de sus habilidades y competencias
Conocimiento especificado de la
compañía

Externalización Economías de escala Control menos directo


Compra de experiencia Barreras de salida
El soporte se centra en las Riesgo de solvencia de los
competencias centrales de la proveedores
compañía Habilidades y competencias de
Suporte para necesidades proveedores desconocidos
transitorias Integración de procesos de negocio
Dirección de pruebas/ensayos de más desafiantes
nuevos servicios Aumento de la necesidad de
gobierno y verificación

Subcontratación Tiempo de comercialización Complejidad del proyecto Propiedad


Aprovechamiento de la experiencia intelectual y protección del
Control copyright
Uso de proveedores especializado Conflicto cultural entre empresas

Asociación y Tiempo de comercialización Complejidad del proyecto Propiedad


aprovisionamient Expansión/entrada en el mercado intelectual y protección del
o múltiple Respuesta competitiva copyright
Aprovechamiento de la experiencia Conflicto cultural entre empresas
Confianza, alineamiento y beneficio
mutuo
Acuerdos de 'Riesgo y
reconocimiento'

Outsourcing de Punto único de responsabilidad Choque cultural entre empresas


Procesos de Acceso a habilidades de Pérdida de experiencia interna
Negocio (BPO) especialistas Pérdida de relación con el negocio
Riesgo transferido a la empresa
externa
Ubicación de bajo cost

Provisión de Acceso a soluciones caras y Choque cultural entre empresas


Servicios de complejas Ubicación de bajo coste Acceso sólo a instalaciones, no a
Aplicaciones Soporte y actualizaciones incluidos conocimiento
Opciones de segundad e ITSCM Modelos de imputación de costes
incluidas normalmente basados en el uso

Outsourcing del Acceso a habilidades, conocimiento Choque cultural entre empresas


Proceso de y experiencia de especialistas Pérdida de experiencia interna
Conocimiento Ubicación de bajo coste Pérdida de relación con el negocio
(KPO) Ahorros significativos de costes

ESTRATEGIA DEL SERVICIO

Entradas a diseño del servicio Salidas desde diseño del servicio

●Visión y misión ● Entradas para los casos de negocio y el


●Portfolio de servicios. portfolio de servicios.
●Políticas. ● Paquete de diseño del servicio.
●Estrategias y planes estratégicos. ● Modelos de servicio actualizados.
●Prioridades. ● Actualizaciones del portfolio de servicio,
●Actas constitutivas del servicio, incluyendo incluyendo el catálogo de servicios.
paquetes del servicio y detalles de la ● Estimaciones e informes financieros.
Utilidad y la Garantía. ● Información y conocimiento relativos al diseño
●Información financiera y presupuestos. en el SKMS.
Perfiles de usuario y patrones de actividad ● Diseños para los procesos y procedimientos de
del negocio documentados. la estrategia.
●Modelos de servicio

TRANSICIÓN DEL SERVICIO

Entradas a diseño del servicio Salidas desde diseño del servicio


●Actualizaciones del catálogo de servicios.
●Retroalimentación acerca de todos los ● Catálogo de servicios.
aspectos del diseño del servicio y del ● Paquete de diseño del servicio RFCs a
paquete de diseño del servicio. transición o despliegue de servicios nuevos o
●Comentarios y retroalimentación para los modificados.
planes de transición. ● Entradas para la evaluación de cambios y
●Respuestas a las solicitudes de cambio reuniones CAB.
(RFCs). ● Diseños para los procesos y procedimientos de
●Conocimiento e información en el SKMS transición del servicio.
(incluyendo el CMS). ● SLAs, OLAs y UCs.
●Errores de diseño identificados en la
transición para su rediseño.
●Informes de evaluación.

OPERACIÓN DEL SERVICIO

Entradas a diseño del servicio Salidas desde diseño del servicio

●Requerimientos operativos. ● Catálogo de servicios.


●Información real de rendimiento. ● Paquete de diseño del servicio Conocimiento
●RFCs para la resolución de contratiempos e información en el SKMS.
operativos. ● Funciones vitales del negocio.
●Histórico de registros de incidentes y ● Requerimientos de mantenimiento de HW/SW.
problemas. ● Diseños para los procesos y procedimientos de
operación del servicio.
● SLAs, OLAs y UCs
● Políticas de seguridad

MEJORA CONTINUA DEL SERVICIO

Entradas a diseño del servicio Salidas desde diseño del servicio

●Resultados del cliente y encuestas de ● Catálogo de servicios.


satisfacción del usuario. ● Paquete de diseño del servicio
●Entradas para los requerimientos de diseño. ● Conocimiento e información en el SKMS.
●Datos necesarios para métricas, KPIs y ● Logros cotejados con las métricas, KPIs y
CSFs. Informes del servicio. CSFs.
●Retroalimentación sobre el paquete de ● Diseño de servicios; medidas; procesos;
diseño del servicio. infraestructura; sistemas.
●RFCs para la implementación de mejoras. ● Diseño para procedimientos y proceso de
mejora en 7 pasos.
● Oportunidades de mejora introducidas en los
registros de CSI.

4 PROCESOS

4.1.- COORDINACIÓN DEL DISEÑO

4.1.1- INTRODUCCIÓN: Las actividades de la fase de diseño del servicio son


bastante detalladas y complejas. Es necesario que las acciones a realizar estén bien
coordinadas para que los proveedores de servicios sea capaces de desarrollar diseños
integrales que sustenten los resultados que el negocio requiere para conseguir sus
objetivos.

4.1.2- PROPÓSITO del proceso de coordinación del diseño es asegurar que se


cumplen los objetivos de la fase de diseño del servicio al proporcionar un punto único
de coordinación y control para todas las actividades de diseño de servicios y procesos.

4.1.3- OBJETIVOS

● Asegurar el diseño consistente de servicios, arquitecturas, tecnología, procesos,


información, sistemas de información de gestión de servicios y métricas para
satisfacer las necesidades de negocio actuales y futuras.
● Coordinar las actividades de diseño a través de proyectos, cambios, proveedores
y equipos de apoyo.
● Planear y coordinar los recursos y capacidades necesarias para diseñar servicios
nuevos o modificados.
● Producir paquetes de servicios de diseño de productos (SDP) sobre la base de los
estatutos de servicio y solicitudes de cambio.
● Producir paquetes de diseño del servicio (SDPs) y entregarlos a transición del
servicio según lo acordado.
● Gestionar los criterios de calidad, requisitos y puntos de entrega entre diseño del
servicio, estrategia del servicio y transición del servicio.
● Asegurarse de que todos los modelos de servicio y diseños de soluciones de
servicios se ajustan a la estratégica, arquitectura, gobierno y otros requerimientos
corporativos.
● Mejorar la eficacia y eficiencia de las actividades y procesos de diseño de
servicios.
● Asegurarse de que todas las partes adoptan un marco común de prácticas
reutilizables de diseño estándar, en forma de actividades, procesos y sistemas de
soporte.
● Monitorizar y mejorar el rendimiento de la etapa de diseño del ciclo de vida del
servicio.

4.1.4- ALCANCE del proceso de coordinación incluye toda la actividad de diseño,


especialmente las soluciones de servicio nuevas o modificadas que están siendo
diseñadas para su transición hacia (o desde, en el caso de una retirada de servicio) el
entorno operativo.

El proceso de Coordinación del diseño incluye:


● Asistencia y soporte a proyectos o cambios a través de las actividades de diseño
del servicio. Asegurar la producción de paquetes de diseño del servicio (SDPs) y
su entrega a transición del servicio.
● Coordinar, priorizar y programar el uso de todos los recursos de diseño del
servicio.
● Mantener las políticas, directrices, estándars, presupuestos, modelos, recursos y
capacidades para las actividades y procesos de diseño del servicio.
● Asegurar que se aborden todos los requisitos de utilidad y garantía en el diseño
de los servicio.

El proceso de Coordinación del diseño no incluye:


● La responsabilidad de las actividades o procesos fuera de la fase de diseño del
ciclo de vida del servicio
● La responsabilidad de diseñar las soluciones de servicios detallados a sí mismos o
la producción de las partes individuales del SDP . Estos son la responsabilidad de
los proyectos individuales o procesos de gestión de servicios.

4.1.5- VALOR PARA EL NEGOCIO

A través de la labor de coordinación del diseño, las organizaciones pueden:


● Asegúrese de que todos los servicios se ajustan a una constante arquitectura, que
permite la integración de datos y intercambio entre servicios y sistemas
● Alcanzar el valor de negocio de servicios en niveles aceptables de riesgo y coste.
● Minimizar el doble trabajo y los costes imprevistos.
● Lograr una mayor satisfacción de cliente y usuario.
● Mejorar la confianza en Ti y en los servicios de TI.
● Asegúrese de que todos los servicios se ajustan a una constante arquitectura, que
permite la integración de datos y intercambio entre servicios y sistemas
● Proporcionar un mejor enfoque en el valor del servicio, así como los resultados del
negocio y de los clientes
● Soporte de mayores volúmenes de cambios logrados con éxito.
● Lograr una mayor agilidad y mejor calidad en el diseño de soluciones de servicio.

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:

● Cumplimiento de estándares corporativos.


● Conformidad con la gobernanza y las normas regulatorias.
● Estándares para los componentes de un diseño integral para servicios tales como:
o Plantillas de documento.
o Planes de documentación.
o Planes de formación.
o Comunicaciones y planes de marketing.
o Planes de medición y métricas.
o Planes de despliegue.

● Criterios para resolver demandas contradictorias de recursos de diseño del


servicio
● Modelos de costo estándar.

4.1.7- PRINCIPIOS: Equilibrio > Priorizacion > Integracion

4.1.8 ACTIVIDADES de coordinación de diseño se dividen en dos categorías


4.1.9 DISPARADORES para el proceso de coordinación de diseño son los cambios en
los requisitos de negocio y servicios, y por lo tanto los principales factores
desencadenantes son las solicitudes de cambio (RFCS) y la creación de nuevos
programas y proyectos. Otro de los principales desencadenantes de la revisión de las
actividades de coordinación de diseño sería la revisión de la estrategia general de TI.

Solicitudes de cambio (RFCs).--> La creación de nuevos programas y proyectos.


-->La revisión de la estrategia global de TI (evaluación de las actividades de
coordinación del diseño).

4.1.10 ENTRADAS: Muchas fuentes de información son relevantes para el proceso de


coordinación del diseño, incluyendo:

● Actas constitutivas del servicio.


● Solicitudes de cambio, registros y cambios autorizados.
● Información del negocio (planes estratégicos y planes financieros,
requerimientos).
● BIA - información sobre el impacto, la prioridad y el riesgo asociado a cada
servicio.
● Portfolio de servicios - requerimientos del negocio para los servicios (opciones y
paquetes de servicios)
● La estrategia del negocio y de TI y las restricciones y limitación de recursos
asociados.
● Requerimientos de gobernanza.
● Políticas corporativas, legales y regulatorias.
● Los itinerarios de programa, proyecto y cambio.
● CMS.
● Retroalimentación desde todos los otros procesos.
● La arquitectura empresarial.
● Sistemas de gestión.
● Métodos de medición y métricas.
● Procesos

4.1.11 SALIDAS del proceso de coordinación del diseño son:

o Diseños de servicio y SDPs consistentes.


o Arquitectura empresarial revisada.
o Sistemas de gestión revisado.
o Métodos de medición y métricas revisadas.
o Procesos revisados.
o Actualizaciones del portfolio de servicios y de los registros de cambios.

4.1.12 INTERFACE

Gestión del portfolio de servicios proporciona el acta del servicio y toda la


documentación relacionada (requerimientos del negocio, requerimientos de
utilidad y garantía, riesgos y prioridades).

Gestión de cambios produce solicitudes de cambio y proporciona detalles de


los cambios autorizados que necesita diseño del servicio para que la actividad
de diseño pueda proceder. Gestión de cambios también da autorización en
puntos definidos para asegurar que se han llevado a cabo las acciones
necesarias y que se cumplen los criterios de calidad.
Gestión financiera proporciona detalles de la propuesta de valor y los
presupuestos para el nuevo servicio.

Gestión de Relaciones con el Negocio proporciona a coordinación del


diseño información relativa a las necesidades, prioridades y resultados
requeridos por el cliente. Y es la interfaz del cliente a un nivel estratégico.

Planificación y Soporte Planificación: Coordinación del diseño proporciona


el SDP para la fase de transición del servicio a través de este proceso.
Planificación y soporte de la transición realiza para la fase de transición lo que
coordinación del diseño realiza para la fase de diseño. La coordinación de estos
2 procesos asegura unos planes generales coherentes y una programación de
recursos para proyectos y cambios.

Gestión de la estrategia proporciona información de la estrategia del servicio


para que coordinación del diseño puede asegurar que las directrices y
documentación de diseño permanecen alineadas con la estrategia.

G. Entregas y Despliegues La planificación y el diseño para entregas y


despliegue se realiza en la fase de diseño del servicio y coordinación del diseño
asegura que esto esté integrado con otras actividades de diseño del servicio y
que forme parte del SDP.

G.Validación y Pruebas La planificación y el diseño de las pruebas se realizan


en la fase de diseño del servicio y coordinación del diseño asegura que esto
esté integrado con otras actividades de diseño del servicio y que forme parte
del SDP.

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.

G. Disponibilidad, Capacidad, Continuidad y Seguridad Cada uno de estos


procesos debe realizar actividades relativas al diseño de forma constante,
según las prácticas desarrolladas conjuntamente con la coordinación del
diseño.

Gestión de Proveedores debe colaborar con coordinación del diseño para


desarrollar prácticas consistentes y confiables para asegurar que las
contribuciones de los proveedores a las actividades de diseño están
correctamente gestionadas e integradas en los contratos.

4.1.13 FACTORES CRITICOS DE ÉXITO

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.

Los servicios • La puntuación de la satisfacción del cliente cumple o excede una


nuevos o calificación designada.
modificados • Aumento en el porcentaje de número de servicios que alcanzan los
satisfacen las objetivos de nivel del servicio
expectativas • Aumento de la satisfacción del personal de proyectos y cambios con
del cliente. el diseño del servicio.
• Disminución del número de conflictos por recursos de diseño del
servicio.
• Aumento en el porcentaje de nuevos servicios exitosos (resultados,
calidad, coste, puntualidad).
• Mayor eficacia y eficiencia en los procesos, actividades y sistemas
de soporte de diseño del servicio.
• Reducción del número y porcentaje de solicitudes de cambio de
emergencia elevadas a trámite por proyectos

4.1.14 DESAFIO

● Mantenimiento constante de diseños y SDPs de alta calidad a través de los


negocios, servicios e infraestructura
● Asegurar que se dedican recursos suficientes para las actividades de
coordinación del diseño.
● Asegurar que las funciones y responsabilidades se asignan correctamente.

4.1.15 RIESGOS asociados a la prestación del proceso de coordinación de diseño


son:

● Falta de habilidades y conocimientos disponibles.


● Información sobre los impactos y las prioridades del negocio insuficiente.
● Ausencia de participación de todas las partes interesadas (clientes, usuarios,
personal de TI).
● Falta de requisitos y resultados deseados claramente definidos.
● Comunicación ineficaz.
● Ausencia de dirección y estrategia.
● Falta de interacción y aportaciones de otras fases del ciclo de vida.
● Renuencia del negocio a participar y de los gestores de proyecto a comunicar e
involucrarse.
● Intentar ahorrar tiempo y dinero durante la fase de diseño.

4.2.- GESTIÓN DEL CATÁLOGO DE SERVICIOS

4.2.1- INTRODUCCIÓN: El Catálogo de servicios es uno de los elementos más


importantes de un enfoque integral de provisión de servicios. El proceso de gestión del
Catálogo de servicios proporciona los medios para asegurar que la organización
acumula todos los beneficios potenciales de un Catálogo de servicios de la manera
más eficiente posible.
4.2.2- PROPÓSITO de Gestión del Catálogo de Servicios es proporcionar una única
fuente de información consistente sobre todos los servicios acordados, y asegurar que
ésta esté completamente disponible para aquellos a los que se les haya autorizado el
acceso a la misma.

4.2.3- OBJETIVOS

● Garantizar que se genere y mantenga un Catálogo de Servicios que contenga


información detallada sobre todos los servicios operativos y sobre aquellos que se
estén preparando para que funcionen operativamente.
● Gestionar la información contenida dentro del Catálogo de Servicios, y garantizar
que sea preciso y refleje los detalles, estado, interfaces y dependencias actuales
de todos los servicios que están empezando a funcionar, o que se estén
preparando para tal efecto, en el entorno de producción.

4.2.4- ALCANCE del proceso de Gestión del Catálogo de Servicios es proporcionar y


mantener información precisa sobre todos los servicios que estén en transición o que
hayan pasado por la transición hasta el entorno de producción.

Las actividades de Gestión del Catálogo de Servicios deberán incluir:


o Definición del servicio
o Producción y mantenimiento de un Catálogo de Servicios preciso
o Interfaces, dependencias y consistencia entre el Catálogo de Servicios y el
Portfolio de Servicios
o Interfaces y dependencias entre todos los servicios y los servicios de soporte
dentro del Catálogo de Servicios y del CMS
o Interfaces y dependencias entre todos los servicios, y componentes de
soporte y Elementos de Configuración (Cls) dentro del Catálogo de Servicios y
del CMS.

4.2.5- VALOR PARA EL NEGOCIO

El Catálogo de Servicios proporciona una fuente central de información sobre los


servicios de TI entregados por la organización del proveedor de servicios. Esto
garantiza que todas las áreas del negocio puedan ver una imagen consistente y
precisa de los servicios de TI, sus detalles y estado. Contiene una visión dirigida al
cliente de los servicios de TI en uso, cómo se pretende que se utilicen, los procesos de
negocio que habilitan, y los niveles y calidad que el cliente puede esperar de cada
servicio.

Gestión del Catálogo de servicios ayuda a las organizaciones a:


● Promocionar y comunicar los servicios de TI.
● Vincular las actividades del proveedor de servicios y los activos del servicio a
los procesos y resultados del negocio.
● Mejorar el conocimiento y centrarse en el “valor de negocio” de los servicios de
TI

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 políticas concernientes al portfolio y a las


secciones constitutivas generales (servs en desarrollo, Catálogo, servicios
retirados).

● La política debe determinar:


○ Que servicios, datos y estatus que se registran para cada uno de los servicios.
○ Detalles de las responsabilidades para cada sección del portfolio global de
servicios.
○ El alcance de cada sección.
○ En qué momento se publica un servicio en el Catálogo de servicios.
○ En qué momento se quita un servicio del Catálogo de servicios.

● 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.7- ESTRUCTURA DEL CATÁLOGO DE SERVICIO:ITIL recomienda tener por lo


menos dos vistas diferentes del Catálogo:

● Vista cliente/negocio: Contiene información de todos los servicios de TI


orientados al cliente junto con las relaciones a las unidades del negocio y procesos
de negocio que dependen de los servicios de TI. Este es el Catálogo de servicios
que el negocio puede ver y usar.
● Vista técnica/soporte: Contiene detalles de todos los servicios de
apoyo/soporte, junto con las relaciones a los servicios orientados al cliente
soportados por estos servicios de apoyo, así como los componentes, CIs y
servicios necesarios para proveer el servicio final a los clientes.

Algunas organizaciones mantienen un catálogo de servicios que incluye sólo los


servicios de cara al cliente, mientras que otros mantienen información sólo sobre los
servicios de apoyo.
4.2.8 ACTIVIDADES: Las actividades clave dentro del proceso de gestión del
catálogo de servicios deben incluir:

● Acordar y documentar una definición de servicio y una descripción para cada


servicio con todas las partes pertinentes.
● Interfaz con la gestión de la cartera de servicios.
● La producción y el mantenimiento de un catálogo de servicios precisa y su
contenido.
● Interfaz con la gestión de relaciones comerciales y SLM para asegurar que la
información se alinea con los procesos de negocio.

4.2.9 DISPARADORES: del proceso de gestión del Catálogo de servicios son


● RFC y el proceso de gestión del cambio
● Cambios en los servicios existentes
● Servicios nuevos.
● Servicios que están siendo retirados.

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. Portfolio El proceso de gestión del portfolio de servicios define cierta información


crítica para los servicios, incluyendo opciones y paquetes de servicio y determina
cuáles servicios se van a constituir.

● 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. Configuración y activos del Servicio La información en el CMS tiene que estar


vinculada al Catálogo de servicios para proporcionar una visión global de las
interfaces y las dependencias entre servicios, clientes, procesos del negocio y activos
del servicio y CIs.

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

● G. Demanda Junto con gestión del portfolio de servicios, gestión de la demanda


determina de que forma se agruparán los servs como paquetes de servicios. G. del
Catálogo de servicios asegura que estos paquetes figuren en el Catálogo de servicios

4.2.13 FACTORES CRITICOS DE ÉXITO

CSF: KPIs:

Un Catálogo de • Aumento del número y % de servicios que se gestionan en del


servicio preciso. Catálogo de servicios.
• Porcentaje de reducción en el número de discrepancias entre la
información del Catálogo de servicios y el "mundo real".

Concienciación de • Aumento del % de la totalidad/plenitud del catálogo de servicio al


los usuarios del cliente.
negocio acerca de • Aumento del % del conocimiento del usuario sobre los servicios
los servicios que figuran en el Catálogo de servicios.
disponibles

Concienciación • Aumento del porcentaje de la totalidad/plenitud del catálogo de


del personal de TI servicios de apoyo.
acerca de la • Aumento de personal de CSU y de TI con acceso a información
tecnología que para soporte de servicios en activa (porcentaje de incidentes con la
sustenta los información apropiada pertinente al servicio).
servicios

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.- GESTIÓN DEL NIVEL DE SERVICIO


4.3.1- INTRODUCCIÓN

● Gestión del Nivel de Servicio (SLM) negocia, acuerda y documenta objetivos


apropiados del servicio de TI con representantes del negocio, y a continuación
monitoriza y genera informes sobre la capacidad del proveedor de servicio a la hora
de entregar el nivel de servicio acordado.
● El éxito de SLM depende en gran medida de la calidad del Porfolio de Servicios y
del Catálogo de Servicios y sus contenidos, ya que proporcionan la información
necesaria sobre los servicios a gestionar dentro del proceso de SLM.

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

● Definir, documentar, acordar, monitorizar, medir, informar y revisar el nivel de los


servicios de TI proporcionados
● Proporcionar y mejorar la relación y comunicación con el negocio y con los
clientes
● Garantizar que los objetivos específicos y medibles se desarrollen para todos los
servicios de TI Monitorizar y mejorar la satisfacción del cliente con la calidad del
servicio entregada
● Garantizar que TI y los clientes tengan una expectativa clara y sin ambigüedades
del nivel de servicio a entregar
● Asegurar que se implementen medidas proactivas para mejorar los niveles de
servicio entregados siempre que tengan un coste justificable

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.

Los procesos de SLM deben incluir:

●Desarrollo de relaciones con el negocio


●Negociación y acuerdo de requisitos y objetivos actuales, y la documentación y
gestión de SLAs para todos los servicios operativos y Negociación y acuerdo de
requisitos y objetivos actuales, y la documentación y gestión de SLRs para todos los
servicios nuevos o modificados propuestos
●Desarrollo y gestión de Acuerdos de Nivel Operativo (OLAs) apropiados para
asegurar que los objetivos se alineen con los objetivos de los SLA
●Revisión de todos los contratos y acuerdos de proveedores con Gestión de
Suministradores para asegurar que los objetivos se alineen con los objetivos de los
SLA
●Prevención proactiva de fallos del servicio, reducción de riesgos del servicio y mejora
de la calidad del servicio, junto con todos los demás procesos e Informe y gestión
de todos los servicios y revisión de todos los incumplimientos y debilidades de los
SLA
●Instigación y coordinación de un Programa de Mejora de Servicio (SIP) para la
gestión, planificación e implementación de todas las mejoras del serv y del proceso

4.3.5- VALOR PARA EL NEGOCIO

● Un canal de comunicación de nivel táctico con los representantes del negocio.


● Una interfaz constante con el negocio para todas las cuestiones relacionadas con el
nivel del servicio.
● Objetivos de nivel de servicio acordados entre TI y el negocio.
● Información de gestión para el seguimiento del logro de dichos objetivos.
● Retroalimentación acerca de la causa de los incumplimientos de los SLAs y las
medidas adoptadas para prevenir su recurrencia.

4.3.6- POLITICAS Las políticas definen:

● Contenido mínimo requerido de los SLAs, OLAs y UCs.


● Cuándo y cómo se evaluarán, renovarán, revisarán o renegociarán los acuerdos.
● Frecuencia y métodos de presentación de informes de nivel del servicio.

4.3.7- EL PROCESO DE GESTIÓN DEL NIVEL DEL SERVICIO


4.3.8 ACTIVIDADES Las actividades clave del proceso de SLM deberán incluir:

● Diseños de los marcos de trabajo del SLA


● Determinar, documentar y acordar requisitos para nuevos servicios y generar
SLRs Monitorización del rendimiento del servicio con respecto a los SLA
● Cotejar, medir y mejorar la satisfacción del cliente
● Revisar y volver a examinar los acuerdos de apoyo y el ámbito del servicio
● Generar informes del servido
● Realizar revisiones del servicio y estimular mejoras dentro del SIP general
● Revisar y volver a analizar SLAs, el ámbito del servicio y los acuerdos de apoyo
Desarrollo de contactos y relaciones
● Conformidades y no conformidades

4.3.9 DISPARADORES

● Cambios en el Portfolio de Servicios como por ejemplo requisitos de negocio


nuevos o modificados o servicios nuevos o modificados
● Acuerdos, SLRs, SLAs, OLAs o contratos nuevos o modificados
● Acciones y reuniones de revisión del servicio
● Roturas del servicio o amenazas de roturas
● Conformidades y no conformidades
● Actividades periódicas como por ejemplo revisión, generación de informes y
encuestas de satisfacción del cliente
● Cambios en la estrategia o política

4.3.10 ENTRADAS

● Información del negocio: desde la estrategia, planes, planes financieros e


información del negocio de la organización o sus requisitos actuales y futuros
● Análisis de Impacto del Negocio
● Requisitos de negocio: detalles de cualquier requisito de negocio acordado, nuevo
o modificado Las estrategias, políticas y restricciones de Estrategia del Servicio
● El Portfolio de Servicios y Catálogo de Servicios
● Información del cambio: desde el proceso Gestión de Cambios cios
● CMS: que contiene información sobre las relaciones entre los servicios de negocio,
los servicios de soporte y la tecnología
● Retroalimentación, conformidades y no conformidades de clientes y usuarios
● Otras entradas: incluyendo asesoramiento, información y entrada de cualquiera
de los demás procesos (p.ej., Gestión de Incidencias, Gestión de la Capacidad y
Gestión de la Disponibilidad), junto con los SLA, SLR y OLA existentes e informes
anteriores del servicio con respecto a la calidad del servicio entregado.

4.3.11 SALIDAS

● Informes del servicio


● Programa de Mejora de Servicio (SIP)
● El Plan de Calidad del Servicio Plantillas de documentación
● Acuerdos de Nivel de Servicio (SLA)
● Requisitos de Nivel de Servicio (SLRs)
● Acuerdos de Nivel Operativo (OLAs)
● Informes sobre OLAs y contratos de soporte
● Acciones y agendas de las reuniones de revisión del servicio
● Agendas de reuniones de revisión del ámbito del servicio y de revisión de los SLA
● Contratos revisados

4.3.12 INTERFACES

G. Relaciones Negocio BRM asegura que el proveedor de servicios entiende las


prioridades y las necesidades del cliente y que los clientes se involucran y están
representados en la labor de SLM.

G. Catálogo de servicios proporciona información precisa sobre servicios, interfaces


y dependencias para ayudar a determinar el marco de trabajo de los SLAs. Ésta
identifica a las partes interesadas que SLM debe implicar y ayuda a SLM a comunicar
los servicios provistos a los clientes.
Gestión de incidentes proporciona datos críticos para demostrar el rendimiento
comparado con los objetivos de los SLAs. SLM negocia objetivos de rendimiento de los
SLAs (por ejemplo, tiempos de restauración), los cuales son un factor crítico de éxito
(CSF) para gestión de incidentes.
Gestión de proveedores trabaja con SLM para definir, negociar, documentar y
acordar términos del servicio con los suministradores para sustentar los compromisos
de los SLAs. Ésta tb gestiona el rendimiento en comparación con dichos términos del
servicio para asegurar que se cumplen los objetivos asociados con los SLAs.

G. Disponibilidad, Capacidad, Continuidad y Seguridad Estos procesos ayudan a


SLM a:
● definir objetivos de nivel del servicio relacionados con su área de
responsabilidad
● validar que dichos objetivos sean realistas. Las operaciones del día a día de
cada proceso aseguran que logros concuerden con los objetivos.

Gestión financiera válida el coste previsto de entregar los niveles de servicio


requeridos por el cliente y asegura que los gastos reales se comparan con los costes
previstos como parte de la gestión de servicios global.

Coordinación del diseño es responsable de asegurar que las actividades de diseño


del servicio se completan con éxito. SLM desarrolla los SRLs y los objetivos del
servicio para cuyos logros se debe diseñar el servicio.

4.3.13 FACTORES CRITICOS DE ÉXITO

CSF: KPIs:

Gestión de • Amenazada la reducción del porcentaje de los objetivos de los


calidad global de SLAs.
servicios de TI, • Aumento en el porcentaje de la percepción y satisfacción del
tanto el número cliente sobre los logros del SLA. (evaluaciones del servicio y
como el nivel de respuestas a la encuesta de satisfacción del cliente).
los servicios. • Reducción en el porcentaje en incumplimientos de los SLAs
debido a OLAs internos.

Entrega de • Aumento en el porcentaje y número total de SLAs colocados.


servicios según • Aumento en el porcentaje de SLAs sobre servicios operativos.
acuerdo y dentro • Reducción en el porcentaje de costes de la provisión de servicios.
de costes • Reducción en el porcentaje del coste de la monitorización y
accesibles presentación de informes de los SLAs.

Gestionar la • Aumento del porcentaje de servicios cubiertos por SLAs, OLAs y


interfaz con el UCs.
negocio y los • Los procesos y procedimientos de SLM están documentados.
usuarios. • Reducción en el tiempo para responder e implementar solicitudes
de SLA.
• Aumento del porcentaje de revisiones de SLAs completadas a
tiempo.

4.3.14 DIFICULTADES: La mayor dificultad a la que se enfrenta SLM es la de


identificar representantes del negocio adecuadas con quienes negociar.
4.3.15 RIESGOS

● Una falta de entrada precisa, implicación y compromiso del negocio y clientes


● Las herramientas y recursos requeridos para acordar, documentar, monitorizar,
generar informes y revisar contratos y niveles de servicio
● El proceso se convierte en un proceso administrativo burocrático más que en un
proceso activo y proactivo de entrega de beneficios medibles al negocio
● Acceso y soporte de CMS y SKMS actualizados y apropiados
● Derivación del uso de los procesos de SLM
● Las mediciones del negocio y del cliente son demasiado difíciles de medir y
mejorar por lo que no se registran
● Se desarrollan relaciones y contactos inapropiados del negocio y del cliente
● Altas expectativas del cliente y baja percepción
● Se alcanza una comunicación deficiente e inapropiada con el negocio y los clientes

4.4.- GESTIÓN DE LA DISPONIBILIDAD


4.4.1- INTRODUCCIÓN: la Disponibilidad es una parte crítica de la garantía de un
servicio ya que sin la disponibilidad no se puede accederse a la utilidad de dicho
servicio. Si un servicio no entrega los niveles requeridos de disponibilidad, entonces el
negocio no recibirá el valor prometido.

4.4.2- PROPÓSITO de Gestión de la Disponibilidad es proporcionar un punto de


enfoque y gestión para todos los aspectos asociados con la disponibilidad, en relación
con los servicios y recursos, garantizando que se midan y logren los objetivos de
disponibilidad en todas las áreas.

4.4.3- OBJETIVOS:

● Generar y mantener un Plan de Disponibilidad actualizado y adecuado que refleje


las necesidades actuales y futuras del negocio
● Proporcionar asesoramiento y directrices para todas las demás áreas del negocio
y de TI con respecto a todos los aspectos relacionados con la disponibilidad
● Garantizar que los logros de disponibilidad del servicio cumplan o superen todos
sus objetivos
● Colaborar con el diagnóstico y resolución de incidencias y problemas asociados
con la disponibilidad
● Evaluar el impacto de todos los cambios en el Plan de Disponibilidad, y el
rendimiento y capacidad de todos los servicios y recursos
● Asegurar que se implementen medidas proactivas para mejorar la disponibilidad
de los servicios siempre que tengan un coste justificable.

4.4.4- ALCANCE

● Debe aplicarse a toda la tecnología y servicios operativos, particularmente a


aquellos recogidos por SLAs. También se puede aplicar a aquellos servicios de TI
que se consideren críticos para el negocio independientemente de si existen SLAs
formales.
● Debe aplicarse a todos los servicios nuevos de TI y a los servicios existentes si se
hubieran establecido Requisitos de Nivel de Servicio (SLRs) o Acuerdos de Nivel de
Servicio (SLAs)
● Debe aplicarse a todos los servicios de soporte y a los socios y suministradores
(internos o externos) que forman la organización de soporte de TI como un
impulsor para la creación de acuerdos formales
● Considera todos los aspectos de los servicios de TI, componentes y organizaciones
de soporte que podrían tener un impacto en la disponibilidad, incluyendo la.
formación, habilidades, eficacia del proceso, procedimientos y herramientas..

4.4.5- VALOR PARA EL NEGOCIO

● Asegura la disponibilidad de sistemas y servicios que estén a la par con la


evolución de las necesidades del negocio.
● Garantiza la disponibilidad y confiabilidad de los servicios de TI.
● Influye sobre la satisfacción del cliente.
● Promueve la lealtad del cliente.
● Influye en la reputación del negocio

4.4.6- POLITICAS

El proceso Gestión de la Disponibilidad está intentando continuamente garantizar que


todos los servicios operativos cumplan sus objetivos de disponibilidad acordados, y
que los servicios nuevos o modificados se diseñen adecuadamente para cumplir sus
objetivos, sin comprometer el rendimiento de los servicios existentes.

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

● Actividades reactivas de Gestión de la Disponibilidad implica la monitorización,


medida, análisis y gestión de todos los eventos, incidencias y problemas que
implican la indisponibilidad. Estas actividades se incluyen principalmente dentro
de los roles operativo.
● Actividades proactivas de Gestión de la Disponibilidad implican la planificación,
diseño y mejora proactiva de la disponibilidad. Estas actividades se incluyen
principalmente dentro de los roles de diseño y planificación.

Gestión de la Disponibilidad se completa en dos niveles interrelacionados:

● Disponibilidad del serv.: implica todos los aspectos de la disponibilidad e


indisponibilidad del serv. y el impacto de la disponibilidad del componente, o el
impacto potencial de la indisponibilidad del componente en la disponibilidad del
serv.
● Disponibilidad del componente: implica todos los aspectos de la disponibilidad e
indisponibilidad del componente

Gestión de la Disponibilidad se basa en la monitorización, medida, análisis e


información de los siguientes aspectos:

Disponibilidad: La capacidad de un servicio, componente o Cl para realizar su


función acordada cuando se requiere. Con frecuencia se mide y se transmite como
un porcentaje:

El tiempo de caída sólo debe incluirse en el cálculo anterior cuando se produce


dentro del Tiempo de Servicio Acordado (AST). Sin embargo, el tiempo de caída
total también debe registrarse y transmitirse.

Fiabilidad: Una medida de cuánto tiempo tarda un serv, componente o Cl en


realizar su función acordada sin interrupciones. La fiabilidad del serv puede
mejorarse aumentando la fiabilidad de los componentes individuales o aumentando
la capacidad de recuperación del serv con respecto a un fallo del componente
individual
Capacidad de Mantenimiento: Una medida de cómo de rápida y eficazmente se
puede restaurar un servicio, componente o Cl hasta alcanzar su funcionamiento
normal después de un fallo. Se mide y transmite como Tiempo Medio para
Restaurar el Servicio (MTRS) y debe calcularse utilizando la siguiente fórmula:

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

Capacidad del Servicio: La capacidad de un proveedor externo para cumplir los


términos de su contrato. En muchas ocasiones este contrato incluirá niveles
acordados de disponibilidad, fiabilidad y/o capacidad de mantenimiento para un
servicio de soporte o componente.

Ciclo expandido de la incidencia:

● Un principio de guía de Gestión de la Disponibilidad es reconocer que todavía es


posible lograr la satisfacción del cliente incluso cuando las cosas van mal. Un
método para ayudar a lograr esto requiere que Gestión de la Disponibilidad
garantice que se minimice la duración de cualquier incidencia para permitir que
las operaciones de servicio normales se reinicien lo más rápidamente posible. Un
objetivo de Gestión de la Disponibilidad es garantizar que se minimice la
duración e impacto de las incidencias que impactan en servicios de TI, para
permitir que las operaciones de negocio se reinicien lo más rápidamente posible.
● El análisis del 'ciclo de vida expandido de la incidencia' permite descomponer el
tiempo de caída total del servicio de TI para cualquier incidencia y hacerlo
corresponder con las etapas principales a través de las que progresan todas las
incidencias (el ciclo de vida). Gestión de la Disponibilidad debe trabajar
estrechamente con Gestión de Incidencias y Gestión de Problemas en el análisis
de todas las incidencias que provocan indisponibilidad.

4.4.8 ACTIVIDADES PROACTIVAS DE GESTIÓN DE LA DISPONIBILIDAD

La capacidad del proceso Gestión de la Disponibilidad es influida positivamente por


la variedad y la calidad de las técnicas y métodos proactivos utilizados por el
proceso. Las siguientes actividades representan las técnicas y actividades
proactivas del proceso Gestión de la Disponibilidad.

● Identificación de las Funciones Vitales del Negocio (VBFs)


● Diseño para la disponibilidad
● Componentes y producto base
● Gestión de sistemas
● Procesos de Gestión del Servicio
● Diseño de alta disponibilidad Soluciones especiales con redundancia total
● Revisar y volver a analizar SLAs, el ámbito del servicio y los acuerdos de apoyo
● Desarrollo de contactos y relaciones
● Conformidades y no conformidades
4.4.9 DISPARADORES

● Necesidades nuevas o modificados del negocio o servicios


● Objetivos nuevos o modificados dentro de acuerdos, como SLRs, SLAs, OLAs o
contratos
● Incumplimientos del servicio o componente, eventos de disponibilidad y alertas,
incluyendo eventos de umbrales, informes de excepciones
● Actividades periódicas como revisar, repasar o informar
● Revisión de previsiones, informes y planes de Gestión de la Disponibilidad
● Revisión de planes y estrategias de negocio y de TI
● Revisión de diseños y estrategias y reconocimiento o notificación de un cambio del
riesgo o impacto de un proceso de negocio o VBF, un servicio de TI o componente

4.4.10 ENTRADAS

● Información del negocio, del servicio, del impacto en el negocio y financiera


● Análisis Anteriores del Riesgo
● Información del cambio y de la entrega
● Gestión de la Configuración
● Objetivos del servicio
● Información del componente y de la tecnología
● Rendimiento anterior
● Información sobre indisponibilidad y fallo

4.4.11 SALIDAS

● El Sistema de Información de Gestión de la Disponibilidad (AMIS).


● El Plan de Disponibilidad para la mejora proactiva de los servicios de TI y la
tecnología.
● Criterios de disponibilidad y diseño de la recuperación y objetivos de servicio
propuestos para servicios nuevos o modificados
● Informes de logros de la disponibilidad, fiabilidad y mantenimiento del servicio
frente a los objetivos, incluyendo la entrada para todos los informes del servicio
● Informes de logros de la disponibilidad, fiabilidad y mantenimiento del
componente frente a los objetivos.
● Revisiones e informes revisados del análisis de riesgo y un Registro de Riesgos
actualizado.
● Requisitos de monitorización, gestión y elaboración de informes para los servicios
y componentes de TI con el objetivo de asegurar que las desviaciones de la
disponibilidad, fiabilidad y mantenimiento sean detectadas, corregidas,
registradas y transmitidas.
● Una planificación de pruebas de Gestión de la Disponibilidad para probar todos los
mecanismos de disponibilidad y capacidad de recuperación
● Las planificaciones de mantenimiento planificado y preventivo
● La Parada de Servicio Planificada (PSO) junto con Gestión de Cambios y de la
Entrega
● Detalles técnicas y medidas de disponibilidad proactivas que se desplegarán para
proporcionar capacidad de recuperación adicional a fin de evitar o minimizar el
impacto de los fallos del componente sobre la disponibilidad del servicio de TI
● Acciones de mejora para su inclusión dentro del SIP.
4.4.12 INTERFACES

G. Nivel de Servicio SLM se apoya gestión de la disponibilidad para establecer y


validar los objetivos de disponibilidad e investigar y resolver los incumplimientos
relacionados con servicios y componentes.

G. Incidentes y G. Problemas Gestión de la disponibilidad asiste en la resolución,


justificación y corrección de incidentes y problemas relacionados con la disponibilidad.

G. Capacidad proporciona la capacidad para sustentar la Resistencia/redundancia y la


disponibilidad del servicio en general.

G. Cambio Gestión de la disponibilidad debe evaluar los cambios propuestos para


cuestiones relacionadas con la disponibilidad y cualquier impacto potencial sobre los
niveles de disponibilidad del servicio.

G. Continuidad Gestión de la disponibilidad colabora con ITSCM en la evaluación de


riesgos, impacto en el negocio y la provisión de mecanismos de resistencia y
tolerancia a fallos y recuperación. La disponibilidad se centra en la operación normal
del negocio y ITSCM se centra en la interrupción extraordinaria del servicio

G. Seguridad define las medidas y políticas de seguridad para su inclusión en los


aspectos de disponibilidad y recuperación en el diseño del servicio.

G. Accesos Gestión de la disponibilidad proporciona los métodos para la concesión /


denegación de acceso a los servicios según se requiera.

4.4.13 FACTORES CRITICOS DE ÉXITO

CSF: KPIs:

Gestionar la • Reducción en el porcentaje de NO disponibilidad de servicios y


disponibilidad componentes.
y confiabilidad • Aumento en el porcentaje de fiabilidad de componentes y
del servicio de servicios.
TI. • Mejora en el porcentaje de disponibilidad general de extremo a
extremo del servicio.
• Mejora del MTBF – tiempo medio entre fallos
• Mejora del MTBSI – tiempo medio entre interrupciones del
servicio
• Reducción del MTRS – tiempo medio de recuperación del
servicio

Satisfacer las • Reducción en el porcentaje de NO disponibilidad de los


necesidades servicios.
de acceso a los • Reducción en el porcentaje de los costes de tiempo extra del
servicios de TI negocio debido a la NO disponibilidad de TI.
del negocio. • Reducción en el porcentaje de fallos en momentos críticos (se
planifican los momentos álgidos de negocios y las necesidades de
disponibilidad prioritarias).
• Mejora en el porcentaje de satisfacción de usuarios y negocio
Disponibilidad • Reducción en el coste de NO disponibilidad.
infraestructura • Mejora en el porcentaje de los costes de entrega del servicio.
y aplicaciones • Completar de forma oportuna un análisis coste-beneficio regular
de TI (SLAs) a establecido para la infraestructura CFIA.
un coste • Reducción en el porcentaje de fallos en el rendimiento de
óptimo. terceros en cuanto a MTRS/MTBF en comparación a los objetivos
establecidos en el contrato.
• Reducción del tiempo necesario para completar (o actualizar)
una evaluación del riesgo.
• Reducción del tiempo para examinar la redundancia/resitencia
del sistema.

4.4.14 DIFICULTADES

● Gestión de la Disponibilidad se enfrenta a muchos desafíos, pero probablemente


el principal de ellos es cumplir realmente las expectativas de los clientes, del
negocio y de la gestión sénior.
● Estas expectativas se basan en que los servicios estarán siempre disponibles, no
sólo durante sus horas de servicio acordadas, sino que todos los servicios estarán
disponibles 24 horas al día, 365 días al año.
● Otro desafío al que se enfrenta Gestión de la Disponibilidad es la integración de
todos los datos de disponibilidad dentro de un conjunto integrado de información
(AMIS) que se pueda analizar de forma consistente para proporcionar detalles
sobre el uso de todos los servicios y componentes.
● Otro desafío adicional al que se enfrenta Gestión de la Disponibilidad es convencer
al negocio y a la gestión senior de la inversión que se requiere para las medidas
de disponibilidad proactivas.

4.4.15 RIESGO

● Ausencia de compromiso del negocio con el proceso de gestión de la


disponibilidad.
● Falta de compromiso de la dirección. No exista información sobre estrategias y
planes futuros.
● Falta de recursos / presupuesto para el proceso de gestión de la disponibilidad.
● Procesos de presentación de informes que requieren mucho trabajo.
● El enfoque está en la tecnología y no en los servicios de TI y las necesidades del
negocio.
● AMIS no se comparte y no es coherente con otros procesos (ITSCM, ISM y gestión
de la capacidad).

4.5.- GESTIÓN DE LA CAPACIDAD

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.2- PROPÓSITO de Gestión de la Capacidad es proporcionar un punto de enfoque


y gestión para todos los aspectos asociados con la capacidad y el rendimiento en
relación con los servicios y recursos.

4.5.3- OBJETIVO

● Generar y mantener un Plan de Capacidad actualizado y adecuado que refleje


las necesidades actuales y futuras del negocio
● Proporcionar asesoramiento y directrices para todas las demás áreas del
negocio y de TI con respecto a todos los aspectos relacionados con la
capacidad y el rendimiento Garantizar que los logros de rendimiento del
servicio cumplan o superen todos sus objetivos de rendimiento acordados
● Colaborar con el diagnóstico y resolución de incidencias y problemas asociados
con el rendimiento y la capacidad
● Evaluar el impacto de todos los cambios en el Plan de Capacidad, y el
rendimiento y capacidad de todos los servicios y recursos
● Asegurar que se implementen medidas proactivas para mejorar el rendimiento
de los servicios siempre que tengan un coste justificable

4.5.4- ALCANCE

Gestión de la Capacidad necesita entender todos los entornos de negocio y


TI, incluyendo:
o La operación actual del negocio y sus requisitos a través de los modelos de
actividad del negocio
o Los futuros planes y requisitos de negocio a través del Porfolio de Servicios
o Los objetivos del servicio y la Operación Actual del Servicio del TI a través de
SLAs y Procedimientos de Operación Estándar
o Todas las áreas de la tecnología de TI y su capacidad y rendimiento,
incluyendo infraestructura, datos, entorno y aplicaciones.

El proceso de Gestión de la Capacidad deberá incluir:


o Monitorizar modelos de actividad del negocio y planes de nivel de servicio a
través del desempeño, utilización y rendimiento de servicios de TI y de la
infraestructura de soporte, entorno, datos y componentes de las aplicaciones, y
generación de informes regulares y ad hoc sobre la capacidad y rendimiento de
componentes y servicios
o Emprender actividades de ajuste para lograr el uso más eficiente de recursos
de TI existentes
o Entender las demandas acordadas actuales y futuras del cliente con respecto
a los recursos de TI, y elaborar previsiones para futuros requisitos
o Influir en Gestión de la Demanda, quizás en colaboración con Gestión
Financiera
o Elaborar un Plan de Capacidad que permita al proveedor de servicio
continuar dando servicios de la calidad definida en los SLAs y que cubra una
franja de tiempo suficiente de planificación para cumplir los futuros niveles de
servicios requeridos como se define en el Porfolio de Servicios y SLRs
o Colaborar con la identificación y resolución de cualquier incidencia y
problema asociados con el rendimiento del servicio o componente
o La mejora proactiva del rendimiento del servicio o componente siempre que
sea justificable en costes y cumpla las necesidades del negocio.

4.5.5- VALOR PARA EL NEGOCIO

Gestión de la Capacidad es responsable de garantizar que los recursos de TI se


planifiquen y programen para proporcionar un nivel consistente de servicio que se
corresponda con las necesidades actuales y futuras del negocio, como se acordó y
documentó en SLAs y OLAs.

Gestión de la capacidad beneficia al negocio al:


● Reducir incidentes y problemas relacionados con el rendimiento y la capacidad
Asegurar que el rendimiento y la capacidad requerida se proporcionan de forma
rentable.
● Contribuir a la productividad de los usuarios mediante el logro los niveles del
servicio relacionados con la capacidad y el rendimiento.
● Dar soporte al diseño y transición de los servicios a través de las actividades de
gestión proactiva de la capacidad.
● Mejorar la planificación de presupuestos mediante el desarrollo y mantenimiento de
un plan de capacidad.

4.5.6- POLITICAS

● Equilibrio de los costes con respecto a los recursos necesarios: la


necesidad de garantizar que la capacidad de procesamiento que se compre sea
justificable en costes, en términos de necesidad del negocio, y la necesidad de
hacer el uso más eficiente de esos recursos.
● Equilibrio del suministro con respecto a la demanda: la necesidad de
garantizar que el suministro disponible de la potencia de procesamiento de TI se
corresponda con las demandas hechas por el negocio, ahora y en el futuro. Tb
podría ser necesario gestionar o influir en la demanda para un recurso particular.

4.5.7- CONCEPTOS BÁSICOS

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.7- CONCEPTOS BÁSICOS – SUBPROCESOS

Gestión de la Capacidad del Negocio

● Traduce las necesidades y planes de negocio en requisitos para el servicio e


infraestructura de TI, garantizando que los futuros requisitos de negocio para los
servicios de TI se cuantifiquen, diseñen, planifiquen e implementen de forma
oportuna
● Estos futuros requisitos provienen de la Estrategia del Servicio y del Porfolio de
Servicios que detallan nuevos procesos y requisitos del servicio, cambios,
mejoras, y también el crecimiento de los servicios existentes.

Gestión de la Capacidad del Servicio

● El enfoque de este subproceso es la gestión, control y predicción de la capacidad y


del rendimiento extremo a extremo de las cargas de trabajo y del uso de los
servicios de TI operativos activos.
● Garantiza que se monitorice y mida el rendimiento de todos los servicios, como se
detalla en los objetivos del servicio de SLAs y SLRs, y que se registren, analicen y
se transmitan los datos recopilados.
● Siempre que sea posible deberán utilizarse umbrales automatizados para
gestionar todos los servicios operativos, para garantizar que se identifiquen
rápidamente las situaciones donde los objetivos del servicio se incumplen o haya
amenaza de ello, y para identificar las acciones rentables para reducir o evitar su
posible impacto.
Gestión de la Capacidad del Componente
● El enfoque de este subproceso es la gestión, control y predicción del rendimiento,
utilización y capacidad de componentes tecnológicos de TI individuales.
● Esto garantiza que se monitorice y se mida el rendimiento de todos los
componentes de la infraestructura de TI, y que se registren, analicen y se
transmitan los datos recopilados.
● Siempre que sea posible, deberán implementarse umbrales automatizados para
gestionar todos los componentes, para garantizar que se identifiquen rápidamente
las situaciones en las que el uso de los componentes incumpla los objetivos del
servicio o en las que haya amenaza de ello, y para identificar las acciones
rentables para reducir o evitar su posible impacto.

4.5.8 ACTIVIDADES

También podría gustarte