5904608
Diseño de Servicio
Description
No tags specified
Slide Set by Viviana Valenzuela, updated more than 1 year ago
More
Less
|
|
Created by Viviana Valenzuela
almost 8 years ago
|
|
Resource summary
Slide 1
Diseño de Servicio
Slide 2
Objetivos
•Definir
y explicar los
conceptos claves del Diseño del Servicio.•Comprender
y contar con los
principios y modelos claves de esta fase.•Explicar
cómo esta fase
contribuye al Ciclo de Vida del Servicio.•Explicar los objetivos de alto nivel, el
alcance, los conceptos básicos, las actividades, los indicadores claves de
rendimiento (KPI – Key Performance Indicators) o métricas, los
roles y los desafíos de los procesos del Diseño del Servicio.
Slide 3
Objetivos
Metas, objetivos y valor de negocio
•Entregar soluciones más efectivas y eficientes
que generen servicios alineados a las necesidades.
•Diseñar
servicios que puedan
ser desarrollados y mejorados fácilmente y
dentro de los costos y la escala de tiempo apropiados.
•Identificar
y manejar los riesgos
para eliminarlos o mitigarlos antes de que los servicios salgan a producción.
•Diseñar la infraestructura de TI (ambientes, aplicaciones y datos) de
forma segura y resistente con los recursos y capacidades requeridas para
encontrar las necesidades actuales y futuras del negocio.
•Diseñar
métodos y métricas
que permitan evaluar la efectividad y eficiencia del diseño de procesos y sus entregables.
Valor al Negocio: Con un buen diseño de servicios, es
posible brindar servicios de mayor calidad y a un costo más efectivo asegurando
que los requerimientos del negocio sean alcanzados.
Slide 4
Procesos
Relación
con otras fase del ciclo de vida
•La fase de SD comienza con el relevamiento
y el entendimiento de las necesidades del negocio y finaliza con una solución
diseñada para alcanzar los requisitos especificados.
•La
solución desarrollada
conjuntamente con las especificaciones del servicio (SDP: Service Design Package) es derivada a la
fase de transición (ST) para que evalúe, construya, testee y desarrolle el
nuevo servicio, o modifique uno existente.
•Una vez completadas las actividades de la
fase de transición (ST), el control se transfiere a la fase de operación (SO).
Slide 5
Principios y Modelo
Las
4 ´P´
•Muchos
diseños, planes y proyectos fracasan en el camino por falta de gestión y
preparación. La implementación de ITIL Service Management como práctica tiene que ver con la
preparación y planificación el uso eficiente y efectivo de las 4 P: personas,
procesos, productos y socios (partners).
Slide 6
Procesos
Aspectos
del diseño
Las
5 grandes aspectos del Diseño del Servicio son:
•Soluciones de servicio para servicios nuevos o
modificados.
•Sistemas y herramientas de gestión de
información.
•Arquitecturas de tecnología y gestión.
•Procesos.
•Métricas y métodos de medición.
El paquete
de diseño del servicio (SDP) es el gran entregable de esta fase que debe cubrir
los aspectos mencionados.
Slide 7
Procesos
•Gestión del Nivel de Servicio
•Gestión del Catálogo de Servicios
•Gestión de la Disponibilidad
•Gestión
de la Seguridad de Información
•Gestión de Proveedores
•Gestión de Capacidad
•Gestión
de Continuidad de los Servicios de TI
•Coordinación del diseño
Slide 8
Gestión Niveles de Servicio
Objetivos
•Definir,
documentar, acordar, monitorear, medir, reportar y revisar los niveles de los
servicios de TI.
•Mantener
y mejorar la relación y comunicación con el negocio y los clientes.
•Asegurar
el desarrollo de metas especificas y medibles para todos los servicios de TI.
•Asegurar
que tanto TI como los clientes tengan expectativas claras de los niveles de
servicio a ser brindados.
•Asegurar
que se tomen acciones proactivas para la mejora de los niveles de servicio mientras se
justifique a nivel costo / beneficio.
Slide 9
Gestión Niveles de Servicio
Gestión de Nivel de Servicio
debe ser un punto de contacto y comunicación para los clientes y
gerentes de negocio de una organización. El proceso debe incluir: •Negociación
y acuerdo de futuros
requerimientos y metas y la documentación y gestión de los requerimientos de
nivel de servicio (SLR: Service Level Requirements) para todos los
servicios propuestos o modificados. •Negociación
y acuerdo de los
requerimientos, la documentación y la gestión de los acuerdos de nivel de
servicio (SLA: Service Level Agreements) para todos los
servicios. •Desarrollo
y gestión de todos
los acuerdos de nivel operativo (OLA: Operational Level Agreements) para asegurar que
las metas estén alineadas con los SLA.
•Actividades
proactivas para la
prevención de todas las fallas de servicio, reducción de riesgo y mejora de la calidad
de servicio.
•Gestión
de reportes y
revisión de todas las debilidades encontradas en los servicios. •Gestión
y coordinación de un
Programa de Mejora de Servicios para la gestión,
planificación e implementación de todas las mejoras en los servicios y
procesos.
Alcance
Gestión de Nivel de Servicio
debe ser un punto de contacto y comunicación para
•los clientes y
gerentes de negocio de una organización.
El proceso debe incluir:
•Negociación
y acuerdo de futuros
requerimientos y metas y la documentación y gestión de los requerimientos de
nivel de servicio (SLR: Service Level Requirements) para todos los
servicios propuestos o modificados.
•Negociación
y acuerdo de los
requerimientos, la documentación y la gestión de los acuerdos de nivel de
servicio (SLA: Service Level Agreements) para todos los
servicios.
•Desarrollo
y gestión de todos
los acuerdos de nivel operativo (OLA: Operational Level Agreements) para asegurar que
las metas estén alineadas con los SLA.
•Actividades
proactivas para la
prevención de todas las fallas de servicio, reducción de riesgo y mejora de la calidad
de servicio.
•Gestión
de reportes y
revisión de todas las debilidades encontradas en los servicios.
•Gestión
y coordinación de un
Programa de Mejora de Servicios (SIP: Service Improvement Program) para la gestión,
planificación e implementación de todas las mejoras en los servicios y
procesos.
Slide 10
Gestión Niveles de Servicio
Acuerdos
de nivel de servicio (SLA)
Los acuerdos
de nivel de servicio (Service Level Agreement) constituyen la base para la gestión
de las relaciones entre un proveedor de servicios y el cliente.
• Un SLA es un acuerdo
escrito entre un proveedor de servicios de TI y el cliente de TI, que define
los objetivos claves y las responsabilidades de ambas partes.
• El énfasis debe ser
puesto en el acuerdo, los SLA no deben ser utilizados como instrumento de
coerción entre las partes. Se debería generar un espíritu de equipo entre el
proveedor y el cliente para llegar a un acuerdo mutuamente beneficioso.
• Gestión de Nivel de Servicio
debe diseñar una estructura de SLA que incluya todos los servicios y clientes
de la manera más conveniente para el negocio.
Acuerdos
de nivel de servicio (SLA)
Los acuerdos
de nivel de servicio (Service Level Agreement) constituyen la base para la gestión
de las relaciones entre un proveedor de servicios y el cliente.
• Un SLA es un acuerdo
escrito entre un proveedor de servicios de TI y el cliente de TI, que define
los objetivos claves y las responsabilidades de ambas partes.
• El énfasis debe ser
puesto en el acuerdo, los SLA no deben ser utilizados como instrumento de
coerción entre las partes. Se debería generar un espíritu de equipo entre el
proveedor y el cliente para llegar a un acuerdo mutuamente beneficioso.
• Gestión de Nivel de Servicio
debe diseñar una estructura de SLA que incluya todos los servicios y clientes
de la manera más conveniente para el negocio.
Slide 11
Gestión Niveles de Servicio
Estructuras
del SLA
Usando el catálogo de servicio como
herramienta de ayuda, SLM debe diseñar la estructura de SLA más apropiada para
asegurar que todos los servicios y clientes estén cubiertos según las
necesidades de la organización.
•SLA basados en el servicioEl SLA cubre un servicio para todos
los clientes que lo utilizan. Esto puede resultar dificultoso cuando los
clientes tienen distintos requerimientos para un mismo servicio. •SLA basados en el cliente
Es un acuerdo con un cliente
específico y cubre todos los servicios que se le brindan.
•SLA “multi-nivel”
Es un acuerdo que mantiene los SLAs
en un tamaño manejable y reduce la necesidad de frecuentes actualizaciones. Se
puede crear un SLA multinivel en donde, por ejemplo se cubran los niveles:
•Nivel corporativo (cuestiones comunes
relacionadas con el servicio)
•Nivel de cliente (cuestiones que
tienen que ver con un cliente específico)
•Nivel de servicio (cuestiones
específicas de un servicio)
Estructuras
del SLA
Usando el catálogo de servicio como
herramienta de ayuda, SLM debe diseñar la estructura de SLA más apropiada para
asegurar que todos los servicios y clientes estén cubiertos según las
necesidades de la organización.
•SLA basados en el servicio
El SLA cubre un servicio para todos
los clientes que lo utilizan. Esto puede resultar dificultoso cuando los
clientes tienen distintos requerimientos para un mismo servicio.
•SLA basados en el cliente
Es un acuerdo con un cliente
específico y cubre todos los servicios que se le brindan.
•SLA “multi-nivel”
Es un acuerdo que mantiene los SLAs
en un tamaño manejable y reduce la necesidad de frecuentes actualizaciones. Se
puede crear un SLA multinivel en donde, por ejemplo se cubran los niveles:
•Nivel corporativo (cuestiones comunes
relacionadas con el servicio)
•Nivel de cliente (cuestiones que
tienen que ver con un cliente específico)
•Nivel de servicio (cuestiones
específicas de un servicio)
Slide 12
Gestión Niveles de Servicio
Acuerdo
de nivel operativo (OLA)
Un acuerdo de nivel
operativo (Operational Level Agreement) es un acuerdo
entre un proveedor de servicios de TI y otra parte de la misma organización que
asiste en la provisión de servicios.
•
Un OLA
debe tener objetivos que soporten los objetivos comprometidos en los SLA; los
objetivos no serán alcanzados si falla la actividad que los soporta.
•
Ejemplo:
un acuerdo con el área de mantenimiento responsable de el funcionamiento de los
acondicionadores de aire del centro de cómputos.
Slide 13
Gestión de Catálogo de Servicios
Objetivos
El
objetivo de la Gestión del Catálogo de Servicios es gestionar la información
que contiene el catálogo de servicio y asegurar que sea correcta y que refleja
en forma adecuada los detalles, estado, interfaces y dependencias de todos los
servicios de TI operativos o en preparación para el paso a producción.
Incluye
los servicios vigentes y los que están listos para comenzar.
Slide 14
Gestión de la Disponibilidad
Objetivos
•Producir
y
mantener un plan de disponibilidad que refleje las necesidades actuales y
futuras del negocio.
•Servir
de
guía y proveer consejos a todas las áreas del negocio y de TI en todas las
cuestiones relacionadas con la disponibilidad de los servicios.
•Asegurar
que
todas las metas de disponibilidad del negocio sean alcanzadas
o superadas.
•Asistir con el diagnóstico y
resolución de los incidentes y problemas relacionados a la disponibilidad de servicios.
•Evaluar
el
impacto de todos los cambios en el plan de disponibilidad y en la
performance o capacidad de todos los recursos y servicios.
•Asegurar que se realicen
actividades proactivas para mejorar la disponibilidad, siempre y cuando sea
favorable la relación costo / beneficio.
Slide 15
Gestión de la Disponibilidad
Elementos
y Niveles de Disponibilidad
El proceso de gestión de la disponibilidad
tiene dos elementos clave:
•Actividades reactivas
•Actividades proactivas
La disponibilidad puede evaluarse en
dos niveles que se encuentran interconectados entre sí:
•Disponibilidad del Servicio
•Disponibilidad de
los componentes
Slide 16
Gestión de la Disponibilidad
Aspectos
de la disponibilidad
Disponibilidad (Availability):
La
capacidad que tiene un servicio, componente o elemento de configuración para
desarrollar su actividad cuando sea requerido.
Por
lo general se mide y reporta como un porcentaje:
Slide 17
Gestión de la Disponibilidad
Aspectos
de la disponibilidad
Confiabilidad
(Reliability):
Medida
de tiempo en que un servicio, componente o elemento de configuración, puede
desarrollar su actividad sin interrupción.
•MTBSI
(Mean
Time Between Service Incidents) =
Tiempo Medio entre Incidentes del Servicio
Confiabilidad (MTBSI en horas) = Tiempo disponible en horas / Cantidad de incidentes del servicio
•MTBF
(Mean Time Between Failures) = Tiempo Medio entre Fallos
Confiabilidad (MTBSF en horas) = (Tiempo disponible en horas - Total de Downtime en horas ) / Cantidad de incidentes del servicio
Slide 18
Gestión de la Disponibilidad
Aspectos
de la disponibilidad
Capacidad de proveer Mantenimiento (Maintainability):
Medida
de cuán rápido y efectivo puede ser restaurado un servicio, componente o
elemento de configuración, luego de haberse producido una falla.
•MTRS
(Mean Time to Restore Service) =Tiempo Medio de Restauración del
servicio
Mantenidilidad (MTRS
en horas) = Total de Downtime en horas / Cantidad de caidas del servicio
MTRS
(Mean Time to Restore Service) =Tiempo Medio de Restauración del Servicio.
Capacidad
de proveer Servicio (Serviceability):
La
capacidad de un tercero para cumplir con los objetivos estipulados en el
contrato. Normalmente estos contratos incluirán los niveles acordados de
disponibilidad, confiabilidad o capacidad de mantenimiento.
Aspectos
de la disponibilidad
Capacidad de proveer Mantenimiento (Maintainability):
Medida
de cuán rápido y efectivo puede ser restaurado un servicio, componente o
elemento de configuración, luego de haberse producido una falla.
•MTRS
(Mean Time to Restore Service) =Tiempo Medio de Restauración del
servicio
asdas
Slide 19
Gestión de la Disponibilidad
Funcion
vital del negocio
VBF
–
Vital Business Function se usa para reflejar parte de un
proceso de negocio que es crítico para el éxito del negocio.
Un
servicio de TI puede soportar un número de funciones de negocio que son menos
críticas. Por ejemplo, una VBF de un cajero automático (ATM) podría ser la
entrega de dinero. Sin embargo, para obtener un estado de cuenta de un ATM
podría no ser considerado vital.
La
distinción es importante y debería influenciar el diseño de la disponibilidad y
los costos
asociados.
Cuanto
más vital sea la función del negocio, mayor el nivel de resistencia y
disponibilidad que debe incorporarse en el diseño requerido para soportar los
servicios de TI.
Slide 20
Gestión de la Seguridad de la Información TI
Objetivos
En
la
mayoría de las organizaciones se alcanzan los objetivos de la gestión de
seguridad de la información cuando:
•La
información
está disponible y es utilizable cuando se requiera y los sistemas que la
proveen pueden resistir apropiadamente los ataques (disponibilidad).
•La
información
es accesible sólo para las personas autorizadas (confidencialidad).
•La
información
es completa, precisa y protegida ante modificaciones no
autorizadas (integridad).
•Las
transacciones
de negocio y la información intercambiada entre empresas o con partners
es confiable (autenticidad).
Slide 21
Gestión de la Seguridad de la Información TI
Framework
de seguridad
El
proceso
y el framework
de Gestión de la Seguridad de la Información, generalmente consiste en:
•Una Política de
Seguridad de la Información y políticas específicas de seguridad de cada
aspecto de la estrategia, los controles y las regulaciones.
•Un Sistema de Gestión
de la Seguridad de la Información (ISMS). (incluye las 4P).
•Una
estrategia
de seguridad, alineada con el negocio.
•Una
estructura
organizacional para gestionar la seguridad.
•Controles
de
seguridad alineados a las políticas.
•La
gestión
de los riesgos de seguridad.
•Un
proceso
de monitoreo para asegurar el cumplimiento y dar feedback.
•Comunicación
de
la estrategia y de las políticas de seguridad.
•Entrenamiento
y
concientización.
Slide 22
Gestión de la Seguridad de la Información TI
Política
de gestión de seguridad de la información
•Las
actividades de la gestión de seguridad de la información deben estar enfocadas
y guiadas por una política apropiada que cubra todas las áreas de seguridad y
que apunte a soportar las necesidades del negocio. Deben incluir:
•Usos y abusos de políticas de activos de TI.
•Políticas de control de contraseñas. •Políticas de Internet.
•Políticas de antivirus.
•
Tiene que
estar disponible para todos los clientes, usuarios y personal de TI.
•
Tiene que
ser revisada siempre que sea necesario, al menos una vez al año.
Política
de gestión de seguridad de la información
•Las
actividades de la gestión de seguridad de la información deben estar enfocadas
y guiadas por una política apropiada que cubra todas las áreas de seguridad y
que apunte a soportar las necesidades del negocio. Deben incluir:
•Usos y abusos de políticas de activos de TI.
•Políticas de control de contraseñas.
•Políticas de Internet.
•Políticas de antivirus.
•
Tiene que
estar disponible para todos los clientes, usuarios y personal de TI.
•
Tiene que
ser revisada siempre que sea necesario, al menos una vez al año.
Slide 23
Gestión de Proveedores
Proveedor
Un
proveedor es un tercero responsable de proveer bienes o servicios
requeridos para
proveer servicios de TI.
•
•Algunos
proveedores
proveen servicios y productos que individualmente agregan un valor casi
insignificante al negocio, pero que en conjunto pueden contribuir directamente
y en forma importante al cumplimiento de la estrategia de negocio. •Cuanto
mayor
sea la contribución del proveedor en la estrategia de negocio, mayor debe ser
el esfuerzo que se debe invertir en la Gestión de Proveedores y en la
participación de estos en el desarrollo de la estrategia de negocio.
Slide 24
Gestión de Proveedores
Un
proveedor de servicios (Service Provider)
es una organización que provee servicios para uno o más clientes internos o
externos.
Existen
tres tipos de proveedores de servicios:
•
Tipo I
– Proveedor de servicios interno (Internal)
Son
funciones de negocio incorporadas en las unidades de negocio a las que les dan
servicio.
•
Tipo II
– Proveedor de servicios compartido (Shared)
Son
funciones de negocio que le dan servicio a varias unidades de negocio, a las
cuales consideran clientes.
•
Tipo III
– Proveedor de servicios externo (External)
Son
organizaciones externas al negocio que le dan servicio a las unidades de
negocio.
Slide 25
Gestión de Proveedores
Contratos
Las
actividades asociadas con la identificación de las necesidades de negocio y la
subsecuente evaluación de nuevos proveedores y contratos, son parte del proceso
de diseño del servicio.
Un
contrato suele tener un cuerpo principal en el que se puede encontrar cláusulas
comerciales y legales.
Los
contratos pueden también contener:
•Requerimientos de seguridad.
•Requerimientos de continuidad del negocio.•Requerimientos de estándares técnicos.•Planes
de migración.
•Acuerdos de rescisión.
Slide 26
Gestión de Proveedores
Gestión de Proveedores
Contrato
de soporte (UC)
Un
contrato
de soporte (Underpinning Contract)
es un acuerdo entre un proveedor de servicios de TI y un proveedor externo que
asiste en la provisión de servicios.
•Un UC debe tener objetivos que soportan los objetivos
comprometidos en los SLA; los objetivos no serán alcanzados si falla la
actividad que los soporta.
Slide 27
Gestión de Proveedores
Base
de datos de proveedores y contratos (SCD)
La
base de datos de proveedores y contratos (Supplier
and Contract Database)
es utilizada para gestionar los contratos de proveedores a lo largo de todo el
ciclo de vida.
La
SCD contiene atributos claves de todos los contratos con proveedores y debería
formar parte del SKMS.
Slide 28
Gestión de Capacidad
Objetivos
•Producir y mantener un plan
de capacidad, apropiado y actualizado, que refleje los requerimientos actuales
y futuros del negocio.
•Proveer
consejos
y servir de guía a todas las áreas del negocio y de TI en los temas
relacionados con capacidad y performance.
•Asegurar
que
la performance de los servicios cumpla o exceda los requerimientos acordados.
•Asistir
en
la investigación y diagnóstico de los incidentes y problemas relacionados con
temas de performance y capacidad.
•Evaluar
el
impacto de todos los cambios en relación a temas de capacidad y disponibilidad
(asistir a las reuniones del CAB en caso de ser necesario).
•Asegurar que se realicen
tareas proactivas para la mejora de la capacidad y performance de los servicios
de TI.
Slide 29
Gestión de Capacidad
Gestión de Capacidad
Plan
de capacidad
•El
plan
de capacidad debe producirse y mantenerse en periodos de tiempo pactados. Debe
publicarse anualmente y debe estar en línea con el negocio y el presupuesto.
Slide 30
Gestión de Capacidad
Sub-procesos
•Gestión de capacidad del negocio: Este
sub-proceso
traduce las necesidades y planes del negocio en requerimientos actuales y
futuros para el servicio y la infraestructura de TI. •Gestión de capacidad del servicio: El
foco
de este subproceso es la gestión, control y predicción de la performance y
capacidad del uso de los servicios actualmente en producción. •Gestión de capacidad de los componentes: El
foco
de este sub-proceso es la gestión, control y predicción de la performance,
utilización y capacidad de los componentes tecnológicos individuales de TI.
Sub-procesos
•Gestión de capacidad del negocio: Este
sub-proceso
traduce las necesidades y planes del negocio en requerimientos actuales y
futuros para el servicio y la infraestructura de TI. •Gestión de capacidad del servicio: El
foco
de este subproceso es la gestión, control y predicción de la performance y
capacidad del uso de los servicios actualmente en producción. •Gestión de capacidad de los componentes: El
foco
de este sub-proceso es la gestión, control y predicción de la performance,
utilización y capacidad de los componentes tecnológicos individuales de TI.
Slide 31
Gestión de la Continuidad de Servicios TI
Objetivos
•Mantener
un
conjunto de planes de continuidad de TI y de planes de recuperación que
soporten el plan de continuidad de negocio.
•Realizar en forma periódica
un análisis de impacto en el negocio (BIA: Business Impact Analysis).
•Realizar
ejercicios
de análisis y gestión del riesgo.
•Aconsejar
a
todas las áreas de TI sobre temas relacionados con la continuidad y la
recuperación de los servicios.
•Asegurar que se pongan en
producción todos los mecanismos necesarios para alcanzar los objetivos de
continuidad y recuperación requeridos por el negocio.
•Asegurar
que
se realicen actividades proactivas para mejorar la disponibilidad de los
servicios y componentes.
•Negociar
y
acordar con proveedores externos, todo lo necesario para llevar adelante la
recuperación de los servicios.
Slide 32
Gestión de la Continuidad de Servicios TI
Continuidad
del negocio
•Gestión
de
Continuidad del Negocio (BCM: Business Continuity Management):
Es el
proceso de negocio responsable por la gestión de los riesgos que pueden afectar
seriamente al negocio. El proceso de BCM incluye la reducción de riesgos a un
nivel mínimo aceptable y la planificación para la recuperación del proceso de
negocio en caso de una interrupción inesperada. El BCM establece los objetivos,
alcance y requerimientos del proceso de continuidad de servicios de TI.
•Plan
de
Continuidad del Negocio (BCP: Business Continuity Plan):
Es
un
plan que incluye todos los pasos requeridos para recuperar los procesos de
negocio en los casos en los que ocurrió una interrupción. Los Planes
de Continuidad de TI (IT Service Continuity Plans)
forman parte
del BCP.
Slide 33
Gestión de la Continuidad de Servicios TI
Gestión de la Continuidad de Servicios TI
Requerimientos
del negocio
•Análisis
de
Impacto del Negocio (BIA: Business Impact Analysis): Es la actividad de BCM que identifica
las funciones vitales del negocio y sus dependencias. Estas dependencias
pueden incluir, por ejemplo: proveedores, personas, otros procesos
de negocio y servicios de TI. El BIA establece los requerimientos de
recuperación de los servicios de TI.
•Análisis
de
Riesgos (RA: Risk Analysis): Es sumamente importante la
identificación y el análisis de las posibles amenazas a la continuidad del
negocio y la probabilidad de ocurrencia de las mismas. Este análisis
implica también el tomar las medidas necesarias para aquellas amenazas en las
que la relación costo beneficio lo justifique.
Requerimientos
del negocio
•Análisis
de
Impacto del Negocio (BIA: Business Impact Analysis): Es la actividad de BCM que identifica
las funciones vitales del negocio y sus dependencias. Estas dependencias
pueden incluir, por ejemplo: proveedores, personas, otros procesos
de negocio y servicios de TI. El BIA establece los requerimientos de
recuperación de los servicios de TI.
•Análisis
de
Riesgos (RA: Risk Analysis): Es sumamente importante la
identificación y el análisis de las posibles amenazas a la continuidad del
negocio y la probabilidad de ocurrencia de las mismas. Este análisis
implica también el tomar las medidas necesarias para aquellas amenazas en las
que la relación costo beneficio lo justifique.
Slide 34
Coordinación del Diseño
Objetivos•Dado
que las actividades de la fase de diseño de servicios es detallada y compleja,
se necesitan acciones bien coordinadas para que un proveedor de servicios puede
crear diseños apropiados que soporten el logro de los resultados de negocio
requeridos.
•El objetivo de este
proceso es asegurar que se cumplen las metas de la fase. Esto se logra mediante
la definición de un punto único de coordinación y control de todas las
actividades de diseño de servicios.
Además
debe:
•Asegurar
el
diseño consistente de todos los elementos (sistemas de información de gestión
de servicios, tecnología, información, métricas, servicios) para cumplir con
los requerimientos del negocio actuales y futuros.
•Coordinar
las
actividades de diseño en todos los proyectos, cambios, proveedores y equipos de
soporte. Gestionar cronogramas, recursos y conflictos en donde se requiera.
•Planificar
y
coordinar los recursos y capacidades para diseñar servicios nuevos o
modificados.
Slide 35
Coordinación del Diseño
Coordinación del Diseño
Objetivos
•Producir
service design packages (SDPs)
en base al roadmap
de servicios y a requerimientos de cambios y que se entregan a la transición de
servicios según lo acordado.
•Gestionar
los
criterios de calidad, requerimientos y puntos de entrega entre la etapa de
diseño de servicios, la estrategia de servicios y la transición de servicios.
•Asegurar
que
todos los modelos de servicio y el diseño de soluciones de servicio cumplen con
los requerimientos de estrategia, arquitectura y gobierno requeridos.
•Monitorear
y
mejorar la eficiencia de las actividades y procesos de diseño de servicios y de
la fase en general.
•Además
de la definición de nuevos servicios, los cambios que requieren más atención de
la coordinación del diseño son los cambios mayores. Sin embargo cualquier
cambio que la organización crea que se puede beneficiar de la coordinación del
diseño se puede incluir.
Slide 36
Actividades
•Asistir
y
soportar cualquier proyecto o cambio a través de los procesos de diseño.
•Mantener
políticas,
guías, estándares, presupuestos, modelos, recursos y capacidades para las
actividades y procesos de diseño.
•Coordinar,
priorizar y programar todos los recursos de diseño de servicios para satisfacer
demandas conflictivas de todos los proyectos.
•Planificar
requerimientos
a futuro.
•Revisar,
medir y mejorar el desempeño de las actividades de diseño.
•Asegurar
que
se cubren todos los requerimientos, particularmente los de utilidad y garantía.
•Asegurar
que
se generan SDPs y
se entregan a la transición del servicio.
•No
incluye la responsabilidad por actividades o procesos fuera de la fase, ni la
producción de las partes individuales de los SDPs que serán responsabilidad de otros
proyectos o procesos de gestión de servicios.
Coordinación del Diseño
Want to create your own Slides for free with GoConqr? Learn more.