Gobernabilidad de ti

Fundamentos de ITIL V.3 O&M

1 | P á g i n a


2 | P á g i n a


3 | P á g i n a


4 | P á g i n a


5 | P á g i n a


6 | P á g i n a


7 | P á g i n a


8 | P á g i n a

Buena Práctica

Buena: Comprobada como adecuada para su uso Práctica: Una forma de trabajar, actividades o

procesos

Las organizaciones operan en ambientes dinámicos con la necesidad de aprender, adaptar y mantener

una ventaja competitiva con respecto a las alternativas que sus clientes pueden tener. Para este fin, las

organizaciones realizan una evaluación comparativa de sí mismas contra los colegas y buscan cerrar las

brechas en las capacidades (capabilities) a través de la adopción de las buenas prácticas que se utilizan

en toda la industria.

La adopción de una buena práctica necesita considerar las Fuentes, Habilitadores, Escenarios e

Impulsores involucrados.

Fuentes: Genera opciones de buenas prácticas entre las cuales se puede elegir, tales como:

• Marcos público

• Normas

• Conocimientos propietarios de organizaciones y personas

Los marcos públicos y las normas son atractivos cuando se comparan con los conocimientos

propietarios:

Los conocimientos propietarios están personalizados para el contexto local y las necesidades específicas del negocio y están integrados profundamente en las organizaciones. Dichos conocimientos con frecuencia se encuentran a través de conocimientos tácitos, que son inextricables y están deficientemente documentados, son difíciles de adoptar, reproducir o transferir

Los marcos y las normas disponibles a nivel público tales como ITIL, COBIT, CMMI, ISO/IEC 20000 e ISO/IEC 27001 se validan para un grupo diverso de organizaciones, disciplinas y situaciones en lugar de la experiencia limitada de una sola organización. Cuentan con el respaldo de un grupo diverso de socios, proveedores y competidores con conocimientos ampliamente distribuidos entre una gran comunidad de profesionales

Ignorar los marcos y las normas públicos puede poner a una organización innecesariamente en desventaja. Las organizaciones deben cultivar sus propios conocimientos propietarios sobre un cuerpo de conocimientos que se basan en los marcos y las normas públicos. El esquema de ITIL ofrece un cuerpo de conocimientos como una fuente no propietaria de buenas prácticas que las organizaciones pueden utilizar para establecer y mejorar las capacidades (capabilities) de la Administración de Servicios.

• Habilitadores: Agregan la capacidad de llevar a cabo buenas prácticas seleccionadas.

(Empleados, Clientes, Proveedores, Asesores, Tecnología)

• Escenarios (un filtro): La(s) situación(es) que causa(n) que una organización se concentre en

prácticas específicas. (Competencia, Conformidad, Compromiso)

• Impulsores (un filtro): Eventos o actividades que crean la necesidad de adoptar una práctica.

(Sustitutos. Reguladores, Clientes)


9 | P á g i n a


10 | P á g i n a

Definición de Servicio

“Un servicio es un medio para entregar valor a los clientes a/facilitar los resultados que desean obtener

los clientes sin la propiedad de costos y riesgos específicos.”

Los resultados del cliente se logran mediante la realización de tareas pero están limitados por la

presencia de ciertas restricciones.

En el amplio sentido de la palabra, los servicios facilitan los resultados al mejorar el rendimiento del

cliente y reducir la fuerza de las restricciones. En tanto que algunos servicios mejoran el rendimiento de

las tareas, otros realizan la tarea por sí mismos.

El resultado es un efecto positivo: un incremento en la posibilidad de obtener resultados deseados.

Es imprescindible comprender que los servicios no son análogos a los sistemas o componentes de

tecnología. El cliente percibe los servicios como una entidad completa de principio a fin compuesta de

tecnología, personas, procesos, proveedores, fondos instalaciones, conformidad con la regulación,

etcétera.

Ejemplo

Una unidad de negocio requiere un terabyte de almacenamiento seguro para brindar soporte a su

sistema de compras en línea. Desde una perspectiva estratégica, desea que el personal, equipo,

instalaciones e infraestructura para un terabyte de almacenamiento permanezcan dentro de su rango

de control. Sin embargo, no desea responsabilizarse de todos los costos y riesgos asociados, reales o

nominales, verdaderos o percibidos.

Por fortuna, existe un grupo dentro del negocio con los conocimientos especializados y la experiencia en

sistemas de almacenamiento a gran escala, y la confianza para controlar los costos y riesgos asociados.

La unidad de negocio acepta pagar por el servicio de almacenamiento que suministra el grupo de

conformidad con términos y condiciones específicos.

La unidad de negocio sigue siendo la responsable del cumplimiento de las órdenes de compra en línea.

No es responsable de la operación ni del mantenimiento de las configuraciones tolerantes a fallas de los

dispositivos de almacenamiento, fuentes de energía dedicadas y redundantes, personal capacitado, o la

seguridad del perímetro del edificio, gastos administrativos, seguro, cumplimiento de las reglas de

seguridad, medidas de contingencia, ni del problema de optimización de la capacidad inactiva para los

incrementos inesperados en la demanda.

La complejidad del diseño, las incertidumbres operacionales y las compensaciones técnicas asociadas

con el mantenimiento de sistemas confiables de almacenamiento de alto rendimiento conducen a

costos y riesgos que la unidad de negocio simplemente no está dispuesta a asumir. El proveedor de

servicios asume la propiedad y asigna esos costos y riesgos a cada unidad de almacenamiento que utiliza

el negocio y cualquier otro cliente del servicio de almacenamiento.


11 | P á g i n a

Servicio vs. Tecnología

Las ofertas de servicio deben proporcionar un menú de opciones significativas con precios asequibles

entre las cuales se pueda elegir. El cliente no se interesa por los ingredientes individuales de cada

artículo del menú. La redacción de los acuerdos sobre el servicio proporciona la visión consolidada que

necesitan para alinearla con los procesos del negocio.

Los clientes no se interesan por la complejidad estructural, los detalles técnicos ni las operaciones de nivel bajo

Prefieren interfaces sencillas y seguras en lugar de configuraciones complejas de recursos tales como aplicaciones, datos, instalaciones e infraestructura

Las ofertas de servicio se deben montar de una forma que sean útiles y utilizables para el negocio y que oculten lo que no interesa a los clientes


12 | P á g i n a

Las expectativas influyen sobre las percepciones de valor. Los clientes tienen valores de referencia sobre

los cuales basan sus percepciones del valor agregado de un servicio. El valor de referencia puede estar

definido con imprecisión o basarse en hechos ineludibles.

El valor se define estrictamente en el contexto de los resultados del negocio. La concentración en los

resultados del negocio por encima de cualquier otra cosa es un avance fundamental en la perspectiva de

muchos proveedores de servicios. Representa un cambio de énfasis del uso eficiente de los recursos a la

realización efectiva de los resultados. La necesidad de efectividad para ayudar a que los clientes lleven a

cabo los resultados es lo que impulsa la eficiencia en las operaciones. Los clientes no compran servicios;

compran el cumplimiento de necesidades particulares. Esta distinción explica la desconexión frecuente

entre las organizaciones de TI y los negocios a los que brindan sus servicios. Lo que el cliente valora

muchas veces es diferente a lo que la organización de TI cree que proporciona. Tenga cuidado con esta

brecha.


13 | P á g i n a

¿Cuáles son los resultados que importan? ¿Cómo se identifican y qué lugar ocupan en términos de las

percepciones y preferencias del cliente? La efectividad al responder dichas preguntas requiere un modo

de pensar orientado hacia el marketing, que es muy diferente a los modos de pensar orientados hacia la

ingeniería y las operaciones. En lugar de concentrarse hacia dentro en la producción de los servicios,

existe la necesidad de mirar de afuera hacia dentro, desde la perspectiva del cliente.

Los proveedores de servicios se diferencian a sí mismos de los vendedores de equipo Únicamente a

través del valor agregado incluso cuando se utiliza el equipo de esos mismos vendedores como activos.

La diferencia puede surgir a partir del aprovisionamiento de servicios de comunicación en lugar de

enrutadores y paneles de control. Se puede obtener otra diferenciación a partir del aprovisionamiento

de servicios de colaboración en lugar de simplemente operar servicios de correo electrónico/correo de

voz. El enfoque cambia de los atributos al cumplimiento de los resultados.


14 | P á g i n a


15 | P á g i n a

Utilidad y Garantía

El valor de un servicio para los clientes se relaciona con la definición de un servicio, en parte, como un

medio para entregar valor a los clientes al facilitar los resultados que desean los clientes. Dichos

resultados se hacen posibles de dos maneras:

(1) La realización de las tareas

(2) Una reducción en la fuerza de las restricciones

El servicio realiza tareas que logran un resultado de negocio, ya sea de manera directa (al realizar

actividades), o de manera indirecta (al limitar o reducir las restricciones). En cualquier caso, el resultado

es un incremento en la posibilidad de obtener los resultados deseados.

El valor de un servicio para los clientes se basa en dos elementos primarios: Utilidad y garantía.

Valor (Cliente) = (Servicio) Utilidad Y (Servicio) Garantía

La utilidad se deriva de los atributos de un servicio que tienen un efecto positivo en la realización de las

actividades, los objetos y las tareas asociados con los resultados deseados. La eliminación o relajación de

las restricciones sobre la realización también se percibe como un efecto positivo.

La garantía se deriva del efecto positivo del servicio que se está poniendo a disposición cuando es

necesario y con la capacidad o magnitud suficientes. También se refiere a la capacidad de dependencia

del servicio en términos de continuidad y seguridad. La utilidad se trata de !J recibe el cliente. La

garantía se trata de cómo se entrega el servicio al cliente.

Tanto la Utilidad como la Garantía son necesarias para el Valor. Los clientes no se pueden beneficiar de

algo que es adecuado para el propósito (Utilidad) pero que no es adecuado para el uso (Garantía) y

viceversa. Cuando la Utilidad de un servicio no está respaldada por la Garantía, los clientes se preocupan

acerca de las pérdidas posibles debido a una calidad de servicio deficiente más que por las ganancias

posibles de recibir la Utilidad prometida. Para disipar tales inquietudes e influir en las percepciones del

cliente acerca de las pérdidas y ganancias posibles, es importante que el valor de un servicio se describa

plenamente en términos de Utilidad y Garantía.

Resulta útil separar la lógica de la Utilidad de la lógica de la Garantía para fines de diseño, desarrollo y

mejora. El Efecto de la Utilidad de un servicio se explica como el incremento en las ganancias posibles

que proviene del rendimiento de los activos del cliente que generan un incremento en la probabilidad

de la consecución de los resultados. La Garantía de los Servicios se explica como la reducción en las

pérdidas posibles para el cliente a partir de la variación en el rendimiento.

De lo que se deduce que los resultados del cliente, más que la recopilación de los requisitos, se

convierten en la preocupación final de los Gestores de Productos. Los requisitos son necesarios, pero no

son suficientes, para asegurar el Valor de los servicios que se entregan a los clientes. También es

necesario definir los resultados esperados. Los requisitos se generan para la coordinación y el control

internos únicamente después de que se comprenden plenamente los resultados del cliente.


16 | P á g i n a

Los recursos y las capacidades (capabilities) son tipos complementarios de los activos que utilizan las

organizaciones para crear valor a través de bienes y servicios. Es relativamente fácil adquirir recursos en

comparación con las capacidades (capabilities).

Los recursos son aportaciones directas para producción. La administración, organización, personas y

conocimientos se utilizan para transformar los recursos.

Las capacidades (capabiities) se desarrollan con el tiempo y representan la habilidad de una

organización para controlar, coordinar e implementar los recursos para producir valor. Por lo general

son impulsadas por la experiencia, comprenden extensos conocimientos, se basan en información y

están integradas firmemente dentro de las personas, sistemas, procesos y tecnologías de una

organización. Las capacidades (capabilities) no pueden producir valor por sí mismas sin los recursos

adecuados y apropiados.


17 | P á g i n a


18 | P á g i n a

Unidades de Negocio y Unidades de Servicio

Los Activos de Servicio son los recursos y las capacidades disponibles para el proveedor de servicios. Los

recursos son las aportaciones directas para la producción. Las capacidades representan la habilidad de la

organización para coordinar, controlar e implementar recursos para producir valor.

La organización desarrolla capacidades con el tiempo y suponen que la organización captura

conocimientos e integra esos conocimientos en sus capacidades. Las capacidades por sí mismas no

pueden producir valor. Los recursos adecuados y apropiados deben estar bajo el control del proveedor

para ejercer las capacidades de la organización y que éstas sean efectivas.

Unidad de Negocio

Una unidad de negocio es simplemente un conjunto de activos que tiene como finalidad crear valor para

los clientes a través de bienes y servicios. Los clientes pagan por el valor que reciben, lo cual asegura

que la unidad de negocio mantenga un retomo adecuado sobre los activos. La relación es buena siempre

y cuando el cliente reciba valor y la unidad de negocio recupere los costos y reciba algún tipo de

compensación o utilidad.

Unidad de Servicio

Las unidades de servicio son como las unidades de negocio, un conjunto de activos de servicio que se

especializa en crear valor a través de servicios. Los servicios definen la relación entre las unidades de

negocio y las unidades de servicio. En muchos casos, las unidades de negocio (clientes) y las unidades de

servicio forman parte de la misma organización. En otros casos las unidades de servicio son entidades

jurídicas independientes


19 | P á g i n a

Es necesario distinguir los diferentes tipos de proveedores de servicios. En tanto que muchos aspectos

de la administración de servicios aplican de la misma forma a todos los tipos de proveedores de

servicios, otros tales como clientes, contratos, competencia, espacios de mercado, ingresos y estrategia

adquieren diferentes significados dependiendo del tipo. Existen tres arquetipos de modelos de negocio

para los proveedores de servicios:

Tipo I — proveedor interno de servicios

Tipo II — unidad de servicios compartidos

Tipo III — proveedor externo de servicios


20 | P á g i n a


21 | P á g i n a

Definición de Administración de Servicio

Las organizaciones necesitan administrar y utilizar con efectividad sus activos de servicio para entregar

valor y habilitar resultados que están alineados con las necesidades del negocio.

La Administración de Servicios es el acto de transformar los recursos en servicios valiosos al explotar las

capacidades (capabilities) organizativas especializadas, que:

Adoptan la forma de funciones y procesos para administrar servicios durante un ciclo de vida

Se especializan en la estrategia, diseño, transición, operación y mejora continua

Representan la capacidad, competencia y confianza para actuar de una organización de servicios

Colocan a la organización como un agente de cambio para facilitar la transformación del negocio

Sin las capacidades (capabilities) especializadas requeridas, una organización de servicios es

simplemente un conjunto de recursos que por sí mismo tiene un valor intrínseco relativamente bajo

para los clientes.

A medida que se incrementa la madurez de la Administración de Servicios, se pueden entregar niveles

más altos de utilidad y garantía sin un incremento proporcional en el uso de los recursos, en concreto

los costos y el personal.

Las capacidades (capabilities) de la Administración de Servicios están influidas por los retos que

distinguen los servicios de otros sistemas de creación de valor tales como la manufactura, minería y

agricultura:

La naturaleza intangible del resultado y los productos intermedios de los procesos del servicio los vuelve difíciles de medir, controlar y validar (o probar)

La demanda está sumamente vinculada a la demanda de activos por parte del cliente para estimular la producción de servicios

El alto nivel de contacto para los productores y consumidores de servicios con una barrera pequeña o inexistente entre el cliente, la front-office y la back-office

La naturaleza perecedera de los resultados del servicio y la capacidad del servicio; los clientes necesitan contar con la seguridad de que el servicio seguirá siendo suministrado con una calidad consistente, en tanto que los proveedores necesitan asegurar un suministro estable de demanda por parte de los clientes.


22 | P á g i n a


23 | P á g i n a

Dueño del Servicio

Para asegurar que un servicio se administra con un enfoque en el negocio, es absolutamente

imprescindible la definición de un punto de responsabilidad único para proporcionar el nivel de atención

y enfoque requeridos para su entrega.

El Dueño de Servicio es responsable de la entrega de un servicio de TI específico y es una parte

fundamental que está involucrada en todos los procesos de TI subyacentes que habilitan o brindan

soporte al servicio que posee.

El Dueño de Servicio tiene las siguientes responsabilidades:

Representa el servicio en toda la organización

Proporciona información sobre los atributos del servicio tales como rendimiento, disponibilidad, etcétera.

Comprende el servicio (componentes, etcétera)

Sirve como un punto de escalar (notificación) para Incidentes mayores

Representa al servicio en las reuniones del Comité Asesor de Cambios para la administración de cambios que afectan al servicio bajo su cuidado

Contribuye a la mejora continua al proporcionar información sobre CSI

Participa en las reuniones de revisión de los servicios internos (dentro de TI)

Trabaja con el Administrador de CSI para identificar y establecer la prioridad de las mejoras del servicio

Participa en las reuniones de revisión de los servicios externos (con el negocio)

Es responsable de asegurar que la entrada del servicio en el Catálogo de Servicios sea precisa y reciba mantenimiento

Participa en la negociación de los Acuerdos de Nivel de Servicio (SLA) y Acuerdos de Nivel Operacional (OLA)


24 | P á g i n a


25 | P á g i n a


26 | P á g i n a

Proceso

Un proceso es un conjunto estructurado de actividades diseñadas para conseguir un objetivo específico.

Un proceso toma una o más aportaciones definidas y las convierte en resultados definidos.

Modelo de Proceso

El trabajo con procesos definidos ha sido el fundamento de ITIL desde su inicio. Al definir cuáles son las

actividades de la organización, qué aportaciones son necesarias y qué resultados se obtendrán a partir

del proceso, se puede trabajar de una forma más eficiente y efectiva. La medición y dirección de las

actividades del proceso incrementan su efectividad.

Un proceso:

Es un conjunto estructurado de actividades organizadas alrededor de un conjunto de objetivos definidos en términos medibles y que se expresan como beneficios para el negocio

Toma una o más aportaciones y las convierte en resultados definidos; resultados impulsados por los objetivos que incluyen mediciones del proceso (métricas) reportes y mejora del proceso

Lo desencadena un evento o más

Incluye todos los roles, responsabilidades, herramientas y controles de administración requeridos para entregar los resultados del proceso de forma confiable

Se debe documentar y controlar para que se pueda repetir y administrar

Requiere recursos y capacidades (capabilities) para habilitarlo, de otra manera sólo sería documentación

Debe contar con un dueño de proceso, una persona responsable de su éxito (que cumpla los objetivos, se adopte, documente, mejore, etcétera)

Debe ser efectivo en cuanto al cumplimiento de las normas operacionales (condiciones que deben cumplir los resultados), las cuales derivan de los objetivos del negocio

También puede definir o modificar políticas, normas, líneas directrices, actividades, procesos, procedimientos e instrucciones de trabajo en caso necesario


27 | P á g i n a


28 | P á g i n a

Proceso

Las definiciones de proceso describen acciones, dependencias y secuencias

Los procesos son ejemplos de sistemas de circuito cerrado porque proporcionan un cambio

y una transformación para conseguir una meta. Utilizan retroalimentación para las acciones

de auto refuerzo y autocorrección

Características

Medible

Podemos medir el proceso de una manera relevante

Es impulsado por el rendimiento. Los administradores desean medir el costo, la calidad y otras variables, en tanto que los profesionales están preocupados con la duración y productividad

Resultados Específicos

Un proceso existe para entregar un resultado específico. Este resultado debe ser individualmente identificable y medible

Clientes

Todos los procesos entregan sus resultados fundamentales a un cliente o una parte involucrada. El cliente o la parte involucrada pueden ser internos o externos a la organización, pero el proceso debe cumplir las expectativas del cliente

Responde a un evento específico

Si bien un proceso puede ser constante o iterativo, este debe ser rastreable conforme a un disparador específico


29 | P á g i n a

Dueño del Proceso

El Dueño de Proceso es responsable de garantizar que el proceso se lleve a cabo conforme a los

procesos acordados y documentados, y que cumple los objetivos de la definición de proceso.

Las tareas incluyen:

Documentar y publicar el proceso

Definir los Indicadores Clave de Rendimiento (KPI) para el proceso

Revisar y tomar una acción sobre los KPI

Mejorar el proceso

Revisar las mejoras propuestas para el proceso

Proporcionar información sobre el Plan de Mejora del Servicio (SIP)

Resolver los problemas con la ejecución del proceso

Garantizar que el personal está capacitado y conoce los roles de su proceso

Garantizar que el proceso y sus roles y responsabilidades asociados son revisados y auditados con regularidad

Garantizar que el proceso recibe los recursos de personal necesarios


30 | P á g i n a

Tres Tipos de Métricas

Métricas de Tecnología

Estas métricas con frecuencia están asociadas con métricas que se basan en los componentes y

aplicaciones, tales como el rendimiento, la disponibilidad, etcétera.

Métricas de Proceso

Estas métricas se capturan en CSFs, KPIs y métricas de actividad para los procesos de gestión de

servicios. Estas métricas pueden ayudar a determinar el estado general de un proceso. Las cuatro

preguntas clave que los KPI pueden ayudar a responder giran en tomo a la calidad, el rendimiento, el

valor y la conformidad del seguimiento del proceso. La CSI utilizó estas métricas como información para

la identificación de oportunidades de mejora para cada proceso.

Métricas de Servicio

Estas métricas son los resultados del servicio de principio a fin. Las métricas del componente se utilizan

para calcular las métricas del servicio.


31 | P á g i n a

Acerca de los CSF y KPI

Factor Crítico de Éxito (CSF)

Un CSF es algo que debe ocurrir en caso de que un proceso, proyecto, plan o servicio tengan éxito.

Indicador Clave de Rendimiento (KPI)

Un KPI es una métrica seleccionada de forma específica que se utiliza para medir el logro de cada CSF.

Muchas métricas se pueden medir, pero sólo las más importantes de éstas se definen como KPIs y se

utilizan para monitorear activamente los CSF.


32 | P á g i n a

Por ejemplo, un CSF (“proteger ¡os servicios de TI al realizar cambios”) sólo se puede medir mediante

KPIs, tales como reducción en el porcentaje de los cambios no exitosos, o reducción en el porcentaje de

los cambios que causan Incidentes, etcétera.

Los KPI se deben seleccionar para asegurar que se utilice un enfoque equilibrado para evaluar los CSF,

de manera que se administren la eficiencia, efectividad y rentabilidad. Para este fin, por lo general se

consideran cuatro categorías de KPI:

Valor: Reportes o encuestas para medir la efectividad y el valor percibido para las partes involucradas y usuarios

Calidad: Los indicadores de calidad por lo general se basan en actividades y se establecen para medir la calidad de las actividades individuales o clave conforme éstas se relacionan con el objetivo del servicio o el proceso de principio a fin.

Rendimiento: Métricas para determinar la velocidad y el rendimiento del servicio o proceso objetivo

Conformidad: Una medida del nivel de adopción del proceso. Los procesos pueden tener un valor percibido como bueno, de buena calidad y de rendimiento (throughput) rápido pero pueden ser adoptados únicamente por una fracción de la organización.

Cada una de éstas se puede evaluar utilizando un enfoque cualitativo y/o cuantitativo.

Ejemplo de Calidad Cualitativa:

CSF: Mejora de la calidad del servicio de TI

KPI: Incremento del 10% en la satisfacción del cliente en cuanto al manejo de Incidentes en los próximos

seis meses.

Métricas requeridas:

Puntuación original de la satisfacción del cliente en cuanto al manejo de Incidentes

Puntuación final de la satisfacción del cliente en cuanto al manejo de Incidentes

Ejemplo de Valor Cuantitativo:

CSF: Reducción de los costos de IT

KPI: Reducción del 10% en los costos del manejo de Incidentes de impresora.

Métricas requeridas:

Costo original del manejo de un Incidente de impresora

Costo final del manejo de un Incidente de impresora

Costo del esfuerzo de mejora


33 | P á g i n a


34 | P á g i n a

Función

Grupo de personas, una unidad u organización, que proporciona estructura y estabilidad

Especializada para realizar ciertos tipos de trabajo y responsabilizarse de resultados específicos

Autocontenida con capacidades (capabilities) y recursos necesarios para su rendimiento y resultados

Responsable de su propio cuerpo de conocimientos, que se acumulan a partir de la experiencia

Las funciones suelen optimizar sus métodos de trabajo localmente para concentrarse en los resultados

asignados, de este modo la coordinación de las funciones cruzadas y el control son imprescindibles para

el éxito de la organización como un todo. El uso de procesos compartidos permite utilizar una

especialización funcional en la organización al tiempo que proporciona los medios para la coordinación y

el control.

Roles

Un conjunto de responsabilidades, actividades y autorizaciones que se otorga a una persona o equipo.

Un rol se define en un proceso. Una persona o equipo pueden tener varios roles; por ejemplo, los roles

del Administrador de Configuraciones y Administrador de Cambios pueden ser realizados por una sola

persona.


35 | P á g i n a


36 | P á g i n a


37 | P á g i n a

Modelo RACI

Con frecuencia se utiliza una matriz de autoridad dentro de las organizaciones para indicar los roles y las

responsabilidades relacionados con los procesos y las actividades. Si bien existen muchas variaciones de

la matriz de autoridad, el modelo RACI está respaldado por los COBIT®1 (Objetivos de Control para la

Información y Tecnología Relacionada, un modelo de gobierno de tecnología de la información

ampliamente reconocido).

Al utilizar el modelo RACI como un ejemplo, sólo existe una persona responsable (accountable) de una

actividad, aunque varias personas pueden ser responsables (responsible) de la ejecución de partes de la

actividad. En este modelo, responsable (accountable) se refiere a la responsabilidad de principio a fin del

proceso. La responsabilidad debe permanecer con la misma persona en todas las actividades de un

proceso.

R Responsable (Responsible)

• Ejecución adecuada del proceso y las actividades • La persona o personas responsables de hacer que se lleve a cabo el trabajo

A Responsable (Accountable)

• Propiedad de la calidad, y los resultados finales del proceso • La persona que tiene la autoridad final sobre la decisión, actividad o diseño del proceso

C Consultada (Consulted)

• Participación a través de la aportación de conocimientos e información

I Informada • Recibe información acerca de la ejecución y calidad del proceso (Informed)

Problemas potenciales con el modelo RACI:

Contar con más de una persona responsable de un proceso significa que en la práctica nadie es responsable

Delegación de responsabilidad (responsibility/accountability) sin la autoridad necesaria

Concentración en relacionar los procesos y las actividades con los departamentos

División/combinación incorrecta de las funciones; agendas o metas en conflicto

Combinación de la responsabilidad para procesos estrechamente relacionados, tales como Administración de Incidentes, Problemas, Configuraciones, Cambios y Liberaciones

Modelo RACI Muestra

Para construir un modelo RACI se requieren los siguientes pasos:

Identificar las actividades/los procesos

Identificar/definir los roles funcionales

Llevar a cabo reuniones y asignar los códigos RACI

Identificar cualquier brecha o traslape, por ejemplo, cuando existen dos R o ninguna R

Distribuir la tabla e incorporar la retroalimentación

Asegurar que se sigan las asignaciones


38 | P á g i n a

W. Edwards Deming es ampliamente conocido por su filosofía de gestión que genera una mayor calidad,

mayor productividad y una posición más competitiva. Como parte de esta filosofía, Deming formuló 14

puntos de atención para los gestores. Algunos de estos puntos son más apropiados para la Gestión de

Servicios de Ti que otros. Para la mejora de la calidad propuso el Ciclo o Círculo Deming. Este ciclo aplica

particularmente para la CSI. Las cuatro etapas clave del ciclo son Planifique, Realice, Revise, Actúe

después de las cuales una fase de consolidación evita que el Círculo regrese a la etapa inicial. Nuestra

meta al utilizar el Ciclo de Deming es la mejora continua y constante. Es un principio fundamental de la

Mejora Continua del Servicio.

El Ciclo Deming es imprescindible en dos puntos de la CSI: Para la implementación de la CSI y para la

aplicación de la CSI en los servicios y procesos de gestión de servicios. En la implementación, se utilizan

las cuatro etapas del Ciclo Deming (Planifique, Realice, Revise, Actúe). Con la mejora continua, la CSI

recurre a las etapas Revise y Actúe para monitorear, medir, revisar e implementar las iniciativas.

El Ciclo está respaldado por un enfoque de gestión dirigido por procesos, en el cual se cuenta con

procesos definidos, las actividades se miden para determinar su conformidad con los valores esperados,

y los resultados se auditan para validar y mejorar el proceso.


39 | P á g i n a


40 | P á g i n a

Publicaciones Centrales de ITIL

Las Publicaciones Centrales de ITIL ofrecen una guía de buenas prácticas que aplica a todos los tipos de

organizaciones que brindan servicios a un negocio.

Las Publicaciones Centrales de ITIL consisten de cinco publicaciones, cada una ofrece la guía necesaria

para un enfoque integrado en cuanto a la administración de servicios y aborda las capacidades

(capabilities) que generan un impacto directo sobre el desempeño de un proveedor de servicios:

Estrategia del Servicio — Piense y actúe de una forma estratégica y modele y planifique servicios que tienen una utilidad y garantía

Diseño del Servicio — Cree la integridad del servicio a través del diseño de servicios nuevos o modificados de una manera amplia, consistente y efectiva

Transición del Servicio — Desarrolle y mejore las capacidades (capabilities) para llevar a cabo efectiva y eficientemente la transición de servicios nuevos o modificados hacia la operación, al controlar los riesgos de falla o interrupción, mientras realiza la Estrategia del Servicio codificada en el Diseño del Servicio

Operación del Servicio — Coordine y lleve a cabo las actividades y los procesos necesarios para entregar y administrar servicios a los niveles acordados

Mejora Continua del Servicio — Guía práctica para la evaluación y mejora de la calidad/madurez de los servicios, procesos y el Ciclo de Vida del Servicio

La estructura de las publicaciones centrales adquiere la forma de uñ ciclo de vida, es interactiva y

multidimensional. Asegura que las organizaciones están configuradas para optimizar las capacidades

(capabilities) de aprendizaje para un área, y de mejora para otras. Se espera que las publicaciones

centrales proporcionen estructura, estabilidad y fuerza a las capacidades (capabilities) de administración

de servicios con principios, métodos y herramientas duraderos. Esto sirve para proteger las inversiones y

brindar las bases necesarias para la medición, el aprendizaje y la mejora.


41 | P á g i n a


42 | P á g i n a

Información específica de cada uno de los procesos que se incluyen en el ciclo de vida del servicio de ITIL

se pueden localizar en las publicaciones principales de ITIL como se muestra:

ESTRATEGIA DEL SERVICIO Representa las políticas y los objetivos Modele y planifique servicios que tienen una utilidad y garantía:

DISENO DEL SERVICIO Una de las tres fases progresivas que representa el cambio y la transformación Servicios de alta calidad, rentables y consistentes

TRANSICION DEL SERVICIO Una de las tres fases progresivas que representa el cambio y la transformación Transición de servicios nuevos y modificados en operaciones

OPERACIÓN DEL SERVICIO Una de las tres fases progresivas que representa el cambio y la transformación para conseguir efectividad y eficiencia en la entrega de los servicios

MEJORA CONTINUA DEL SERVICIO Representa el Aprendizaje y la mejora Proceso de mejora de Siete pasos


43 | P á g i n a

La especialización y coordinación son necesarias en el enfoque del ciclo de vida. Esto es posible gracias a

la retroalimentación y el control entre las funciones y los procesos dé todos los elementos del ciclo de

vida. El patrón dominante en el ciclo de vida es el progreso secuencial que comienza a partir de la

Estrategia del Servicio (SS) a través del Diseño del Servicio (SD), Transición del Servicio (ST) y Operación

del Servicio (SO) y que posteriormente regresa a la Estrategia del Servicio a través de la Mejora Continua

del Servicio (CSI). Sin embargo, ese no es el único patrón de acción. Cada elemento del ciclo de vida

proporciona puntos para la retroalimentación y el control.

La combinación de múltiples perspectivas permite una mayor flexibilidad y control entre los ambientes y

las situaciones. El enfoque del ciclo de vida imita la realidad de la mayoría de las organizaciones donde la

administración efectiva requiere el uso de múltiples perspectivas de control. Los responsables del

diseño, desarrollo y mejora de los procesos de la Administración de Servicios pueden adoptar una

perspectiva de control basada en los procesos.


44 | P á g i n a

ESTRATEGIA DEL SERVICIO


45 | P á g i n a


46 | P á g i n a

El Portafolio de Servicios representa los siguientes elementos:

Compromisos e inversiones realizados por un Proveedor de Servicios para todos los Clientes y Espacios de Mercado

Compromisos contractuales actuales

Desarrollo del nuevos Servicios

Programas de Mejora Continua del Servicio iniciados por la Mejora Continua del Servicio

El Portafolio de Servicios también incluye servicios de terceros que forman una parte integral de las

ofertas de servicios para los clientes, algunos de los cuales son visibles para los clientes, y otros no.

Un enfoque de administración de portafolios ayuda a que los gestores determinen la prioridad de las

inversiones y mejoren la asignación de los recursos. Un Portafolio de Servicios representa la habilidad y

preparación de un Proveedor de Servicios para servir a los Clientes y Espacios de Mercado. Representa

todos los recursos que actualmente están involucrados o están siendo liberados en diversas fases del

Ciclo de Vida del Servicio. Los cambios a los Portafolios de Servicios están regidos por las políticas y los

procedimientos. El Portafolio de Servicios se divide en tres fases: Canal de Entrada de Servicios, Catálogo

de Servicios y Servicios Retirados.


47 | P á g i n a


48 | P á g i n a

Los Servicios Conceptuales

La fase Servicios Conceptuales consiste de servicios en desarrollo para un Espacio de Mercado o Cliente dados. En la fase de Transición del Servicio se pondrán estos servicios en operación una vez terminados el Diseño, Desarrollo y la Prueba del Servicio. Los Espacios del Mercado Un Espacio de Mercado se define y determina por un conjunto de resultados de negocio que pueden ser

facilitados por un servicio; representa un conjunto de oportunidades para que los Proveedores de

Servicios entreguen valor al negocio de un cliente a través de uno o más servicios.

Entre los ejemplos de algunos resultados de negocio que pueden constituir la base para uno o más

Espacios de Mercado, se incluyen:

Los equipos de ventas son más productivos al utilizar el sistema de administración de ventas en computadoras inalámbricas

El sitio Web de comercio electrónico está vinculado al sistema de administración de almacenes

Las aplicaciones clave de negocio son monitoreadas y están seguras

Los funcionarios de crédito cuentan con un acceso más rápido la información que se requiere

Acerca de los solicitantes de préstamos

El servicio de pago de facturas en línea ofrece más opciones de pago a los compradores

Se garantiza la continuidad de los negocios

Una definición adecuada de los servicios toma en cuenta el contexto bajo el cual los Clientes perciben valor de los servicios. Los Espacios de Mercado ayudan a colocar los servicios en el contexto dentro del cual los Clientes pueden percibir con mayor claridad el valor que se obtiene de esos servicios.

Los Espacios de Mercado contribuyen a una definición de servicios basados en resultados que aseguran

que los gestores planifiquen y ejecuten todos los aspectos de la administración de servicios en su

totalidad desde la perspectiva de lo que es valioso para el Cliente y lo que puede medir. Los servicios por

lo tanto no sólo crean valor para los Clientes, sino que también captan valor para el Proveedor de

Servicios.

El Catálogo de Servicios

El Catálogo de Servicios es el subconjunto del Portafolio de Servicios que es visible para los Clientes.

Consiste de servicios que están activos en la fase de Operación del Servicio, así como aquellos servicios

aprobados para ser ofrecidos a los Clientes actuales o prospectos. Debido a que el Catálogo de Servicios

es una expresión de la capacidad operativa del Proveedor de Servicios dentro del contexto de un Cliente

o Espacio de Mercado, puede ser muy útil para desarrollar soluciones adecuadas para Clientes de uno o

más servicios.


49 | P á g i n a

El Catálogo de Servicios puede servir para lo siguiente:

Servir como una orden de servicio y un mecanismo de canalización de la demanda

Comunicar y definir las políticas, las guías y la rendición de cuentas requeridas para la Administración del Portafolio de Servicios

Definir los criterios para determinar qué servicios entran en la Administración del Portafolio de Servicios y el objetivo de cada servicio

Actuar como el portal de adquisición para los Clientes, incluyendo precios y compromisos a nivel de servicio, así como los términos y las condiciones para el aprovisionamiento del servicio

En el Catálogo de Servicios es donde los servicios se dividen en componentes. Aquí es donde los activos,

procesos y sistemas son introducidos con los puntos de entrada y términos para su uso y

aprovisionamiento. Se pueden proyectar varios Catálogos de Servicios desde el Portafolio de Servicios.

Además, un subconjunto del Catálogo de Servicios puede ser un catálogo de servicios de terceros o de

externos. Este Catálogo de terceros puede consistir de servicios que son ofrecidos a los Clientes con

diversos niveles de valor agregado o en combinación con otros elementos del Catálogo de Servicios.

Los servicios de terceros se pueden utilizar para resolver la demanda hasta que los artículos del Canal de

Entrada de Servicios se encuentran en la fase de operación, o bien se pueden utilizar como un sustituto

para los servicios que se están eliminando de la fase del Catálogo de Servicios.

Servicios Retirados

Los Servicios Retirados son servicios del Catálogo de Servicios que se eliminan de la fase o que se retiran.

La actividad de eliminar un servicio de una fase forma parte de la Transición del Servicio y garantiza el

cumplimento total de todos los compromisos que se hicieron con los Clientes, así como la liberación de

los activos de servicio de los contratos.

El Catálogo de Servicios es la única parte del Portafolio de Servicios que recupera costos o genera

utilidades. Por último, el Portafolio de Servicios como un todo debe contar con una combinación

adecuada de servicios de entrada y el Catálogo de Servicios para asegurar la viabilidad financiera del

Proveedor de Servicios.


50 | P á g i n a


51 | P á g i n a

El Catálogo de Servicios tiene dos aspectos:

El Catálogo de Servicios del Negocio presenta la visión del cliente del Catálogo de Servicios. Contiene detalles de todos los servicios de TI que se ofrecen al cliente, junto con las relaciones con las unidades de negocio y los procesos de negocio que dependen de los servicios de TI

El Catálogo de Servicios Técnico soporta el Catálogo de Servicios de Negocio pero no forma parte de la visión del Cliente. Contiene detalles de todos los servicios de TI que se ofrecen al cliente, junto con las relaciones con los servicios de soporte, servicios compartidos, componentes y Elementos de Configuración (CIs) necesarios para soportar el aprovisionamiento del servicio al negocio

La relación entre estos dos aspectos se ilustra en el diagrama que se incluye en la diapositiva anterior.

La situación preferida que adoptan las organizaciones más maduras mantiene estos dos aspectos dentro

de un Solo Catálogo de Servicios que forma parte de una actividad totalmente integrada de la

Administración de Servicios y del Portafolio de Servicios.

El Catálogo de Servicios de Negocio facilita un proceso mucho más proactivo de la Administración de

Niveles de Servicio, lo que permite desarrollar más el campo de la Administración de Servicios de

Negocio.

El Catálogo de Servicios Técnicos resulta útil para la construcción de las relaciones entre los servicios,

SLAs, OLAs y otros acuerdos y componentes de soporte al ayudar a identificar la tecnología que se

requiere para soportar un servicio y los grupos de soporte que brindan soporte a los componentes.


52 | P á g i n a

El riesgo se define como la incertidumbre de un resultado, ya sea que se trate de una oportunidad

positiva o de una amenaza negativa. La administración de riesgos requiere la identificación y el control

de la exposición al riesgo, el cual puede tener un impacto en el alcance de los objetivos de negocio de

una organización.

Todas las organizaciones administran sus riesgos, pero no siempre de una manera visible, repetible y

que se puede aplicar consistentemente para soportar la toma de decisiones. La tarea de la

administración de riesgos consiste en asegurar que la organización haga un uso rentable de un marco de

riesgos que tiene una serie de pasos bien definidos. El objetivo es soportar una mejor toma de

decisiones a través de la comprensión de los riesgos y su impacto probable.


53 | P á g i n a

Existen dos fases distintas en la Administración de Riesgos: Análisis de Riesgos y Administración de la

Mitigación del Riesgo.

Análisis de Riesgos

El Análisis de Riesgos involucra la identificación y evaluación del nivel (medida) de los riesgos calculados

a partir de los valores de activos evaluados y los niveles de amenazas evaluadas, así como de las

vulnerabilidades de esos activos.

Administración de la Mitigación del Riesgo

La mitigación del riesgo también involucra la identificación, selección y adopción de medidas justificadas

por los riesgos identificados en los activos en términos de su impacto potencial en los servicios en caso

de que ocurra un fallo, así como la reducción de esos riesgos a un nivel aceptable.


54 | P á g i n a

Un Caso de Negocio describe el potencial, ya sea bueno o malo de una propuesta, de una manera tal

que la propuesta se puede juntar otras propuestas para su comparación.

Estructura del Caso de Negocio

A. Introducción Presenta los objetivos de negocio que se tratan en la iniciativa de administración

de servicios.

B. Métodos y Suposiciones Define los límites del caso de negocio, tales como el plazo, costos y

beneficios.

C. Impactos de Negocio Los resultados financieros y no financieros del caso de negocio.

D. Riesgos y Contingencias La probabilidad de que vayan a surgir diferentes resultados.

E. Recomendaciones Acciones específicas recomendadas.

Con facilidad, se pueden encontrar una gran variedad de formatos de Casos de Negocio en la Web, y

dentro de una organización se puede utilizar más de un formato; sin embargo, una Estructura de Caso

de Negocio común incluye los elementos anteriores.


55 | P á g i n a

ADMINISTRACION DE LA DEMANDA

La Administración de la Demanda con frecuencia utiliza el Cargo Diferencial para fomentar que los

Clientes utilicen los servicios de TI en los horarios menos ocupados. La Administración de la Demanda

también utiliza otras técnicas tales como la limitación del número de usuarios concurrentes.

La Administración de la Demanda:

Son actividades que comprenden e influyen en la demanda del Cliente por Servicios y el suministro de Capacidad para cumplir esas demandas

A nivel Estratégico, la Administración de la Demanda puede involucrar el análisis de los Patrones de Actividad de Negocio y Perfiles del Usuario

A nivel Táctico puede involucrar el uso del Cargo Diferencial para fomentar entre los Clientes el uso de un Servicio de TI en horarios con menor actividad


56 | P á g i n a

La capacidad en exceso genera costos sin crear un valor que proporciona una base para la recuperación del costo. Los clientes se resisten a pagar por capacidad inactiva a menos que tenga valor para ellos

La capacidad insuficiente genera un impacto sobre la calidad de los servicios entregados y limita el crecimiento del servicio. Los SLA, la prospección, planificación y estrecha coordinación con el cliente pueden reducir la incertidumbre en la demanda pero no pueden eliminarla por completo

El consumo produce demanda y la producción consume demanda en un patrón altamente sincronizado. A diferencia de los bienes, los servicios no se pueden fabricar con anticipación ni surtir en un inventario de bienes esperando la demanda. La demanda y la capacidad están mucho más conectadas en los sistemas de servicio aun cuando se comparan con la fabricación justo-a-tiempo (JIT)

La capacidad productiva de los recursos disponibles para un servicio se ajusta de acuerdo con las prospecciones y los patrones de demanda Algunos tipos de capacidad se pueden incrementar rápidamente conforme se requieren, y liberar cuando no se utilizan. Se puede influir en la llegada de la demanda al utilizar incentivos de precio; sin embargo, no se puede producir ni surtir el resultado del servicio antes de que la demanda en realidad se materialice


57 | P á g i n a

ADMINISTRACION FINANCIERA

La Administración de la Demanda con frecuencia utiliza el Cargo Diferencial para fomentar que los

Clientes utilicen los servicios de TI en los horarios menos ocupados. La Administración de la Demanda

también utiliza otras técnicas tales como la limitación del número de usuarios concurrentes.

La Administración de la Demanda:

Son actividades que comprenden e influyen en la demanda del Cliente por Servicios y el suministro de Capacidad para cumplir esas demandas

A nivel Estratégico, la Administración de la Demanda puede involucrar el análisis de los Patrones de Actividad de Negocio y Perfiles del Usuario

A nivel Táctico puede involucrar el uso del Cargo Diferencial para fomentar entre los Clientes el uso de un Servicio de TI en horarios con menor actividad


58 | P á g i n a


59 | P á g i n a

Una meta de la Administración Financiera es asegurar el financiamiento adecuado para la entrega y el

consumo de servicios. La planificación brinda la traducción y calificación financiera de la demanda futura

esperada de servicios de TI. La Planificación de la Administración Financiera parte de la planificación

histórica de TI al concentrarse en la demanda y suministro de variaciones que resultan de la estrategia

del negocio, información de la capacidad y prospección, en lugar de los tradicionales gastos de artículos

de línea individuales o cuentas de costo del negocio.

La contabilidad dentro de la Administración Financiera se diferencia de la contabilidad tradicional ya que

se deben definir categorías y características adicionales que permitan la identificación y el rastreo de los

gastos concebidos en función del servicio o artículos de capital. La Administración Financiera desempeña

un rol transaccional entre los sistemas financieros corporativos y la administración de servicios.

Un modelo de ‘contra cargos’ para TI puede ofrecer responsabilidad y transparencia. Sin embargo, si el

modelo operativo actual ofrece un reaprovisionamiento de fondos anual más sencillo, entonces el cargo

con frecuencia no es necesario para ofrecer responsabilidad y transparencia. En este ejemplo la

visibilidad deseada provendría en su lugar de las actividades e información de la planificación, modelado

de la demanda y Valoración del Servicio.

El cumplimiento implica el uso de métodos y prácticas adecuadas y consistentes de contabilidad,

específicamente en cuanto a la valoración financiera de activos, prácticas de capitalización,

reconocimiento de ingresos, y controles de acceso y seguridad.

Meta de la Valoración del Servicio

La meta principal de la Valoración del Servicio es producir un valor para los servicios que el negocio

perciba como justo, y cumpla las necesidades del proveedor en términos de su respaldo como una

inquietud constante.


60 | P á g i n a

DISEÑO DEL SERVICIO


61 | P á g i n a

El propósito principal de la etapa Diseño del Servicio del ciclo de vida es el diseño de servicios nuevos o

modificados para su introducción en el ambiente de producción. Es importante que se adopte un

enfoque amplio en todos los aspectos del diseño, y que cuando se modifique o corrija cualquiera de los

elementos individuales de diseño se considere el resto de los aspectos. Por lo tanto durante el diseño y

desarrollo de una aplicación nueva, esto no se debe llevar a cabo de forma aislada, sino que también

debe considerar el impacto sobre el servicio en general, los sistemas de administración y las

herramientas (por ejemplo: el Portafolio de Servicios y el Catálogo de Servicios), las arquitecturas, la

tecnología, los procesos de Administración de Servicios y las medidas y métricas necesarias. Esto no sólo

asegurará que el diseño aborde los elementos funcionales, sino también que todos los requerimientos

de Administración y operacionales se tratan como una parte fundamental del diseño y no se agregan de

último momento


62 | P á g i n a


63 | P á g i n a

Las metas y los objetivos principales del Diseño del Servicio son:

Diseñar servicios para satisfacer los objetivos del negocio, con base en los requerimientos de

calidad, conformidad, riesgo y seguridad

Diseñar servicios que se pueden desarrollar y mejorar de una manera fácil y eficiente

Diseñar procesos eficientes y efectivos para el diseño, transición, operación y mejora de

servicios TI de alta calidad

Identificar y administrar los riesgos

Diseñar infraestructuras de TI, ambientes, aplicaciones y recursos y capacidades (capabilities) de

datos/información seguros y resistentes

Diseñar métodos de medición y métricas

Producir y mantener planes, procesos, políticas, arquitecturas, marcos y documentos de TI para

el diseño de soluciones de TI de calidad

Ayudar con el desarrollo de políticas y normas en todas las áreas de diseño y planificación de

servicios y procesos de TI

Desarrollar las habilidades y capacidades (capabilities) dentro de la TI al mover las actividades de

estrategia y diseño hacia las tareas operacionales

Contribuir a la mejora de la calidad general del servicio de TI dentro de las restricciones de

diseño impuestas, especialmente mediante la reducción de la necesidad de retrabajos

El Diseño del Servicio debe considerar los siguientes aspectos al diseñar las soluciones del servicio para

cumplir las necesidades nuevas y en evolución del negocio:

Proceso del negocio

Servicio

Acuerdos de Nivel de Servicio (SLA) / Requerimientos de Nivel de Servicio (SLR)

Infraestructura

Ambiente

Datos

Aplicaciones

Servicios de Soporte

Acuerdos de Nivel Operacional (OLA) y contratos

Equipos de Soporte

Proveedores


64 | P á g i n a


65 | P á g i n a

Beneficios de un Buen Diseño del Servicio

Menor Costo Total de Propiedad (TCO): El costo de propiedad sólo se puede minimizar si todos los aspectos de los servicios, procesos y la tecnología se diseñan correctamente e implementan contra el diseño

Calidad mejorada del servicio: Se mejorará tanto la calidad del servicio como la calidad operacional

Consistencia mejorada del servicio: Ya que los servicios se diseñan dentro de la estrategia, arquitecturas y restricciones corporativos

Implementación más sencilla de los servicios nuevos o modificados: Ya que existe un Diseño del Servicio integrado y completo, así como una producción de Paquetes de Diseño del Servicio (SDP) completos

Alineación mejorada del servicio: Participación desde la concepción del servicio al asegurar que los servicios nuevos o modificados coinciden con las necesidades de negocio, y contar con servicios diseñados para cumplir los Requisitos de Nivel de Servicio

Rendimiento más efectivo del servicio: Con la incorporación y el reconocimiento de los planes de Capacidad, Disponibilidad Financiera y Continuidad de los Servicios de TI

Gobierno mejorado de la TI: Ayuda con la implementación y comunicación de un conjunto de controles para el gobierno efectivo de la TI

Administración más efectiva de Servicios y procesos de TI : Los procesos se diseñarán con una calidad óptima y de manera rentable

Información y toma de decisiones mejoradas: Las medidas y métricas más completas y efectivas harán posible una mejor toma de decisiones y realización de mejoras continuas a las prácticas de administración de servicios en la etapa de diseño del ciclo de vida del servicio


66 | P á g i n a


67 | P á g i n a

Proveedor

Cualquier tercero externo necesario para proporcionar soporte a cualquiera de los componentes o entregar los servicios que se requieren para proporcionar un servicio al negocio

Opera dentro del alcance de un contrato que se negocia entre el proveedor de servicios y el proveedor

Es administrado mediante el proceso de Administración de Proveedores

Acuerdo de Nivel de Servicio (SLA)

Un acuerdo por escrito entre un proveedor de servicios de TI y sus clientes, que define los objetivos de servicio clave y las responsabilidades de ambas partes

Constituye la base para la administración de la relación entre el proveedor de servicios y el cliente

Acuerdo de Nivel Operacional (OLA)

Un Acuerdo de Nivel Operacional (OLA) es un acuerdo entre un proveedor de servicios de TI y otra parte de la misma organización que ayuda con el aprovisionamiento de los servicios de TI

Contiene los objetivos que soportan al Acuerdo de Nivel de Servicio (SLA)

Puede incluir partes que no pertenecen al área de TI de la misma organización, tales como Recursos Humanos, Finanzas o Mantenimiento Físico.

Contrato de Soporte

Proporciona un compromiso que tiene fuerza jurídica entre dos o más partes

Se utiliza como la base de los acuerdos del proveedor externo en los que se requiere un compromiso que se pueda hacer cumplir conforme a las leyes

Contiene Responsabilidades, Objetivos y las actividades necesarias para administrar las partes a lo largo del ciclo de vida del contrato


68 | P á g i n a

Las Cuatro P

Muchos diseños, planes y proyectos fracasan por la carencia de preparación y administración La

implementación de ITIL como una práctica consiste en preparar y planificar el uso efectivo y eficiente de

las cuatro P (por sus siglas en inglés):

Personas Este término se refiere a la organización de las personas a través de las funciones, roles,

equipos, grupos, divisiones y departamentos. Estos se definen utilizando organigramas y descripciones

de trabajo.

Procesos Este término se refiere a la documentación de todos los procesos relevantes tales como

políticas, flujos de proceso, procedimientos e instrucciones de trabajo.

Productos/Tecnología Este término se refiere a los servicios, la tecnología y las herramientas.

Socios /Proveedores Este término se refiere a los proveedores, fabricantes y distribuidores.


69 | P á g i n a

Durante la etapa de diseño, se debe producir un Paquete de Diseño del Servicio (SDP) para cada servicio

nuevo, cambio mayor a un servicio, eliminación de un servicio o cambios al Paquete de Diseño del

Servicio mismo. Posteriormente, este paquete pasa de la etapa de Diseño del Servicio a la Transición del

Servicio junto con los detalles de todos los aspectos del servicio y sus requisitos a lo largo de todas las

etapas posteriores de su ciclo de vida.


70 | P á g i n a

Cinco Aspectos Principales del Diseño del Servicio

Se debe adoptar un enfoque integrado general para las actividades de diseño documentadas en la

sección anterior y se debe cubrir el diseño de:

Las soluciones de servicio, incluyendo todos los requisitos, recursos y capacidades funcionales necesarios y acordados

Los sistemas y herramientas de Administración de Servicios, en especial el Portafolio de Servicios para la administración y el control de los servicios a lo largo de su ciclo de vida

Las arquitecturas de la tecnología, arquitecturas de la administración y herramientas que se requieren para proporcionar los servicios

Los procesos que se necesitan para el diseño, la transición, operación y mejora de los servicios

Los sistemas, métodos y métricas de medición para los servicios, las arquitecturas y sus principales componentes y los procesos


71 | P á g i n a

Existen muchas actividades que se deben completar dentro de la etapa Diseño del Servicio para un

servicio nuevo o modificado. Se requiere un enfoque formal y estructurado para producir el servicio

nuevo con el costo, funcionalidad y calidad correctos y dentro del periodo adecuado. Este proceso y las

etapas que lo constituyen se ilustran en la Figura 3.5, junto con el resto de las áreas principales que será

necesario involucrar dentro del proceso. Este proceso debe ser iterativo/incremental para asegurar que

el servicio entregado cumple las necesidades en constante evolución y cambio del negocio durante el

desarrollo del proceso del negocio y el Ciclo de Vida del Servicio de TI. Es posible que sea necesario

asignar administradores de proyecto y equipos de proyecto adicionales para administrar las etapas

dentro del ciclo de vida para la implementación del servicio nuevo.


72 | P á g i n a

El servicio se considera junto con los sistemas y las herramientas de Administración de Servicios,

especialmente el Portafolio de Servicios, para asegurar que el servicio nuevo o modificado es

consistente con el resto de los servicios, y que el resto de los servicios con los que se conecta, que

soportan o dependen de los servicios nuevos o modificados son consistentes con este servicio nuevo. De

no ser así, será necesario adaptar el diseño del servicio nuevo o el resto de los servicios existentes.

Además, se deben revisar los sistemas y las herramientas de Administración de Servicios para asegurar

que pueden soportar el servicio nuevo o modificado.


73 | P á g i n a

El servicio se considera junto con las arquitecturas de tecnología y los sistemas de Administración para

asegurar que todas las arquitecturas de tecnología y los sistemas de Administración son consistentes

con el servicio nuevo o modificado, y tienen la capacidad (capability) para operar y mantener el servicio

nuevo. De no ser así, entonces será necesario corregir las arquitecturas o los sistemas de

Administración, o revisar el diseño del nuevo servicio.


74 | P á g i n a

Los procesos, roles, responsabilidades y habilidades deben tener la capacidad (capability) para operar,

soportar y mantener el servicio nuevo o modificado. De no ser así, será necesario revisar el diseño del

servicio nuevo o mejorar las capacidades (capabilities) del proceso existente. Esto incluye todos los

procesos de TI y de Administración de Servicios, no sólo los procesos clave del Diseño del Servicio.


75 | P á g i n a

Los métodos de medición existentes deben proporcionar las métricas requeridas sobre el servicio nuevo

o modificado. De no ser así, entonces será necesario mejorar los métodos de medición o revisar las

métricas del servicio.


76 | P á g i n a

ADMINISTRACION DEL CATALOGO DE SERVICIOS


77 | P á g i n a


78 | P á g i n a


79 | P á g i n a

Conceptos Básicos de la SCM

Definición de Servicio

El personal de TI con frecuencia confunde un servicio como lo percibe el cliente con un sistema de TI. En

muchos casos un servicio puede estar conformado por otros servicios (y así sucesivamente) que a su vez

están conformados por un sistema de TI o más. Con frecuencia, un buen punto de inicio es preguntar a

los clientes qué servicios de TI utilizan y cómo se correlacionan, y soportan estos servicios a los procesos

de su negocio. Con frecuencia los clientes tienen una mayor claridad de lo que creen que es un servicio.

Jerarquía del Servicio

Para evitar confusiones, puede ser una buena idea definir una jerarquía del servicio dentro del Catálogo

de Servicios, al calificar con exactitud qué tipo de servicio se registra, por ejemplo: Servicio del negocio

(aquel que ve el cliente). De otra manera, también será necesario registrar los servicios de soporte, tales

corno los servicios de infraestructura, servicios de red, servicios de aplicación (todos invisibles para el

cliente, pero imprescindibles para la entrega de los servicios de TI).

Servicio como un Elemento de Configuración (CI)

Al definir cada servicio como un Elemento de Configuración (CI) y, cuando así corresponde, relacionar

éstos para formar una jerarquía del servicio, la organización puede relacionar eventos tales como

Incidentes y Solicitudes de Cambio (RFC) con los servicios afectados, y de esta manera proporcionar la

base para el monitoreo y la generación de reportes del servicio utilizando una herramienta integrada.

Por lo tanto es imprescindible que los cambios dentro del Portafolio de Servicios y el Catálogo de

Servicios estén sujetos al proceso de la Administración de Cambios.

Catálogo de Servicios del Negocio

El Catálogo de Servicios del Negocio contiene los detalles de todos los servicios de TI que se entregan al

cliente, junto con las relaciones con las unidades de negocio y los procesos del negocio que dependen

de los servicios de TI.

Catálogo de Servicios Técnicos

El Catálogo de Servicios Técnicos contiene los detalles de todos los servicios de TI que se entregan al

cliente, junto con las relaciones con los servicios de soporte, servicios compartidos, componentes y CIs

necesarios para respaldar el aprovisionamiento del servicio al negocio. Este debe respaldar al Catálogo

de Servicios del Negocio y no formar parte de la visión del cliente.


80 | P á g i n a

ADMINISTRACION DE NIVELES DE SERVICIO


81 | P á g i n a

La Administración de Niveles de Servicio (SLM) negocia, acuerda y documenta los objetivos

correspondientes de los servicios de TI con los representantes del negocio y posteriormente monitorea y

produce reportes sobre la capacidad del proveedor de servicios para entregar el nivel de servicio

acordado. La SLM es un proceso imprescindible para todas las organizaciones de proveedores de

servicios de TI. Es responsable de acordar y documentar los objetivos y las responsabilidades del nivel de

servicio dentro del Acuerdo de Nivel de Servicio (SLA) y los Requerimientos de Nivel de Servicio (SLR)

para todas las actividades dentro del área de TI.


82 | P á g i n a

La SLM debe proporcionar un punto de contacto y comunicación regulares con los clientes y gestores del

negocio de una organización. Debe representar al proveedor de servicios de TI ante el negocio y al

negocio ante el proveedor de servicios de TI. Esta actividad debe abarcar tanto el uso de los servicios

existentes como los requisitos futuros potenciales para los servicios nuevos o modificados. La SLM

necesita administrar la expectativa y percepción del negocio, de los clientes y usuarios, así como

asegurar que la calidad de servicio que entrega el proveedor de servicios coincide con esas expectativas

y necesidades. Para hacer esto con efectividad, la SLM debe establecer y mantener Acuerdos de Nivel de

Servicio (SLAs) para todos los servicios reales actuales, y administrar el nivel de servicio que se

proporciona para cumplir los objetivos y medidas de calidad que se incluyen en el Acuerdo de Nivel de

Servicio. La SLM también debe producir y acordar Requisitos de Nivel de Servicio (SLR) para todos los

servicios planificados nuevos o modificados.


83 | P á g i n a


84 | P á g i n a

SLA basado en el servicio: Este se refiere a cuando un SLA cubre un servicio para todos los clientes de

ese servicio, por ejemplo, se puede establecer un SLA para el servicio de correo electrónico de una

organización, el cual cubre a todos los clientes de ese servicio.

Cuando se proporcionan niveles comunes de servicio a todas las áreas del negocio (por ejemplo: correo

electrónico o telefonía) el SLA basado en el servicio se puede utilizar como un enfoque eficiente.

También se pueden utilizar múltiples clases de servicio (por ejemplo: oro, plata y bronce) para

incrementar la efectividad de los SEA basados en el servicio.

SLA de múltiples niveles: Las estructuras del SEA de múltiples niveles permiten que los SLA se

mantengan en un tamaño manejable, evita la duplicación innecesaria, y reduce la necesidad de

actualizaciones frecuentes. Un ejemplo puede incluir:

Nivel corporativo: Cobertura de todos los problemas genéricos de la SLM apropiados para todos los clientes de la organización. Esos problemas suelen ser menos volátiles, de manera que las actualizaciones se requieren con menor frecuencia

Nivel cliente: Cobertura de todos los problemas de la SLM relevantes para el grupo o unidad de negocio de un cliente en particular, independientemente del servicio que se utiliza

Nivel servicio: Cobertura de todos los problemas de la SLM relevantes para el servicio específico, en relación con un grupo del cliente específico (uno para cada servicio cubierto por el SEA)

Requerimientos de Nivel de Servicio (SLR) El conjunto de objetivos y responsabilidades se debe

documentar y acordar dentro de un SLR para cada servicio nuevo o modificado propuesto.

Gráfica SLAM Una gráfica de Monitoreo del SLA (SLAM) se puede utilizar al frente de un reporte del

servicio para proporcionar una descripción general ‘en un vistazo’ acerca de cómo se miden los logros

contra los objetivos. Estas gráficas son más efectivas si se codifican por colores (Rojo, Ambar, Verde, y

como resultado algunas veces se les conoce como gráficas RAG, por sus siglas en inglés).

Revisión del Servicio Reuniones periódicas de revisión que se llevan a cabo regularmente con los

clientes (o sus representantes) para revisar los logros del servicio en el último periodo y para anticipar

cualquier problema en el siguiente periodo. Es normal llevar a cabo estas reuniones cada mes o, como

mínimo, cada trimestre.

Plan de Mejora del Servicio (SIP) Los SIP se utilizan para registrar todas las acciones y los planes de

mejora acordados entre los proveedores de servicios y sus proveedores, siempre que es necesario, y se

deben utilizar para administrar el progreso de las acciones de mejora acordadas, incluyendo las medidas

de reducción de riesgos.


85 | P á g i n a

Desencadenadores

Existen muchos desencadenadores que provocan actividades en la SLM. Éstos incluyen:

Cambios en el Portafolio de Servicios

Acuerdos, SLRs, SLAs, OLAs o contratos nuevos o modificados

Reuniones y acciones de revisión del servicio

Infracciones del servicio o amenaza de infracciones

Halagos y quejas

Actividades periódicas tales como revisión, generación de reportes, y encuestas de satisfacción

del cliente

Cambios en la estrategia o política


86 | P á g i n a

Entradas

Existen diversas fuentes de información que son relevantes para el proceso de la Administración de

Niveles de Servicio. Estas incluyen:

Información del negocio: De la estrategia del negocios, planes, y planes financieros e información de la organización sobre sus requerimientos actuales y futuros

Análisis del Impacto al Negocio: Suministra información acerca del impacto, prioridad, riesgo y número de usuarios asociados a cada servicio

Requerimientos del negocio: Detalles de cualquier requerimiento del negocio acordado, nuevo o modificado

Las estrategias, políticas y restricciones de la Estrategia del Servicio

El Portafolio de Servicios y el Catálogo de Servicios

Información sobre los cambios del proceso de la Administración de Cambios

CMS: Contiene información sobre las relaciones entre los servicios del negocio, los servicios de soporte y la tecnología

Retroalimentación, quejas y halagos de los clientes y usuarios

Otra información: Incluye asesoría, información y datos del resto de los procesos (por ejemplo, Administración de Incidentes, Administración de la Capacidad y Administración de la Disponibilidad), junto con los SLA, SLR, y OLA existentes y reportes anteriores dci servicio sobre la calidad del servicio entregado.

Salidas

Las salidas de la Administración de Niveles de Servicio deben incluir:

Reportes del servicio: Proporcionan detalles de los niveles del servicio alcanzados en relación con los objetivos estipulados en los SLA

Plan de Mejora del Servicio (SIP): Un programa o plan general de acciones de mejora prioritarias, que abarca todos los servicios y todos los procesos, junto con los impactos y riesgos asociados

El Plan de Calidad del Servicio: Documenta y planifica la mejora general de la calidad del servicio

Plantillas de documentos: Plantillas estándar de documentos, formatos y contenido de los SLA, SLR y OLA, alineados con las normas corporativas

Acuerdo de Nivel de Servicio (SLA): Un conjunto de objetivos y responsabilidades que se debe documentar y acordar dentro de un SLA para cada servicio operacional

Requerimientos de Nivel de Servicio (SLR): Un conjunto de objetivos y responsabilidades que se debe documentar y acordar dentro de un SLR para cada servicio nuevo o modificado propuesto

Acuerdo de Nivel Operacional (OLA): Un conjunto de objetivos y responsabilidades que se debe documentar y acordar dentro de un OLA para cada equipo de soporte interno

Reportes sobre OLAs y contratos de soporte, minutas y acciones de las reuniones de revisión del Servicio: Todas las reuniones se deben programar de forma regular, así mismo se deben planificar las agendas, y registrar y avanzar Sus análisis y acciones

Minutas de la reunión de revisión del SLA y revisión del alcance del servicio: Resume las acciones acordadas y revisiones de los SLA y el alcances del servicio

Contratos revisados: Los cambios a los SLA o SLR nuevos pueden requerir la modificación de los contratos de soporte existentes, o la negociación y el acuerdo de contratos nuevos


87 | P á g i n a

ADMINISTRACION DE PROVEEDORES


88 | P á g i n a

Administrar proveedores y los servicios que suministran, proporcionar una perfecta calidad del servicio

de TI al negocio, al asegurar que se obtiene valor por el dinero. El proceso de la Administración de

Proveedores asegura que los proveedores y los servicios que suministran se administran de tal manera

que respaldan los objetivos del servicio de TI y las expectativas del negocio. El objetivo es crear

conciencia del contexto del negocio de trabajar con socios y proveedores, y cuál es la mejor forma de

dirigir este trabajo hacia la obtención del beneficio del negocio para la organización.


89 | P á g i n a

Idealmente, la Base de Datos de Proveedores y Contratos (SCD) debe formar un elemento integrado de un Sistema de Administración de Configuraciones (CMS) o Sistema de Administración de Conocimientos de Servicio (SKMS) completos, al registrar todos los detalles del proveedor y del contrato, junto con los detalles del tipo de servicio o producto que proporciona cada proveedor y el resto de la información y relaciones con otros CI asociados. Los servicios que proporcionan los proveedores también formarán una parte clave del Portafolio de Servicios y del Catálogo de Servicios. La relación entre los servicios de soporte y los servicios de TI y de negocio que soportan es clave para proporcionar servicios de TI de calidad.


90 | P á g i n a

ADMINISTRACION DE LA SEGURIDAD DE LA

INFORMACION


91 | P á g i n a


92 | P á g i n a


93 | P á g i n a

Marco de seguridad

El proceso y marco de la Administración de la Seguridad de la Información generalmente consistirán de:

Una Política de Seguridad de la Información y políticas de seguridad específicas que abordan cada aspecto de la estrategia, controles y reglamentos

Un Sistema de Administración de la Seguridad de la Información (ISMS), que contiene las normas, los procedimientos de Administración y las líneas directrices que respaldan las políticas de seguridad de la información

Una estrategia extensa de seguridad, estrechamente vinculada con los objetivos, estrategias y planes del negocio

Una estructura organizativa de seguridad efectiva

Un conjunto de controles de seguridad para respaldar la política La mitigación de riesgos de seguridad

Procesos de monitoreo para asegurar la conformidad y proporcionar retroalimentación sobre la efectividad

Estrategia y plan de comunicación para seguridad

Estrategia y plan de capacitación y conciencia

Política de Seguridad de la Información

La Política de Seguridad de la Información debe contar con el pleno respaldo de la alta gerencia

ejecutiva de TI e, idealmente, con el apoyo y compromiso de la alta gerencia ejecutiva.

Sistema de Administración de la Seguridad de la Información (ISMS)

El marco proporciona la base para el desarrollo de un programa rentable de seguridad de la información

que respalda los objetivos del negocio. Los cinco elementos dentro de este marco son: Controlar,

planificar, implementar, evaluar y mantener.


94 | P á g i n a

ADMINISTRACION DE LA DISPONIBLIDAD


95 | P á g i n a


96 | P á g i n a


97 | P á g i n a

El tiempo acordado de servicio se documenta en el Acuerdo de Nivel de

Servicio (SLA)

El tiempo inactivo se calcula al ir anotando los tiempos de interrupción que provienen de los registros de

Incidentes y de las interrupciones provocadas por los Cambios, ya sea que estén documentadas o no. No

incluye ningún acuerdo para las interrupciones provocadas por los cambios acordados ni las ventanas de

mantenimiento programadas.

El tiempo activo se calcula al restar el tiempo inactivo del tiempo acordado de servicio.

Para obtener un porcentaje se debe dividir el tiempo activo entre el tiempo acordado de servicio y

multiplicar este resultado por 100.

Ejemplo

Tiempo acordado de servicio: 24 horas al día, 7 días a la semana = 168 para la semana - Menos 4 horas para una ventana acordada de servicio Menos 4 horas para los tiempos inactivos debido a un cambio acordado o programado

El total ahora es de 160 horas del tiempo acordado de servicio para la semana Tiempo inactivo provocado por Incidentes 2 horas Tiempo inactivo provocado por cambios no planificados y no documentados =2 horas Total = 4 horas de tiempo inactivo para la semana Tiempo activo = Tiempo acordado de servicio — tiempo inactivo Tiempo activo = 160—4 = 156 horas Disponibilidad = Tiempo activo dividido entre el tiempo acordado de servicio. Posteriormente, se debe Multiplicar el resultado por 100 Disponibilidad = (156 / 160) * 100 =97.5%


98 | P á g i n a


99 | P á g i n a

Actividades Reactivas: Monitoreo, medición, análisis y administración de todos los eventos, Incidentes y

Problemas relacionados con la no disponibilidad

Actividades Proactivas: Planificación, diseño y mejora de la disponibilidad.

Disponibilidad de Servicio: Disponibilidad o no disponibilidad a nivel de servicio y el impacto, o impacto

potencial, de la disponibilidad del componente en los servicios.

Disponibilidad de Componente: Disponibilidad y no disponibilidad a nivel de componente.

Confiabilidad: Medida del tiempo que puede realizar su función un servicio, componente o CI sin

interrupciones.

Capacidad de Mantenimiento: Medida de qué tan rápido y con cuánta efectividad se puede restaurar

un servicio, componente o CI a la normalidad después de un fallo.

Capacidad de Servicio: Habilidad de un tercero para cumplir los términos de su contrato en cuanto a la

disponibilidad, confiabilidad y capacidad de mantenimiento.

Diseño para una Función Vital de Negocio:

Alta Disponibilidad: Minimiza o cubre los efectos del fallo de un componente de TI ante los usuarios de un servicio

Tolerancia a Fallas: Habilidad de un servicio, componente o CI para operar correctamente después del fallo de una parte de un componente

Operación Continua: Un enfoque o diseño para eliminar los tiempos inactivos planificados de un servicio de TI, los componentes individuales pueden no estar disponibles pero el servicio sigue estando disponible

Disponibilidad Continua: Un enfoque o diseño para conseguir una disponibilidad del 100% — El servicio de TI no tiene tiempos inactivos planificados o no planificados


100 | P á g i n a

ADMINISTRACION DE LA CAPACIDAD

El propósito de la Administración de la Capacidad es proporcionar un punto de enfoque y

Administración para todos los asuntos relacionados con la capacidad y el rendimiento, que se relacionan

tanto con los servicios como con los recursos.


101 | P á g i n a

Producir y mantener un Plan de Capacidad adecuado y actualizado que refleja las necesidades actuales y futuras del negocio

Proporcionar asesoría y guía al resto de las áreas del negocio y del área de TI sobre todos los asuntos relacionados con la capacidad y el rendimiento

Asegurar que los logros de rendimiento del servicio cumplen o exceden todos los objetivos de rendimiento acordados, al administrar el rendimiento y la capacidad tanto de los servicios como de los recursos

Ayudar con el diagnóstico y la resolución de los Incidentes y Problemas relacionados con el rendimiento y la capacidad

Evaluar el impacto de todos los cambios en el Plan de Capacidad, así como en el rendimiento y la capacidad de todos los servicios y recursos

Asegurar la implementación de medidas proactivas para mejorar el rendimiento de los servicios siempre que se pueda justificar su costo


102 | P á g i n a


103 | P á g i n a

Conceptos Básicos de la Administración de la Capacidad

Equilibrio de los costos contra los recursos necesarios La necesidad de asegurar que la capacidad de

procesamiento que se adquiere tiene un costo justificable en términos de las necesidades del negocio, y

la necesidad de utilizar esos recursos de la forma más eficiente.

Equilibrio del suministro contra la demanda La necesidad de asegurar que el suministro disponible de

potencia de procesamiento de TI coincide con las demandas del negocio, tanto ahora como en el futuro.

También puede ser necesario manejar o influir en la demanda de un recurso particular.

Plan de Capacidad Una de las actividades clave de la Administración de la Capacidad es la producción de

un plan que documenta tanto el uso de los recursos como el rendimiento de los servicios actuales.

También prospecta los requerimientos futurosde1os recursos de TI nuevos que se necesitan para

respaldar las actividades anticipadas del negocio. El Plan de Capacidad se debe publicar por lo menos

cada año (junto con un plan de inversión de capital propuesto), y posteriormente actualizar con

regularidad (trimestralmente) para dar cuenta de los cambios del negocio y de la tecnología.

Administración de la Capacidad del Negocio Este subproceso traduce las necesidades y los planes del

negocio en requerimientos para el servicio y la infraestructura de TI, al asegurar que los requerimientos

futuros de servicios de TI del negocio se cuantifican, diseñan, planifican e implementa de manera

oportuna.

Administración de la Capacidad del Servicio El enfoque de este subproceso es la Administración, control

y predicción del rendimiento y capacidad de principio a fin del uso y las cargas de trabajo de los servicios

de TI de producción y operacionales. El Acuerdo de Nivel de Servicio (SLA) y los Requerimientos de Nivel

de de Servicio (SLR) son monitoreados y medidos para identificar los asuntos relacionados con la

capacidad. Los umbrales automatizados son útiles para ayudar a administrar los servicios. Las alertas del

umbral, cuando se diseñan correctamente, proporcionan un plazo suficiente a la Administración técnica

y de operaciones para que lleve a cabo los ajustes y evite un Incidente relacionado con la capacidad.

Administración de la Capacidad de Componente El enfoque de este subproceso es la Administración,

control y predicción del rendimiento, uso y capacidad de los componentes individuales de tecnología del

área de TI. El enfoque específico consiste en el monitoreo y la Administración de los componentes

individuales junto con los requerimientos del servicio.


104 | P á g i n a

ADMINISTRACION DE LA CONTINUIDAD DE LOS

SERVICIOS DE TI


105 | P á g i n a


106 | P á g i n a

Objetivos

Mantener el conjunto de Planes de Continuidad de Servicios de TIy planes de recuperación de TI que soportan los Planes de Continuidad de Negocio (BCP) generales de la organización

Llevar a cabo, de manera regular, ejercicios de Análisis del Impacto de Negocio (BIA) para asegurar que todos los planes de continuidad se mantienen en línea con los impactos y requisitos de negocio en constante cambio

Realizar una evaluación de riesgos y ejercicios de administración regulares en coordinación con, el negocio así como los procesos de Administración de la Disponibilidad y Administración de la Seguridad, que administra los servicios de TI dentro de un nivel acordado de riesgos de negocio

Proporcionar asesoría y guía al resto de las áreas de negocio y al área de TI sobre los asuntos relacionados con la continuidad y recuperación

Asegurar la instauración de los mecanismos de continuidad y recuperación adecuados para cumplir o exceder los objetivos acordados de continuidad de negocio

Evaluar el impacto de todos los cambios en los Planes de Continuidad de Servicios de TI y planes de recuperación del área de TI

Asegurar la implementación de medidas proactivas para mejorar la disponibilidad de los servicios siempre que sea justificable su costo

Negociar y acordar los contratos necesarios con los proveedores para el aprovisionamiento de la capacidad de recuperación necesaria con la finalidad de soportar todos los planes de continuidad junto con el proceso de Administración de Proveedores


107 | P á g i n a


108 | P á g i n a

Enfoque del ciclo de vida

La ITSCM es un proceso cíclico a través del ciclo de vida que asegura que una vez que se desarrollan los

planes de continuidad y recuperación del servicio éstos se mantienen alineados con los Planes de

Continuidad del Negocio (BCPs) y las prioridades del negocio.

Iniciación y requerimientos

Las etapas de iniciación y requerimientos son principalmente actividades de la BCM. La ITSCM sólo se

debe involucrar en estas etapas para respaldar las actividades de la BCM y para comprender la relación

entre los procesos del negocio y los impactos que provocan en éstos la pérdida del servicio de TI. Como

resultado de estas actividades iniciales del BIA y los Análisis del Riesgo, la BCM debe producir una

Estrategia de la Continuidad del Negocio, y la primera tarea real de la ITSCM es producir una estrategia

de la ITSCM que soporte la estrategia de la BCM y sus necesidades.

Planes de Continuidad del Negocio (BCP)

La Estrategia de la Continuidad del Negocio se debe concentrar principalmente en los procesos del

negocio y los problemas asociados (por ejemplo: Continuidad de los procesos del negocio, continuidad

del personal, continuidad de los edificios). Una vez que se produce la Estrategia de la Continuidad del

Negocio, y se determina el rol que los servicios de TI deben proporcionar dentro de la estrategia, se

puede producir una estrategia de la ITSCM que respalda y habilita la Estrategia de la Continuidad del

Negocio. Esto asegura que se puedan tomar decisiones rentables, que consideran todos los ‘recursos’

que entregarán un proceso del negocio. Las fallas al llevar a cabo esto suelen impulsar opciones de

ITSCM que son más rápidas, más complicadas y costosas que las que realmente se necesitan.

Análisis del Impacto al Negocio (BIA) & funciones críticas del negocio

Los BIA son la actividad que identifica las Funciones Vitales del Negocio (VBF) y sus dependencias. Estas

dependencias pueden incluir proveedores, personas, otros procesos del negocio, servicios de TI,

etcétera. Los BIÁ definen los requerimientos de recuperación para los Servicios de TI. Estos

requerimientos incluyen los objetivos del tiempo de recuperación, objetivos del punto de recuperación y

objetivos mínimos del Nivel de Servicio para cada Servicio de TI.

Retos de la contratación externa

Esta situación puede ser incluso más complicada en situaciones de contratación externa donde un

proceso de la ITSCM dentro de un proveedor de servicios externo u organización de contratación

externa tiene que cumplir las necesidades no sólo de los procesos y estrategias de la BCM del cliente,

sino también los procesos y las estrategias de la BCM de la propia organización de contratación externa.

Estas necesidades pueden estar en conflicto entre ellas, o pueden estar en conflicto con las necesidades

de la BCM de alguno de los clientes de la organización de contratación externa.


109 | P á g i n a

TRANSICION DEL SERVICIO


110 | P á g i n a


111 | P á g i n a

Metas de la Transición del Servicio

Planificar y administrar la capacidad y los recursos que se requieren para empaquetar, crear,

probar e implementar una liberación en producción y establecer el servicio que se especifica en

los requerimientos del cliente y la parte involucrada.

Proporcionar un marco consistente y riguroso para la evaluación de la capacidad (capability) del

servicio y el perfil de riesgo antes de la liberación o implementación de un servicio nuevo o

modificado.

Establecer y mantener la integridad de todos los activos y configuraciones de servicio

identificado conforme evolucionan a lo largo de la etapa Transición del Servicio.

Proporcionar buenos conocimientos e información sobre calidad de manera que la

Administración de Cambios, Liberación e Implementación pueda acelerar una toma efectiva de

decisiones acerca de la promoción de una liberación a través de los ambientes de prueba y hacia

producción.

Proporcionar mecanismos de creación e instalación eficientes y repetibles que se puedan utilizar

para implementar liberaciones en los ambientes de prueba y producción, y reconstruir en caso

de que se requiera restaurar el servicio.

Asegurar que el servicio se puede administrar, operar y soportar de acuerdo con los

requerimientos y las restricciones especificados en el Diseño del Servicio.


112 | P á g i n a

Planificar y administrar los recursos para establecer con éxito un Servicio nuevo o modificado en

la producción dentro del costo, la calidad y los plazos estimados.

Asegurar que existe un impacto mínimo imprevisto sobre los Servicios de producción,

operaciones y la Organización de soporte.

Incrementar la satisfacción del cliente, usuario y personal de Gestión de Servicios con las

prácticas de transición del Servicio, incluyendo la implementación del Servicio nuevo o

modificado, comunicaciones, documentación de versiones, capacitación y transferencia de

conocimientos.

Incrementar el uso adecuado de los Servicios, así como de las aplicaciones y soluciones de

tecnología subyacentes.

Proporcionar planes claros y completos que permiten que el cliente y el negocio cambien los

proyectos para alinear sus actividades con los planes de transición del servicio.


113 | P á g i n a

La Transición del Servicio también agrega valor al negocio mejorar:

La calidad para adaptarse con rapidez a los requisitos nuevos y desarrollos del mercado (ventaja competitiva)

La Gestión de transiciones de fusiones, separaciones, adquisiciones y transferencia de Servicios.

El índice de éxito de los Cambios y las Versiones para el negocio.

Las predicciones de los niveles de Servicio y las garantías para los Servicios nuevos y modificado.

La confianza en el grado de cumplimiento de los requerimientos de negocio y gobierno durante el cambio.

La variación de lo real en comparación con los calculados y los planes/presupuestos de recursos aprobados.

La productividad del negocio y el personal del Cliente debido a una mejor planificación y un mejor uso de los Servicios nuevos y modificados.

La cancelación de o los cambios oportunos en los contratos de mantenimiento tanto para el

hardware como para el software cuando los componentes son desechados o puestos fuera de

servicio.

La compresión del nivel de riesgo durante y después del cambio; por ejemplo, la interrupción,

trastorno o re-trabajo del Servicio.


114 | P á g i n a

Las siglas DIKW significan Datos, Información, Conocimientos y Sabiduría

Los datos son un conjunto de hechos discretos acerca de los eventos.

La información proviene de proporcionar contexto a los datos.

Los conocimientos están compuestos de las experiencias, ideas, información, valores y juicios

tácitos de las personas

La sabiduría proporciona el discernimiento final del material y proviene de contar con la ciencia

de la aplicación y contextual para proporcionar un juicio lógico solidó y común.

ANALISIS DE SERVICIO E INSTRUMENTACION

El Análisis de Servicio es útil para modelar los componentes de la infraestructura y servicios de soporte existentes para los servicios del negocio de nivel más alto. Este modelo se construye sobre las dependencias y no sobre la topología: causalidad en lugar de correlación. Posteriormente, los eventos de infraestructura se ligan a los procesos correspondientes del negocio. Hasta aquí pueden llegar las tecnologías modernas en una jerarquía DIKW. Es bien sabido que ninguna tecnología para computadora puede proporcionar sabiduría. Se necesitan personas para proporcionar un entendimiento evaluado, así como para responder y percibir las preguntas “¿Porqué?”.


115 | P á g i n a


116 | P á g i n a


117 | P á g i n a


118 | P á g i n a

Conceptos Básicos de la SACM Elemento de Configuración (CI) Un Elemento de Configuración es un activo, componente de servicio u otro elemento que está, o que estará, bajo el control de la Administración de Configuraciones. Los tipos de CI incluyen:

CIs del Ciclo de Vida del Servicio (por ejemplo: Casos de negocio; planes de la administración de servicios: planes del ciclo de vida del servicio; Paquetes de Diseño del Servicio (SDP); planes de liberación y cambios; planes de pruebas)

CIs del Servicio (por ejemplo: Activos de la capacidad (capability) del servicio: administración, organización, procesos, conocimientos, personas; activos de los recursos del servicio: capital financiero, sistemas, aplicaciones, información, datos, infraestructura e instalaciones, personas; modelos de servicio; paquetes de servicio; paquete de liberación; criterios de aceptación de servicio).

CIs de la Organización (por ejemplo: Estrategia del negocio; políticas; requerimientos regulatorios o establecidos por la ley; productos compartidos por más de un grupo; CIs Internos: activos tangibles o intangibles que se requieren para entregar y mantener el servicio y la infraestructura.

CIs Externos (por ejemplo: Requerimientos y acuerdos de los clientes externos; liberaciones de proveedores o subcontratistas y servicios externos)

Modelo Lógico La Administración de Configuraciones entrega el modelo lógico requerido de los servicios, activos e infraestructura al registrar las relaciones entre los Elementos de Configuración. Relaciones Una relación es un vínculo entre dos Elementos de Configuración que identifica una dependencia o conexión entre ellos, por ejemplo, las aplicaciones pueden estar vinculadas a los servidores en los que se ejecutan; los Servicios de TI tienen diversos vínculos a todos los CI que contribuyen a ellos. Base de Datos de Administración de Configuraciones (CMDB) Una base de datos que se utiliza para administrar los Registro de Configuraciones a lo largo de su Ciclo de Vida. La CMDB registra los atributos de todos los CI, y las relaciones con otros CI. Una CMDB también puede contener otra información vinculada al CI, por ejemplo registro de incidentes, problemas o cambios. La Administración de Configuración brinda mantenimiento a la CMDB y es utilizada por todos los procesos de la Administración de Servicio de TI. Sistema de Administración de Configuración (CMS) El CMS conserva toda la información de los CI dentro del alcance designado. El CMS mantiene las relaciones entre todos los componentes del servicio y cualquier registro/documentación relacionado de administración de servicio. Por lo general, el CMS también conservara datos acerca de los empleados, proveedores, ubicaciones y unidades de negocio, clientes y usuarios.


119 | P á g i n a

Biblioteca Definitiva de Medias (DML) La configuración exacta de la MDL se define durante las actividades de planificación. La definición incluye:

Medios, ubicación física, hardware y software que se utilizaran, en caso de que se mantenga en línea. Algunas herramientas de soporte de Gestión de Configuraciones incorporan bibliotecas de software, las cuales pueden ser consideradas una parte lógica de la DML.

Convenciones de nombre para las áreas de almacenamiento de archivos y medio físicos.

Entornos soportados, por ejemplo entornos de prueba y reales.

Arreglos de seguridad para el envió de Cambios y la emisión de software, además de procedimientos de respaldo y recuperación.

El alcance de la DML es por ejemplo el código fuente, objeto de creaciones controladas y documentación asociada.

Periodo de retención

Planes de capacidad para la DML y procedimientos para el monitoreo del crecimiento en el tamaño.

Procedimientos de auditoria

Procedimientos para asegurar que la DML está protegida contra Cambios erróneos o no autorizados (por ejemplo: criterios de entrada y salida para los elementos)


120 | P á g i n a

El sistema de Administración de Configuración (CMS) conserva toda la información de los CIs dentro del

alcance designado. Algunos de estos elementos, por ejemplo: software, documento, por ejemplo, un CI

de Ser vicio incluirá los detalles, tales como el proveedor, costo fecha de adquisición y fecha de

renovación para las licencias y contratos de mantenimientos, así como la documentación relacionada,

tal como los SLAs y contratos de soporte.

El CMS también se utiliza para una extensa variedad de propósitos, por ejemplo los datos de activos

que se conservan en un CMS (datos de la CMDB) se pueden poner a disposición de los sistemas externos

de Gestión de Activos financieros para realizar un proceso específico de gestión de activos que se

informa fuera de la Gestión de Configuraciones. El CMS mantiene las relaciones entre todos los

componente del Servicio y cualquier documentación de incidentes, Problemas, Errores Conocidos,

Cambios y Liberaciones relaciones, y también puede contener datos corporativos acerca de los

empleados, proveedores, ubicaciones y unidades de negocio, clientes y usuarios.


121 | P á g i n a


122 | P á g i n a

Las actualizaciones para la información de los activos y configuraciones se disparan por medio de

solicitudes de cambio, órdenes de compra, adquisiciones y solicitudes de servicio. Por su propia

naturaleza, al ser el único deposito virtual de datos e información sobre las configuraciones para la

Administración de Servicio de TI, la SACM brinda soporte y funciona junto con el resto de los procesos y

actividades hasta cierto punto. Algunas de las interfaces más notables son:

Administración de Cambios-identificación del impacto de los cambios propuestos

Administración Financiera – captura de información financiera clave tal como costos, métodos

de depreciación, dueño y usuario (para presupuestario y asignación de costos), costos de

mantenimiento y reparación

ITSCM-conciencia de los activos de los que dependen los servicios, control de repuestos y

software clave

Incidente/problema/error-suministro y mantenimiento de información clave de diagnóstico;

mantenimiento y aprovisionamiento de datos al centro de servicio al usuario

Administración de la disponibilidad-detención de puntos de falla


123 | P á g i n a

ADMINISTRACION DE CAMBIOS


124 | P á g i n a


125 | P á g i n a

Conceptos Básicos de la Administración de Cambios

Cambio de Servicio

Un cambio de Servicio es un cambio que se realiza a un servicio existente, o la introducción de un

servicio nuevo. Es la adición, modificación o eliminación de un servicio o componente de servicio

autorizado, planificado o soportado y su documentación asociada.

Cambio Normal

Cualquier cambio que sigue el proceso de cambio normal se considera un cambio normal. Los

cambios normales pueden incluir cambios a los servicios, el portafolio de servicios, proyectos de

mejora del servicio, etcétera.

Cambio Estándar

Es un cambio previamente aprobado y de bajo riesgo, relativamente común y que sigue un

procedimiento o instrucción de trabajo; por ejemplo, el aprovisionamiento de equipo estándar

a un empleado nuevo. Se registran y se les da seguimiento utilizado un mecanismo diferente, tal

como una Solicitud de Servicio.

Cambio de Emergencia

Un cambio de emergencia es un cambio que se debe realizar tan pronto como es posible; por

ejemplo, para resolver un incidente mayor o implementar una revisión de seguridad. El proceso

de la Administración de Cambios normalmente tendrá un procedimiento especifico para el

manejo de los Cambios de Emergencia.

Modelo de cambio

Una forma repetible de manejar una categoría particular de cambio. Un modelo de cambio define los

pasos predefinidos específicos que se seguirán para un cambio de esta categoría. Los modelos de

cambio pueden ser muy sencillos, sin necesidad de aprobación (por ejemplo: La liberación de un

software importante).

Flujos de trabajo de los modelos del proceso de cambio

Las organizaciones encontraran muy útil predefinir los modelos del proceso de cambio, y aplicarlos a los

cambios apropiados cuando ocurren. Un modelo de proceso es una manera de predefinir los pasos que

se deben realizar para manejar un proceso (en este caso, un proceso para el manejo de un tipo de

cambio particular) de la manera acorada. Posteriormente se pueden utilizar herramientas de soporte

para administrar el proceso requerido. Esto asegurara que dichos cambios se manejen en la ruta

predefinida y conforme a las escalas de tiempo predefinidas.


126 | P á g i n a

Los cambios que requieren un manejo especializado se podrían tratar de esta forma, tales como los

cambios de emergencia que pueden tener una autorización diferente, y documentarse en retrospectiva.

El modelo del proceso de cambios incluye:

Los pasos que se deben realizar para manejar el cambio, incluyendo el mensaje de problemas y

eventos inesperados.

El orden cronológico en el que se deben realizar estos pasos, definiendo cualquier dependencia o co-procesamiento

Responsabilidades; quien debe hacer qué

Escalas de tiempo y umbrales para la conclusión de las acciones

Procedimientos de estalación; a quien se debe contactar y cuando

Estos modelos generalmente son información para las herramientas de soporte de la Administración de

Cambios en uso y posteriormente las herramientas automatizan el manejo, administración, generación

de soportes y estalación del proceso.

TIPO DE CAMBIO CON EJEMPLOSPROCEDIMIENTOS DE

TRABAJO DOCUMENTADOSSS SD ST SO CSI

Solicitud de cambio al portafolio de servicios

Elemento de línea nuevo del portafolio

Al alcance predicho, caso de negocio, línea base

Canal de entrada de servicios

Al alcance predicho, caso de negocio, línea base

A los atributos existentes o planificados del

servicio

Cambio de proyecto que genera un impacto

sobre el Diseno del servicio, por ejemplo,

garantias pronosticadas

Mejora del Servicio

Propuesta de Cambio del proyecto

Cambio del Negocio

Sin Impacto en el Servicio o Linea base del diseno

Mejora del Servicio

Solicitud de acceso a usuarioProcedimiento de acceso

de usuario1

Actividad Operacional

"Tunning" (dentro de las

especificaciones/restricciones)

Reinicio del Hardware en caso de falla si no

genera un impacto sobre otros servicios

Mantenimiento Planificado

1

Procedimiento local (con

frecuencia previamente

autorizada)

1

Administración de cambios

del servicio1 1

1 1Administración de cambios

del servicio1 1 1

Administración de cambios

del servicio1


127 | P á g i n a

Planificación de la remediación

No se debe aprobar cambio alguno sin haber abordado explícitamente la pregunta que hacer en caso de

que no tenga éxito. Lo ideal será contar con un plan para revertirlo, el cual restablecerá la organización a

su situación inicial, con frecuencia mediante la recarga de un conjunto de CIs de la línea de base, en

especial software y datos. Sin embargo, no todos los cambios se pueden revertir, en cuyo caso se

requiere un enfoque alternativo para la remediación.

Comité Asesor de Cambios

El Comité Asesor de Cambio (cab) es una entidad que existe para respaldar la autorización de los

cambios y ayudar a la Administración de Cambios en la evaluación y determinación de las prioridades

de los cambios.

Comité Asesor de Cambios de Emergencia

Algunas veces se requieren cambios de emergencia y se deben diseñar y probar cuidadosamente

Algunas veces se requieren cambios de emergencia podría ser mayor al incidente original. Los cambios

de emergencia pueden documentar algunos detalles en retrospectiva. El número de cambio de

emergencia propuesto se debe mantener a un mínimo absoluto, debido a que estos generalmente son

más perjudiciales y propensos a fallas.

Autorización de cambios de emergencia

Existirán niveles de autorización definidos para un cambio de emergencia, y los niveles de la autoridad

delegada se deben documentar y comprender con claridad. En una emergencia podría no ser posible

convocar una reunión del CAB completo. En caso de que se requiera la aprobación del CAB, la otorgara

el CAB de Emergencia (ECAB).


128 | P á g i n a


129 | P á g i n a

Siete Rs (por sus siglas en ingles)

¿Quién LEVANTÓ el Cambio?

Es importante contar con información sobre quien representa el Cambio en caso de que se requiera una

aclaración posterior acerca de la necesidad del Cambio. También hay ejemplos en los que la prioridad

de un Cambio se puede ver afectado por el cargo o departamento que origino el Cambio.

¿Cuál es la RAZON del Cambio?

Es importante conocer por qué se está solicitando el Cambio. Algunos ejemplos pueden incluir.

Calidad

Rendimiento

Cumplimiento

Mantenimiento

Defectos

¿Cuál es el RESULTADO que se requiere del Cambio? ¿Qué beneficio pueden esperar del Cambio ya sea la Organización, el departamento, el personal de soporte o el cliente?

¿Cuál son los RIESGOS involucrados en el Cambio Todos los Cambios tienen un riesgo que puede variar en cualquier lugar, desde el retraso del procesamiento hasta la imposibilidad ara toda la Organización de proporcionar un Servicio a sus correspondientes en los tiempos y la ejecución del Cambio.

¿Qué RECURSOS se requieren para entregar el Cambio? En todo Cambio existen diversos recursos que necesitan tomarse en cuenta, tales como:

Humanos

Financieros

Externos

Internos

¿Quién es RESPONSABLE de la creación, prueba e implementación del Cambio?

Es importante identificar todas las partes involucradas en la realización de un Cambio, y que los

gestores estén informados respecto al rol que desempeñara su gente en la implementación del Cambio.

¿Cuál es la RELACIÓN entre este Cambio y otros Cambios?

No se puede exagerar la complicación de la interacción, las dependencias y relaciones de los Cambios,

no es poco común tener múltiples Cambios paralelos que pueden afectarse entre sí en cualquier punto

en sus rutas críticas. Es imprescindible comprender esto y adaptarse a ellos para evitar un incremento

en las interrupciones y los fallos no planificados en un proceso de Cambios.


130 | P á g i n a


131 | P á g i n a

Actividades

Registrar la RFC

El Cambio se levanta mediante la solicitud del iniciador: una persona o un grupo.

Revisar la RFC

Gestión de Cambios debe considerar brevemente cada solicitud y filtro con base en:

Razones de Aceptación Razones de Rechazo

Practico Impráctico

RFC nueva Repite las RFC anteriores:

Ya fue aceptado

Sigue bajo consideración

Rechazado

Información completa Entregas incompletas

Descripción Inadecuada

Sin la Aprobación presupuestal necesaria

Información Precisa

Cuenta con la aprobación presupuestal necesaria

Evaluar el Cambio El asunto de los riesgos para el negocio de cualquier Cambio se debe tomar en

cuenta antes de la autorización de cualquier Cambio.

Autorizar el Cambio Muchas Organizaciones utiliza una matriz sencilla para clasificar los riesgos. La

autorización formal de todo los Cambios se obtiene de una autoridad de Cambios que puede estar

representada por un rol. Persona o grupo de personas.

Planificar las Actualizaciones La planificación cuidadosa de los Cambios asegurara que no existe

ambigüedad alguna acerca de que tareas se incluyen en el proceso de Gestión de Cambios, que tareas se

incluyen en otros procesos y la manera en que los procesos crean una interfaz con cualquier proveedor

o proyecto que estén aprovisionando un Cambio o Versión.

Coordinar la Implementación del Cambio Las RFC autorizadas deben ser transferidas a los grupos

técnicos relevantes para la creación de los Cambios.

Una buena práctica es hacer esto de una manera formal a la que se pueda dar seguimiento.

Revisar y Cerrar el Registro Una vez concluida el Cambio:

Se informan los resultado

Se lleva a cabo la evolución

En caso de haber sido exitoso, se cierran el registro

En caso de haber fracasado, se cierra el registro


132 | P á g i n a


133 | P á g i n a

Relaciones de la Administración de Cambios

Las entradas de la Administración de Cambios incluyen:

Políticas y estrategias para el Cambio y la liberación

Solicitud de Cambio

Propuesta de cambio

Planes-cambios, transición, liberación, implementación, prueba, evaluación y remediación

Programa de cambios actuales y PSO

Activos actuales o elementos de configuración (por ejemplo: Línea base, paquete de servicio,

paquete de liberación)

Línea de base de la configuración de acuerdo con los planeado

Resultados de las pruebas, reporte de las pruebas y reporte de evaluación

Las salidas de los procesos serán:

RFCs rechazadas

RFCs aprobadas

Cambios a los servicios, servicio o infraestructura que resultan de las RFC aprobadas

Activos o elementos de configuración nuevos, modificados o desechados (por ejemplo: Línea

base, paquete de servicio, paquete de liberación)

Programa de cambios

Revisión de la Interrupción Prevista del Servicio (PSO)

Planes de cambio autorizados

Decisiones y acciones de cambio

Documentos y registros de cambio

Reportes de la Administración de Cambios

Los procesos de la Administración de Servicio pueden requerir cambios y mejorar. Muchos también

estarán involucrados en la evaluación del impacto e implementación de los cambios de servicio, como

se analiza a continuación:

Administración de Activos de Servicio y de Configuración

El Sistema de Administración de Configuraciones proporciona acceso confiable, rápido y fácil a

información precisa acerca de la configuración para permitir que las partes involucradas y el personal

evalúen el impacto de los cambios propuestos y rastreen el flujo de trabajo de los cambios. Esta

información permite que se liberen las versiones correctas de los componentes de activos y servicios a

la parte adecuada o en el ambiente correcto. A medida que se implementan los cambios, se actualiza la

información de la Administración de Configuraciones. El CMS también puede identificar los CI/activos

relacionados que se verán afectados por el cambio, pero que no se incluyeron en la solicitud original, o

de hecho los CIs/activos similares que aprovecharan un cambio similar.


134 | P á g i n a

Administración de Problemas

La administración de problemas es otro proceso clave ya que los cambios se requieren con frecuencia

para implementar soluciones temporales y para corregir errores conocidos. La administración de

problemas es una de las mayores fuentes de RFCs y también con frecuencia uno de los principales

contribuyentes al análisis del CAB.

Continuación de Servicios de TI

La continuación de servicios de TI tiene muchos procedimientos y los planes se deben actualizar a través

de la administración de cambios para asegurar que son precios, están actualizados y que las partes

involucradas están enteradas de los cambios.

Administración de la seguridad

La administración de la seguridad funciona junto con la administración de cambios ya que los cambios

requeridos por seguridad se realizaran a través de los procesos de la administración de cambios y la

seguridad será un contribuyente clave para el análisis del CAM sobre muchos servicios. Todos los

cambios importantes se evaluaran para determinar su impacto potencial sobre el plan de seguridad.

Administración de la capacidad y la demanda

La administración de la capacidad y la demanda es un aspecto fundamental de la administración de

cambios. La administración inadecuada de la demanda es una fuente de costos y riesgos para los

proveedores de servicios debido a que siempre existe un nivel de incertidumbre asociada con la

demanda de servicios. La administración de la capacidad desempeñada un rol importante de la

evaluación de los cambios propuestos, no solo de los cambios individuales sino del impacto total de los

cambios sobre la capacidad del servicio. Los cambios que surgen de la Administración de la Capacidad,

incluyendo aquellos que se estipulan en el plan de capacidad, iniciaran como RFCs a través del proceso

de cambios.


135 | P á g i n a

ADMINISTRACION DE LIBERACIONES E

IMPLEMENTACION

El objetivo de la Administración de Liberación e Implementación es implementar liberaciones en

producción y establecer el uso efectivos del servicio para entregar valor al cliente y poder entregarlo a

operaciones del servicio.

La administración de liberación e implementación se enfoca en crear, probar y entregar la capacidad

(capability) para proporcionar los servicios especificados por diseño de servicios y que cumplirían los

requerimientos de las partes involucradas, y entregarán los objetivos deliberados.


136 | P á g i n a

Además de los objetivos de la página anterior, los siguientes objetivos también son importantes para el

proceso de la administración de Liberación e implementación.

Asegurar la transferencia de conocimientos para permitir que los clientes y usuarios optimicen su uso del servicio para respaldar las actividades de su negocio.

Asegurar que las habilidades y los conocimientos son transferidos al personal de operaciones y soporte.

Asegurar un impacto no predicho mínimo sobre los servicios de producción, las operaciones y la organización de soporte.

Asegurar que los clientes, usuarios y el personal de administración de servicios están satisfecho con las prácticas y los resultados de la transición del servicio.


137 | P á g i n a

Política de Liberación

Incluye las definiciones de unidades de liberación, roles, responsabilidades, horarios, frecuencia y otros

requerimientos acerca del manejo de las liberaciones.

Unidad de liberación

La parte del servicio o la infraestructura que generalmente se libera al mismo tiempo de acuerdo con la

política de liberación de una organización. La unidad puede variar, dependiendo del tipo o elemento de

software y hardware.


138 | P á g i n a

ADMINISTRACION DEL CONOCIMIENTO


139 | P á g i n a


140 | P á g i n a

Específicamente dentro de la administración de servicios de TI, la administración de conocimientos se

concentrara en el sistema de administración de conocimientos del servicio que se ocupa de, como su

nombre lo indica, los conocimientos. Para soportar estos conocimientos habrá una cantidad

considerable de datos, que se mantendrá en una almacén central lógico o en un sistema de

administración de configuraciones (CMS) y en una base de datos de administración de configuraciones

(CMDB), sin embargo, claramente el SKMS es un concepto más extenso que abarca una base mucho más

amplia de conocimientos, por ejemplo:

La experiencia del personal

Los registros de los asuntos periféricos (por ejemplo: clima, números y conducta del usuario,

cifras de rendimiento de la organización)

Los requerimientos, las habilidades y expectativas de los proveedores y socios

Los niveles de habilidad típicos y anticipados del usuario


141 | P á g i n a

OPERACION DEL SERVICIO


142 | P á g i n a

La operación le servicio es una fase clave del ciclo de vida de la gestión de servicio de TI. Los procesos

bien planificados e implementados no serán aprovechados si la operación diaria de dichos procesos no

se realiza, controla, y administran correctamente. Tampoco será posible mejorar el servicio si las

actividades diarias para monitorear el rendimiento, evaluar las métricas y recopilar los datos no se

realizan de manera sistemática durante la operación del servicio.


143 | P á g i n a


144 | P á g i n a

Valor al Negocio de la Operación del Servicio

En tanto que todas las etapas del ciclo de vida del servicio de ITIL se concentran en suministrar valor al

negocio, desde el punto de vista del cliente, la Operación del Servicio se encuentra donde se ve el valor

real.

Estrategia del Servicio: se planifica y modela el valor del servicio.

Diseño del Servicio: se diseña el servicio para cumplir los requerimientos del negocio y

proporcionar el valor esperado al cliente.

Transición del servicio: se valida el valor del servicio contra el valor predicho.

Mejora continúa del servicio: Se identifican las métricas para optimización.

La Operación del Servicio se encuentra donde se ejecutan y miden estos planes, diseños y

optimizaciones.

La Operación del Servicio también busca entregar valor al abordar los siguientes retos a través del uso

de procesos, métricas y funciones efectivos:

Una vez que se diseña y prueba el servicio, se espera que se ejecute dentro de los objetivos del

presupuesto y Retorno sobre la Inversión antes establecidas en el ciclo de vida.

Durante la fase operacional es difícil obtener financiamiento para corregir los defectos de

diseño o requerimientos no previstos, ya que esto no formaba parte de la propuesta de valor

original.

Es difícil obtener financiamiento adicional para herramientas o acciones (incluyendo

capacitación) que tienen como objetivo mejorar la eficiencia de la Operación del Servicio.

Una vez que el servicio se pone en operación durante cierto tiempo, se convierte en parte de

la línea base de lo que el negocio espera de los Servicios TI.


145 | P á g i n a

Evento

Un evento se puede definir como cualquier ocurrencia detectable o discernible que es de importancia

para la administración de la infraestructura de TI o la entrega del servicio de TI. Por lo general, los

eventos son notificaciones creadas por un servicio de TI, elemento de configuración (CI) o herramienta

de monitoreo.

En algunos casos, un evento puede conducir al registro de un incidente.

La Operación del Servicio efectiva depende del conocimiento del estado de la infraestructura y la

detección de cualquier desviación de la operación normal o esperada. Esto se obtiene a través de

buenos sistemas de monitoreo y control, que se basan en dos tipos de herramientas:

Herramientas de monitoreo activo que sondean los CI clave para determinar su estado y

disponibilidad. Cualquier excepción generará una alerta que se debe comunicar a la herramienta

o equipo adecuados para que emprendan una acción.

Herramientas de monitoreo pasivo que detectan y correlacionan alertas o comunicaciones

generadas por los CI.


146 | P á g i n a

Los Eventos pueden requerir que el personal de Operaciones de TI emprenda acciones, y éstas por lo

general se realizan a través de una alerta, o notificación, creada por cualquier servicio de TI, elemento

de configuración de monitoreo.

El propósito de una alerta es asegurar que se notificó a la persona con las habilidades apropiadas para

atender el evento. Con frecuencia, las alertas son creadas y administradas por herramientas de

administración de Sistemas, y son administradas por el Proceso de la administración de Eventos. Una

alerta también puede conducir al registro de un incidente.


147 | P á g i n a

Los incidentes pueden surgir de cualquier parte – reportados por los usuarios (por lo regular, a través de

una llamada telefónica el Centro de Servicio al Usuario), por el personal técnico, por los proveedores o

por herramientas de monitoreo de eventos.


148 | P á g i n a

Prioridad es una categoría que se utiliza para identificar la importancia relativa e algo, tal como un

incidente, Solicitud de Servicio, Problema o Cambio.

La Prioridad deriva del impacto y Urgencia asociados, y se utiliza para identificar el tiempo que se

requiere para emprender las acciones ; por ejemplo, un SLA puede estipular que los Incidentes de

Prioridad 2 se deben resolver dentro de las 12 horas siguiente.

Impacto es una medida del efecto de un incidente, solicitud de servicio, Problema o Cambio en los

procesos del negocio. El Impacto con frecuencia se caracteriza como una interrupción y se basa en cómo

se verán afectados los niveles de servicio.

Urgencia es la velocidad relativa que requiere el negocio para la resolución de un incidente, Solicitud de

Servicio, Problema o Cambio. La urgencia con frecuencia es la medida del tiempo que transcurre para

que haya un impacto considerable sobre el negocio. Por ejemplo, un incidente de alto impacto puede

tener una Urgencia baja si el impacto va a afectar al negocio hasta el final del año fiscal.


149 | P á g i n a

Las solicitudes de Servicio son análogas a las “ordenes de trabajo” y difieren de los incidentes en que las

Solicitudes de Servicio no se deben a un retraso o interrupción inesperada en el servicio, sino en algo

que es necesario realizar para que el usuario obtenga el valor competo del servicio en cuestión.


150 | P á g i n a

Los registro de incidentes se asocian (vinculan) a los registros de problemas para indicar el impacto de

un problema y ayudar a determinar su prioridad.


151 | P á g i n a

Una solución Temporal reduce o elimina el impacto de un Incidente o Problema para el cual aún no hay

disponible una resolución completa – una manera temporal de resolver las dificultades. Por ejemplo, un

archivo de configuración puede tener que editarse de forma manual para la operación adecuada de un

componente del servicio. Aunque sigue siendo importante identificar el caso del archivo incorrecto y

eliminarlo, la solución temporal permite reanudar la operación normal del servicio.

Las Soluciones Temporales se caracterizan por pasos documentos que abordan los síntomas conocidos,

los pasos que se pueden utilizar nuevamente conforme es necesario para reducir o eliminar el impacto

de un incidente o problema. En el caso de un problema, el registro de problemas incluirá la solución

temporal mejor conocida hasta que se pueda implementar una resolución completa. Las soluciones

temporales para incidentes que no tienen registros de problemas asociados se documentan en el

registro de incidentes.


152 | P á g i n a

La documentación de los Errores Conocidos facilita un diagnóstico y resolución más rápidos

(restauración del servicio) en caso de que ocurran más incidentes.


153 | P á g i n a

La Base de Datos de Errores Conocidos (KEDB) es una base de datos de todos los Registros de Errores

Conocidos y forma parte del sistema de Administración de Conocimientos del Servicio (SKMS).

Es imprescindible que todos los datos que se ingresan a la base de datos se puedan recuperar rápido y

con presión.

Administración de Problemas crea la KEDB y se utiliza durante las fases de diagnósticos de Incidentes y

Problemas para tratar de acelerar el proceso de resolución.


154 | P á g i n a

ADMINISTRACION DE EVENTOS

La Gestión de Eventos proporciona mecanismos para la detección temprana de Incidentes. En muchos

casos se puede detectar el Incidente y asignarlo al grupo adecuado para que lleve a cabo las acciones

antes de que ocurra cualquier interrupción real del Servicio.

La Gestión de Eventos permite monitorear por excepción algunos tipos de actividades automatizadas, y

de esta manera elimina la necesidad de contar con un monitoreo en tiempo real costoso e intensivo de

los recursos, al tiempo que reduce el tiempo inactivo.

Cuando se integra con otros procesos de Gestión de Servicio (por ejemplo, Gestión de la Disponibilidad o

Capacidad), la Gestión de Eventos puede indicar cambios de estado o excepciones que permiten que la

persona o equipo adecuado realicen una respuesta temprana, mejorando así el rendimiento del

proceso. A su vez, esto permite que el negocio se beneficie de una Gestión de Servicio más efectiva y

más eficiente en general.


155 | P á g i n a


156 | P á g i n a

Conceptos Básicos de la Administración de Eventos

Existen diversos tipos de eventos. Un evento puede significar:

Operación regular:

Notificación de que se completó una carga de trabajo programada

Un usuario inició sesión para una aplicación

Un correo electrónico llegó a su destinatario deliberado

Operación inusual, pero no excepcional – generalmente una indicación de que la situación puede

requerir un monitoreo más cercano:

El uso de memoria de un servidor alcana el 5% de su rendimiento más alto aceptable

El tiempo de conclusión de una transacción es de 10% más largo de lo normal

Una excepción:

Un usuario intenta inicial sesión en una aplicación con la contraseña incorrecta

El CPU de un dispositivo se encuentra por arriba de la tasa de uso aceptable

El análisis de una PC revela la institución de software no autorizado

Existen dos aspectos importantes acerca de los ejemplos anteriores:

¿Qué constituye exactamente una operación normal versus inusual, versus una excepción?

Cada uno depende del envío y recepción de algún tipo de mensaje

En el Diseño del Servicio se debe planificar y determinar qué Eventos puede y debe utilizarse en la

operación de un servicio, y cómo se manifestarán. La Operación del Servicio se concentra en la captura

de y respuesta a los eventos que se estipularon en el Diseño del Servicio.


157 | P á g i n a

ADMINISTRACION DE INCIDENTES


158 | P á g i n a

Meta de la Administración de Incidente

La meta principal del proceso de la Administración de Incidentes es restaurar la operación normal del

servicio tan pronto como es posible y minimizar el impacto adverso sobre las operaciones del negocio,

asegurando de esta manera que se mantienen los niveles óptimos posibles de calidad y disponibilidad

del servicio. La operación normal del servicio aquí se define como una operación del servicio dentro de

los límites del Acuerdo de Nivel de Servicio (SLA).

Alcance

La Administración de Indícienles incluye cualquier Evento que interrumpe, o que puede interrumpir un

servicio. Esto incluye los Eventos que comunican directamente los usuarios, ya sea a través del Centro

de Servicio al Usuario o a través de una interfaz de las herramientas de Administración de Eventos a las

herramientas de Administración de Incidentes.

El personal técnico también puede reportar y/o registrar incidentes. Si, por ejemplo, observa algo

inadecuado con algún componente del Hardware o la red, puede reportar o registrar un Incidente, y

referirlo al Centro de Servicio al Usuario. Sin embargo, esto no significa que tos los Eventos sin

Incidentes. Muchas clases de Eventos no están relacionadas con las interrupciones del todo, sino que

son indicadores de una operación normal o son simplemente informativos.

Nota: Aunque tanto los Incidentes como las Solicitudes de Servicio se reportan al Centro e Servicio al

Usuario, esto no significa que sean los mismo. Las Solicitudes de Servicio no representan una

interrupción del servicio acordado, sino una manera de satisfacer las necesidades del cliente, y pueden

estar resolviendo un objetivo acordado en el Acuerdo de Nivel DE Servicio. El proceso del cumplimiento

de Solicitudes atiende las Solicitudes de Servicio.


159 | P á g i n a


160 | P á g i n a

Conceptos Básicos de la Administración de Incidentes

Escalas de Tiempo Los incidentes progresaran a través de las diversas etapas de su vida. La conciencia y

el monitoreo del tiempo que se invierta en estas etapas es imprescindible para cumplir los niveles de

servicio acordados para los clientes. Se deben acordar escalas de tiempo para todas las etapas del

manejo de incidentes con base en la respuesta general al incidente y los objetivos de resolución

específicos en los Acuerdos de nivel de Servicio.

Modelo de Incidencia Muchos Incidentes no son nuevos, estos involucran la atención de algo que ya

sucedió antes y que bien podría suceder de nuevo. Un modelo de Incidencia son los pasos previamente

definidos que se deben realizar para manejar un tipo particular de Incidencia de una forma acordada.

Por ejemplo, se utilizaran diferentes modelos para los Incidentes relacionados con el rendimiento,

seguridad, infraestructura de la red, proveedores, etcétera.

El modelo de Incidencia incluirá:

Los pasos que se deben realizar para manejar el Incidente

El orden cronológico de los pasos que se van a realizar, definiendo las dependencias o el co-

procesamiento

Responsabilidad –quien debe hacer que escalas de tiempo y umbrales para la conclusión de las

acciones

Procedimientos de escalación - a quien se debe contactar y cuando

Cualquier actividad necesaria para la conservación de la evidencia

Incidencia Mayores Un Incidente mayor es la categoría más alta de impacto de un Incidente y resulta

en una interrupción importante para el negocio. Para estos Incidentes “mayores” se debe utilizar un

procedimiento independiente, con escalas de tiempo más cortas y una mayor Urgencia. Se debe acordar

una definición de lo que constituye un Incidente Mayor, y lo ideal es que este correlacionado con en el

esquema general de prioridad de los Incidentes, de manera que se pueda asegurar que se manejara

apropiadamente a través del procedimiento de Incidentes mayores.

Nota: Algunas veces las personas confunden los Incidentes Mayores con los Problemas. Un Incidente,

mayor o de otro tipo, siempre seguirá siendo un Incidente, nunca se convierte en un problema. Un

Problema es la causa de un Incidente o más, u ¡siempre seguirá siendo una entidad independiente! Sin

esta distinción entre los Incidentes y Problemas, y si se mantienen los registros por separados, existe el

peligro de que:

Los Incidente se cerraran demasiado temprano en el ciclo de soporte general y no se

emprenderán acciones para prevenir su repetición, o

Los Incidentes se mantendrán abiertos para que se pueda realizar el análisis de la causa raíz y

visiblemente se perderá cuando el servicio del usuario realmente se restaure. Es posible que no

se cumplan los objetivos del SLA aunque el servicio haya sido restaurado dentro de las

expectativas de los usuarios.


161 | P á g i n a


162 | P á g i n a

Identificación del Incidente

la detección temprana es imprescindible, generalmente a través de eventos de los componentes calve del servicio

los Incidentes se deben resolver antes de que tengan un impacto sobre los usuarios Registros del Incidente

todos los Incidentes de deben de registrar completamente y deben incluir un sello con la fecha/hora, sin importar la fuente

se registra toda la información relevante

se mantiene un registro histórico completo, y lo utiliza el resto de los grupos de soporte Clasificación del Incidente

Asignación de la categoría de Incidente adecuada de manera que se registre el tipo exacto de la llamada

Afecta las métricas, generación de reportes y activación del modelo de incidente correcto Determinación de la Prioridad del Incidente

Acuerdo y asignación de una prioridad adecuada

Determina como manejan el incidente tanto las herramientas de soporte como el personal de soporte

Diagnóstico Inicial

Intento por descubrir todos los síntomas del Incidente y cómo resolverlo

Los guiones de diagnóstico y registros de Errores Conocidos permiten un diagnósticos temprano y preciso

Escalación del incidente

Escalación funcional: asignada un Incidente a otro grupo debido a la falta de conocimientos / pericia o un lapso en las escalas de tiempo acordadas

Escalación Jerárquica: La gerencia puede llevar a cabo acciones correctivas para los incidentes Mayores o es muy probable que el incidente no se resuelva a tiempo o satisfactoriamente

Investigación y Diagnostico

investigación y diagnóstico de lo que salió mal

se documentan por completo en el registro de Incidentes las actividades y los detalles de las acciones que se realizaron

Resolución y Recuperación

Aplicación y prueba de la resolución potencial

Variaran las acciones que se llevaron a cabo y las partes involucradas en las acciones de recuperación

Cierre del Incidente

El Centro de Servicio al Usuario debe revisar que se haya resuelto por completo el incidente y que los usuarios están satisfechos y dispuestos a aceptar que se puede cerrar el Incidente

Rastreo y Comunicaciones del Monitoreo de Propiedad

Independientemente de quien maneja el Incidente, la propiedad sigue siendo del Centro de Servicio al Usuario en todo momento, desde el inicio hasta el cierre. El Centro de Servicie al Usuario es responsable de monitorear y rastrear el progreso, mantener informados a los usuarios sobre el estado del incidente, así como de cerrar el incidente.


163 | P á g i n a


164 | P á g i n a

Relaciones de la Administración Incidente Los Incidentes se pueden desencadenar de muchas formas. La ruta más común es cuando un usuario

llama al Centro de Servicio al Usuario o completa una pantalla de registro de Incidentes en la Web; sin

embargo cada vez es más frecuente que los Incidentes se registren automáticamente a través de

herramientas de Administración de Eventos. El personal técnico puede observar las fallas potenciales y

levantar un incidente, Algunos Incidentes también pueden surgir al inicio de operaciones de los

proveedores, quienes pueden enviar algún tipo de notificación de una dificultar potencial o real que

requiere atención.

Las interfaces con la Administración de Incidentes incluyen:

Administración de Problemas: La administración de Incidentes forma parte del proceso general

del manejo de problemas en la organización. Los Incidentes con frecuencia son provocados por

problemas subyacentes, que se deben resolver para evitar que se repita el incidente

Administración de Configuraciones: proporciona los datos que se utilizan para identificar y

conocer el progreso de los Incidentes. Uno de los usos del CMS es identificar el equipo

defectuoso y evaluar el impacto de un Incidente. También se utiliza para identificar a los

usuarios afectado por los problemas potenciales. El CMS también contiene información acerca

de que categorías de incidente se deben asignar a cada grupo de soporte. A su vez, la

administración de Incidentes puede mantener el estado de grupo de soporte. A su vez, la

Administración de Incidentes puede mantener el estado de los CI defectuosos. También puede

ayudar a que la Administración de Configuraciones audite la infraestructura cuando se trabaja

en la resolución de un incidente

Administración de cambios: Cuando se requiera un cambio para implementar una Solución

Temporal o resolución será necesario registrarlo como un RFC y la Administración de Cambios se

encargará de su progreso. A su vez, la Administración de Incidentes puede detectar y resolver

los Incidentes que surgen partir de Cambios fallidos.

Administración de la Capacidad: La Administración de Incidentes proporciona una

desencadenador para el monitoreo del rendimiento donde parece que existe un problema de

rendimiento. La Administración de la Capacidad puede desarrollar Soluciones Temporales para

Incidentes

Administración de la Disponibilidad: Utilizará datos de la Administración de Incidentes para

determinar la disponibilidad de los servicios de TI y ver dónde se puede mejorar el ciclo de vida

del incidente.

SLM: La habilidad para resolver Incidentes en un tiempo especificado forma una parte clave de

la entrega de un nivel de servicio acordado. La administración de Incidentes permite que la SLM

defina repuestas medibles para las interrupciones del servicio. También proporciona reportes

que permiten que la SLM revise los SLA de forma objetiva y regular. En particular, la

Administración de Incidentes puede ayudar a definir dónde son más débiles los servicios, de

manera que la SLM puede definir acciones como parte del Plan de Mejora del Servicio (SIP). La

SLM define los niveles de servicio aceptables dentro de los cuales trabaja la Administración de

incidentes.


165 | P á g i n a

ADMINISTRACION DE SOLICITUDES


166 | P á g i n a

Objetivos del Cumplimiento de Solicitudes

El Cumplimiento de Solicitudes es el proceso de atender las solicitudes de servicio de los usuarios. Los

objetivos del proceso del Cumplimientos Solicitudes incluyen:

brindar un canal para que los usuarios soliciten y reciban servicios estándar para los que existe

un proceso previamente definido de aprobación y calificación.

Brindar información a los usuarios y clientes acerca de la disponibilidad de los servicios y el

procedimiento para obtenerlos.

Obtener y entregar los componentes de los servicios estándar solicitados (por ejemplo:

licencias y medidas de software).

El término “Solicitud de Servicio” se utiliza como una descripción genérica para los diversos tipos de

demanda que realizan los usuarios el departamento de TI. Muchas de éstas son realmente Cambios

pequeños, de bajo riesgo, que ocurren con frecuencia, de bajo costo, etcétera (por ejemplo: una

solicitud para cambiar una contraseña, una solicitud para instalar una aplicación de software adicional

en una estación de trabajo particular, una solicitud para reubicar algunos elementos del equipo del

escritorio), o tal vez sólo una pregunta para solicitar información pero su escala y su frecuente

naturaleza de bajo riesgo significan que se pueden manejar mejor un proceso individual, en lugar de que

ser permita que congestionen y obstruyan los procesos normales de la administración de Incidentes y

Cambios.


167 | P á g i n a


168 | P á g i n a

Modelo de Solicitud

Similares a los Incidentes, muchas Solicitudes de Servicio involucran el manejo de algo que ya sucedió

antes y que bien podría suceder de nuevo. Algunas Solicitudes de Servicio ocurrirán con frecuencia y

requerirán un manejo de una forma consistente para cumplir los niveles de servicio acordado. Para

ayudar con esto, muchas organizaciones desearan crear Modelos de Solicitud previamente definidos.

Un modelo de Solicitud es una manera de definir previamente los pasos que se deben realizar

para manejar un proceso (en este caso un proceso para atender un tipo de solicitud en

particular), de la manera acordada.

Cuando se establecen los Modelos de Solicitud, entonces se puede utilizar las herramientas de

soporte para administrarlos, lo que asegura que las Solicitudes de Servicio estándar se manejan

de una manera previamente definida y dentro de las escalas de tiempo previamente definidas.

El Modelo de Solicitud Incluirá:

Los pasos que se deben realizar para manejar la solicitud.

El orden cronológico de los pasos que se van a realizar, definiendo cualquier dependencia o co-

procesamiento.

Responsabilidad – quién debe hacer qué escalas de tiempo y umbrales para la conclusión de las

acciones.

Procedimientos de escalación - a quién se debe contactar y cuando



169 | P á g i n a

ADMINISTRACION DE PROBLEMAS


170 | P á g i n a

Objetivos de la Administración de Problemas

La Administración de Problemas es el responsable de la administración del Ciclo de Vida de todos los

problemas.

Los objetivos principales de la Administración de Problemas son:

Evitar que ocurren Problemas y los Incidentes resultantes

Eliminar los Incidentes que se repiten

Minimizar el impacto de los Incidentes que no se pueden evitar

La administración de Problemas incluye las actividades que se requieren para diagnosticar la causa raíz

de los Incidentes y determinar la resolución de estos problemas. También es responsable de asegurar

que se implemente la resolución a través de los procedimientos de control adecuados, en especial la

Administración de Cambios y la Administración Liberaciones.

Aunque la Administración de Incidente y Problemas son procesos independientes, éstos están

estrechamente relacionados y por lo general utilizaran las mismas herramientas, así mismo pueden

utilizar una clasificación y sistemas de codificación de impacto y prioridad similares. Esto asegurará una

comunicación efectiva al atender incidentes y problemas relacionados.


171 | P á g i n a


172 | P á g i n a

Modelo de Problema

Muchos Problemas serán únicos y requerirán un manejo individual, sin embargo cabe la posibilidad de

que algunos incidentes vuelvan a suceder debido a problemas aletargados o subyacentes (por ejemplo,

cuando se tomó la decisión de “vivir con” el problema, en lugar de seguir adelante con una resolución

permanente y costosa). Puede ser útil la creación de un Modelo de Problema para el manejo de esta

clase de problemas en el futuro. Esto es muy similar en concepto de la idea de los Modelos de Incidente

que ya se describió.

Un Modelo de Problema es una forma de definir previamente los pasos que se deben realizar

para manejar un tipo particular de problemas de una forma acordada.

Posteriormente se puede utilizar herramientas de soporte para administrar el proceso

requerido. Esto asegurará que los problemas estándar se manejan de una manera previamente

definida, y dentro de las escalas de tiempo previamente definidas.

El Modelo de Problema incluirá:

Los pasos que se deben realizar para manejar el Problema

El orden cronológico de los pasos que se va a realizar, definiendo cualquier dependencia o co –

procesamiento

Responsabilidades - quién debe hacer qué escalas de tiempo y umbrales para la conclusión de

las acciones

Procedimientos de escalación – a quién se debe contactar y cuándo



173 | P á g i n a


174 | P á g i n a

Detección del Problema

Sospecha o detección de una causa desconocida de uno o más Incidentes

Detección automatizada de fallas recurrentes en la infraestructura o aplicación

Notificación por parte del grupo de soporte intrno o externo acerca de la existencia de un

problema

Análisis de Incidentes como parte de una Administración de Problemas proactiva

Registro del Problema

Registro de todos los detalles relevantes del Problema de manera que exista un registro

histórico completo

Se coloca un sello con la fecha y hora para permitir un control y escalación adecuados

Clasificación del Problema

Se clasifican de la misma forma que los Incidentes (y se debe utilizar el mismo sistema de

codificación)

Permite trazar con facilidad la verdadera naturaleza del Problema en el futuro

Se puede obtener información gerencial importante

Determinación de la Prioridad

Se determina la prioridad de la misma forma (Impacto y Urgencia) y por las mismas razones que

los Incidentes

También se deben tomar en cuenta la frecuencia y el impacto de los Incidentes relacionados

Investigación y Diagnóstico

Se debe realizar una investigación para tratar de diagnosticar la causa raíz del problema

La velocidad y naturaleza de esta investigación variará dependiendo de la prioridad

Los recursos y pericia se deben aplicar con base en la prioridad Creación del Registro de Errores

Conocidos

Al completar el diagnóstico (en particular cuando se encontró una solución temporal), se debe

levantar un registro de Errores Conocidos, incluso si aún no existe una resolución permanente

Resolución del Problema

Lo ideal es que tan pronto como se encuentre la solución, se debe aplicar para resolver el

problema

Si se requiere algún cambio en la funcionalidad, se debe levantar una Solicitud de Cambio (RFC)

Cierre

El registro de problemas se debe cerrar formalmente cuando una resolución permanente tiene

éxito, así como cualquier registro de incidentes relacionados que sigan abiertos

Asegurarse de que se actualizó el registro para contener una descripción histórica completa de

todos los eventos

Revisión del Problema Mayor

Se realiza después de cada Problema Mayor cuando la memoria todavía está fresca

Aquello que se hizo correcta o incorrectamente

¿Qué se podría hacer mejor en el futuro?

Cómo evitar que suceda de nuevo

Identificar a cualquier tercero responsable y si es necesario realizar acciones de seguimiento


175 | P á g i n a


176 | P á g i n a

Entradas y Salidas de la Administración de Problemas Las Interfaces entre la Administración de Problemas y otros procesos incluyen lo siguiente:

Administración de Cambios: La Administración de Problemas asegura que todas las resoluciones o

soluciones temporales que requieren un cambio a un CI se envíen a través de la Administración de

Cambios mediante una RFC. La Administración de Cambios monitoreará el progreso de estos

cambios y mantendrá al tanto a la Administración de Problemas. La Administración de Problemas

también está involucrada en la rectificación de la situación provocada por los Cambios fallidos

Administración de Configuraciones: La Administración de Problemas utiliza el CMS para identificar

Cis defectuosos y también para determinar el impacto de los problemas y resoluciones. El CMS

también se puede utilizar para formar la base de la KEDB, y se puede conservar con o integrar a los

registros de problemas

La Administración de Liberación e Implementación es responsable de implementar la solución del

problema en el ambiente de producción. También ayuda a asegurar que los errores conocidos

asociados se transfieren de la Base de D4os de Errores Conocidos de desarrollo a la Base de Datos

de Errores Conocidos de pr6ducción. La Administración de Problemas ayudará a resolver los

problemas provocados por las fallas durante el proceso de liberación

La Administración de la Disponibilidad está involucrada en determinar cómo reducir el tiempo

inactivo e incrementar el tiempo activo. Como tal, mantiene una relación estrecha con la

Administración de Problemas, en especial con las áreas proactivas. Gran parte de la información

gerencial disponible en la Administración de Problemas se comunicará a la Administración de la

Disponibilidad

Administración de la Capacidad: Algunos problemas requerirán una investigación mediante los

equipos y las técnicas de la Administración de la Capacidad. La Administración de la Capacidad

también ayudará a evaluar las medidas proactivas. La Administración de Problemas proporciona

información gerencial sobre la calidad de las decisiones que se tomaron durante el proceso de la

Planificación de la Capacidad

Continuidad del Servicios de TI: La Administración de Problemas actúa como un punto de entrada

hacia la Administración de la Continuidad del Servicio de TI cuando no se resuelve un problema

importante antes de que comience a generar un impacto mayor sobre el negocio

Administración de Niveles de Servicio: La ocurrencia de incidentes y problemas afecta la entrega

del nivel de servicio medido por la SLM. La Administración de Problemas contribuye a las mejoras a

los niveles de servicio, y su información gerencial se utiliza como la base de algunos componentes de

las revisiones del SLA. La SLM también proporciona parámetros dentro de los cuales trabaja la

Administración de Problemas, tales como información acerca del impacto y el efecto sobre los

servicios de las resoluciones propuestas y medidas proactivas

Administración Financiera: Ayuda en la evaluación del impacto de las resoluciones propuestas o

soluciones temporales, así como en el Análisis de Valores de Daño. La Administración de Problemas

brinda información gerencial acerca del costo de la resolución y prevención de problemas, que se

utiliza como una entrada en los sistemas de presupuestación y contabilidad, así como en los cálculos

del Costo Total de Propiedad


177 | P á g i n a

ADMINISTRACION DE ACCESOS

La Administración de Accesos otorga el derecho para que los usuarios puedan utilizar un servicio o

grupo de servicios. Por lo tanto, consiste en la ejecución de políticas y acciones definidas en la

Administración de la Seguridad y de la Disponibilidad

La Administración de Accesos es el proceso de otorgar a los usuarios autorizados el derecho para utilizar

un servicio, al tiempo que se impide el acceso a los usuarios no autorizados. También se conoce como

Administración de Derechos o Administración de Identidad en diferentes organizaciones.


178 | P á g i n a


179 | P á g i n a

Conceptos Básicos

Acceso

Se refiere al nivel y grado de funcionalidad de un Servicio o datos que el usuario tiene derecho a

utilizar.

Identidad

Se refiere a la información del usuario que lo distingue como individuo y que verifica su estado

dentro de la Organización. Por definición, la Identidad de un usuario es exclusiva para ese

usuario.

Derechos - (también denominados privilegios)

Los derechos se refieren a los ajustes reales que le proporcionan acceso al usuario a un Servicio

o grupo de Servicios. Los derechos o niveles de acceso típicos incluyen lectura, escritura,

ejecución, cambio y eliminación.

Servicios o Grupos de Servicios

La mayoría de los usuarios no sólo utiliza un Servicio, y los usuarios que realizan un conjunto de

actividades similares utilizarán un conjunto de Servicios similares. En lugar de brindar acceso

para cada Servicio a cada usuario por separado, es más eficiente poder otorgar acceso al mismo

tiempo a cada usuario o grupo de usuarios al conjunto completo de Servicios al que tienen

derecho de utilizar.

Servicios de Directorio

Los Servicios de Directorio se refieren al tipo específico de herramienta que se utiliza para

gestionar el acceso y los derechos.


180 | P á g i n a

FUNCIONES EN LA OPERACIÓN DEL SERVICIO


181 | P á g i n a

La interacción e interdependencia de la Administración Técnica y la Administración de Aplicaciones con

la Administración de Operaciones proporciona un control adecuado de la infraestructura de operación,

de manera que todas las áreas pueden ser efectivas.

La Administración de Operaciones de TI es la que opera el funcionamiento diario de la infraestructura de

la que depende la garantía del servicio. Sin embargo, en muchas organizaciones las funciones de la

Administración Técnica y/o de Aplicaciones también son responsables de la operación diaria de un

subconjunto específico de la Infraestructura de TI. La diapositiva muestra que, aunque forma parte de

las funciones de la Administración Técnica y/o de Aplicaciones, el personal que realiza estas actividades

diarias lógicamente forma parte de la función de la Administración de Operaciones de TI.


182 | P á g i n a

CENTRO DE SERVICIO AL USUARIO


183 | P á g i n a

Rol del Centro de Servicio al Usuario

El Centro de Servicio al Usuario es una función que es fundamental para el concepto entero de la

Administración de Servicios. Sirve como el Punto Unico de Contacto (SPOC) entre los usuarios y los

clientes con respecto a la entrega y el uso de los servicios. El Centro de Servicio al Usuario se concentra

en el cliente y se compone de personas con habilidades interpersonales, consciencia del negocio y una

perspectiva orientada al servicio (con base en el valor).

Como el profesional principal del proceso de la Administración de Incidentes, el Centro de Servicio al

Usuario es dueño de todos los Incidentes independientemente de dónde y cómo se identificaron y

registraron.

Los beneficios de la función del Centro de Servicio al Usuario incluyen:

Servicio al cliente, percepción y satisfacción mejorados

Mayor accesibilidad a través de un punto único de contacto, comunicación e información

Mejor calidad y rotación más rápida de las solicitudes del cliente y usuario

Trabajo en equipo y comunicación mejorados

Enfoque mejorado y proactivo en cuanto al aprovisionamiento del servicio

Impacto negativo al negocio reducido

Infraestructura y control mejor administrados

Mejor uso de los recursos de Soporte de TI

Mayor productividad del personal del negocio

Información gerencial mejorada para el respaldo de las decisiones


184 | P á g i n a


185 | P á g i n a

Objetivos del Centro de Servicio al Usuario

Restaurar el servicio tan rápido como es posible, utilizando el proceso de la Administración de

Incidentes

Cumplir la solicitud de servicio, utilizando el proceso del Cumplimiento de Solicitudes

Ayudar a que los usuarios sean productivos y obtengan el mayor valor de los servicios suministrados

Impulsar y mejorar el servicio para y en nombre del negocio

Las responsabilidades específicas del Centro de Servicio al Usuario incluyen:

Recepción de llamadas, cliente de primera línea y enlace del usuario

Registro de todos los detalles relevantes de los Incidentes/Solicitudes de Servicio, asignación de los

códigos de clasificación y prioridad

Suministro de investigación y diagnóstico de primera línea y resolución de aquellos Incidentes!

Solicitudes de Servicio que le sean posibles

Monitoreo y seguimiento de todos los Incidentes y Solicitudes de Servicio

Escalación de los Incidentes/Solicitudes de Servicio que no pueda resolver dentro de las escalas de

tiempo acordadas

Cierre de todos los Incidentes, Solicitudes de Servicio y otras llamadas resueltos

Realización de la devolución de llamadas /encuestas del cliente/satisfacción según lo acordado

Suministro de recomendaciones para la mejora del servicio e identificación de las necesidades de

capacitación del cliente

Contribución a la identificación de los Incidentes o Solicitudes de Servicio que se repiten

Actualización del Sistema de Administración de Configuraciones (CMS) bajo la dirección y

aprobación de la Administración de Configuraciones, si así se acordó

El Centro de Servicio al Usuario facilita la integración entre los procesos del negocio y la infraestructura

de la Administración de Servicios. No sólo maneja Incidentes, Solicitudes de Servicio y preguntas, sino

también proporciona una interfaz (SPOC) para otras actividades relacionadas con el uso de servicios

tales como solicitudes de Cambio del cliente, contratos de mantenimiento, licencias de software,

Administración de la Seguridad de la Información, Administración de Niveles de Servicio, Administración

de la Capacidad, Administración de la Disponibilidad, etcétera.


186 | P á g i n a


187 | P á g i n a

Tipos de Centro de Servicio al Usuario

Centro Local de Servicio al Usuario Un Centro de Servicio al Usuario que se localiza en el mismo sitio o

en las mismas instalaciones que la comunidad de usuarios a la que brinda sus servicios.

Ayuda a la comunicación y brinda una presencia claramente visible

Con frecuencia puede ser ineficiente y costoso en cuanto a los recursos

Requiere consistencia en los procesos y herramientas de toda la empresa

Las razones para considerar el uso de un Centro Local de Servicio al Usuario incluyen:

Uso horario, idioma, diferencias culturales o políticas

Grupos especializados de usuarios o estado VTP/crítico de los usuarios

La existencia de servicios personalizados/especializados requiere conocimientos especializados

Centro Centralizado de Servicio al Usuario Un Çentro de Servicio al Usuario localizado en una ubicación

fisíca centralizada para todas las ubicaciones o sitios de los usuarios.

Permite contar con un personal general más reducido para atender un mayor volumen de

llamadas

Puede conducir a niveles más altos de habilidad a través de una mayor familiarización con las

ocurrencias frecuentes

Nota: Aún podría ser necesario mantener alguna forma de presencia local para manejar las necesidades

de soporte físico, pero esta clase de personal se puede controlar e implementar de forma central.

Centro Virtual de Servicio al Usuario Un Centro de Servicio al Usuario que para las personas que llaman

parece estar en una sola ubicación, pero en realidad se encuentra geográfica o estructuralmente

disperso.

Puede estar situado y se puede tener acceso a él en cualquier parte del mundo

Depende sumamente de la tecnología, en particular de Internet, además de las herramientas de

soporte corporativas para coordinarse y comunicarse

Permite la opción de trabajar desde el hogar, oficinas remotas, grupos de soporte secundarios,

contratación extranjera o contratación externa para cumplir la demanda del usuarios

Requiere consistencia y uniformidad en la calidad del servicio y los términos culturales

Siguiendo al Sol Las organizaciones globales o internacionales pueden combinar dos de sus Centros de

Servicio al Usuario o más que están geográficamente dispersos para brindar un servicio que sigue al sol

las 24 horas a un costo relativamente bajo.

Ningún Centro de Servicio al Usuario tiene que trabajar más de un turno

Depende de procesos comunes, herramientas e información compartida

Se deben resolver las diferencias culturales

Requiere una escalación bien controlada y se necesitan procesos de entrega


188 | P á g i n a

ADMINISTRACION TECNICA


189 | P á g i n a

El Rol Dual de la Administración Técnica

Al desempeñar estos dos roles, la Administración Técnica puede asegurar que la organización cuenta

con acceso al tipo y nivel adecuados de recursos humanos para administrar la tecnología y, de esta

manera cumplir los objetivos del negocio. La definición de los requerimientos de estos roles comienza

en la etapa Estrategia del Servicio, se expande en Diseño del Servicio, se válida en Transición del

Servicio, y se perfecciona en Mejora Continua del Servicio.

Administración Técnica:

Desempeña un rol importante en el diseño, prueba, liberación y mejora de los servicios de TI.

Proporciona una guía a Operaciones de TI acerca de cómo lograr de la mejor forma la

administración operacional continua de la tecnología:

o Se lleva a cabo parcialmente durante el proceso del Diseño del Servicio

o Es un elemento de la comunicación diaria con la Administración de Operaciones de TI ya

que ellos buscan lograr la estabilidad y el rendimiento óptimo

Asegura un equilibrio entre el nivel de habilidad, uso y costo de estos recursos:

o Considera el uso de contratistas para las habilidades que se necesitan pocas veces

o Utiliza “grupos” centralizados de especialistas para proporcionar una economía de

escala a la organización y minimizar la necesidad de incluir contratistas en la plantilla

o Identifica habilidades especializadas entre los recursos de TI de manera que se puedan

aplicar conforme surjan necesidades específicas, además de sus labores regulares no

especializadas


190 | P á g i n a


191 | P á g i n a

La Gestión Técnica proporciona habilidades técnicas detalladas y los recursos necesarios para soportar la

operación continua de la infraestructura de Ti. La Gestión Técnica también desempeña un rol

importante en el diseño, prueba, publicación y mejora de los Servicios de TI. En las Organizaciones

pequeñas, se puede administrar esta experiencia desde un solo departamento, pero las Organizaciones

más grandes suelen estar divididas en diversos departamentos técnicamente especializados.

En muchas Organizaciones, los departamentos de Gestión Técnica también son responsables de la

operación diaria de un subconjunto de la Infraestructura de Ti. Esta diapositiva muestra que, aunque

forma parte de un departamento de Gestión Técnica, el personal que realiza estas actividades forma

lógicamente parte de la función de la Gestión de Operaciones de TI.


192 | P á g i n a

ADMINISTRACION DE APLICACIONES

La Administración de Aplicaciones es para las aplicaciones lo que la administración técnica es para la

infraestructura de TI. Como en el caso de la Administración Técnica, la Administración de Aplicaciones

debe equilibrar la necesidad de habilidades técnicas específicas con la demanda de dichas habilidades.

La Administración de Aplicaciones se asegura de que se cuenta con el nivel y grado de habilidades y

conocimientos indicados para respaldar el desarrollo, implementación, operación y mejora adecuados

del ambiente de la aplicación con la finalidad de satisfacer las necesidades continuas del negocio.

La Administración de Aplicaciones es responsable de la administración de las aplicaciones a lo largo del

ciclo de vida y desempeña un rol en todas las aplicaciones, ya sea adquiridas o desarrolladas

internamente. Una de las decisiones clave a la que contribuyen es la decisión de comprar una aplicación

o construirla.

La Administración de Aplicaciones también desempeña un rol importante en el diseño, prueba y mejora

de aplicaciones que forman parte de los servicios de TI. Como tal, puede estar involucrada en los

proyectos de desarrollo, pero generalmente es diferente de los equipos de Desarrollo de Aplicaciones.


193 | P á g i n a

Para alcanzar los objetivos:

Las aplicaciones deben ser confiables, rentables y estar bien diseñadas

La utilidad está alineada con el negocio

Las habilidades técnicas adecuadas mantienen un óptimo rendimiento operacional de la

aplicación óptimo

Las habilidades de la aplicación se implementan de manera eficiente para resolver los Incidentes

y Problemas de la aplicación


194 | P á g i n a

Generalmente, la Administración de Aplicaciones se divide en departamentos con base en el portafolio

de aplicaciones de la organización, lo que hace posible una especialización más sencilla y un soporte más

enfocado.

En muchas organizaciones los departamentos de Administración de Aplicaciones cuentan con personal

que se encarga de las operaciones diarias de esas aplicaciones. Al igual que con la Administración

Técnica, este personal lógicamente forma parte de la función de la Administración de Operaciones de TI.


195 | P á g i n a

ADMINISTRACION DE OPERACIONES DE TI

La habilidad del negocio para cumplir sus objetivos y permanecer competitivo depende de los resultados

y la confiabilidad de la operación diaria de TI. La Administración de Operaciones de TI es responsable de

ejecutar las actividades y normas de rendimiento que se definen durante el Diseño del Servicio y se

prueban durante la Transición del Servicio. En este sentido, el rol principal de Operaciones de TI es

mantener el status quo.

A medida que cambian la demanda y los requerimientos del negocio, la Administración de Operaciones

de TI debe ser capaz de mantener su paso, con frecuencia desafiando el status quo y la Administración

de Operaciones de TI debe ser capaz de adaptarse continuamente a los requerimientos y demanda del

negocio.

La estabilidad de la infraestructura de TI y la consistencia de los Servicios de TI es una de las principales

inquietudes de Operaciones de TI. Incluso las mejoras operacionales tienen como objetivo encontrar

maneras más sencillas y mejores de realizar la misma tarea.

La Administración de Operaciones de TI consiste de dos roles: Control de Operaciones de TI y

Administración de Instalaciones.


196 | P á g i n a


197 | P á g i n a


198 | P á g i n a

La Administración de Accesos maneja el ambiente físico de las instalaciones del Centro de datos o

respaldo


199 | P á g i n a

La interacción e interdependencia de la Gestión Técnica y la Gestión de Aplicaciones con la Gestión de

Operaciones proporciona un control adecuado de la Infraestructura de operación, de manera que todas

las Áreas pueden ser efectivas. La Gestión de Operaciones es la que opera el funcionamiento diario de la

Infraestructura de la que depende la garantía del Servicio.


200 | P á g i n a


201 | P á g i n a

Comunicación en la Operación del Servicio

Un principio importante es que todas las comunicaciones deben tener un propósito o resultar en una

acción. No se debe comunicar información alguna a menos que haya una audiencia clara. Además, la

audiencia debe participar activamente en la determinación de la necesidad de dicha comunicación y lo

que se hará con la información.

Por favor observe que no existe un medio o medios definitivos de comunicación, ni una ubicación ni

frecuencia fijas. En algunas organizaciones, la comunicación tiene lugar en las juntas. Otras

organizaciones prefieren utilizar el correo electrónico o la comunicación inherente de sus herramientas

de Administración de Servicios. Aunque el contenido común de la comunicación es bastante consistente

una vez que se definen los procesos, los medios de comunicación disponibles cambian constantemente:

Correo electrónico, a clientes tradicionales a dispositivos móviles

Mensajes de texto

Mensajería Instantánea (IM)

VOIP basada en computadoras

Teleconferencias

Reuniones virtuales con capacidades para compartir documentos

Es imprescindible que todas las partes involucradas comprendan cómo utilizar con efectividad los

medios de comunicación seleccionados. Además, los medios de comunicación deben asegurar que

sirven para cualquier objetivo de comunicación. Por ejemplo, la necesidad de una comunicación segura

podría eliminar la posibilidad de la IM o los mensajes de texto, en tanto que la necesidad de una mayor

calidad podría eliminar la VOIP.

Por lo tanto debe haber una política en torno a la comunicación dentro de cada equipo o departamento

y para cada proceso. Aunque ésta debe ser formal, la política no debe ser molesta ni compleja. Por

ejemplo, un administrador puede solicitar que todas las comunicaciones sobre los cambios se envíen

por correo electrónico. Siempre y cuando esto se especifique en los Procedimientos Estándar de

Operación (sin importar la forma en que existen) del departamento, no habrá necesidad de crear

políticas individuales para ello.


202 | P á g i n a

MEJORA CONTINUA DEL SERVICIO


203 | P á g i n a


204 | P á g i n a


205 | P á g i n a

El modelo de CSI

El proceso de mejora se puede resumir en seis pasos:

1. Adopción de la visión al comprender los objetivos del negocio de alto nivel. La visión debe alinear el

negocio y las estrategias de TI.

2. Evaluación de la situación actual para obtener una fotografía precisa e imparcial del lugar donde se

encuentra la Organización en este momento. Esta evaluación de la línea base es un análisis de la

posición actual en términos del negocio, la organización, las personas, el proceso y la tecnología.

3. Comprensión y acuerdo de las prioridades de mejora con base en un desarrollo más profundo de los

principios definidos en la visión. La visión completa se puede encontrar a años de distancia pero este

paso proporciona metas específicas y un marco de tiempo manejable.

4. Detalle del plan de la CSI para conseguir un aprovisionamiento del Servicio de mayor calidad al

implementar procesos de Administración de Servicios de TI y mediante el desarrollo e implementación

de los procesos de Administración de Servicios de TI.

5. Revisión de que se cuenta con mediciones y métricas para asegurar que se consiguieron los hitos, alto

cumplimiento de los procesos, y que los objetivos y las prioridades del negocio se cumplieron de

acuerdo al Nivel de Servicio.

6. Por último, el proceso debe asegurar que el momento para la mejora de la calidad se mantiene al

asegurar que los cambios se integran en la Organización.


206 | P á g i n a


207 | P á g i n a

Uso del Modelo PDCA para Controlar y Administrar la Calidad

Las mejoras del servicio están reguladas por el ciclo de vida de la mejora. El ciclo de vida de la mejora

está inspirado en el Modelo Deming: Planear, Hacer, Revisar, Actuar. El modelo establece un patrón

claro para los esfuerzos de mejora continua. El proceso de planificación debe abordar los siguientes

elementos

PLANEAR — Establece las metas de mejora incluyendo el análisis de brechas, la definición de los pasos

de acción para cerrar las brechas y el establecimiento e implementación de medidas para asegurar que

se cerraron las brechas y se consiguieron los beneficios.

Alcance de la CSI

Objetivos y requerimientos de la CSI

Interfaces entre la CSI y el resto del ciclo de vida del servicio

Actividades del proceso que se van a desarrollar

Marco de los roles y las responsabilidades de la gerencia

Herramientas apropiadas para respaldar los procesos

Métodos y técnicas para medir, evaluar, analizar Y’ reportar la calidad, efectividad y eficiencia de los servicios y procesos de administración de servicios.

HACER — Desarrollo e implementación de un proyecto para cerrar las brechas. Implementación o

mejora de procesos y establecimiento de la operación fluida del proceso. La implementación de la CSI

incluye lo siguiente:

Fondos y presupuestos requeridos para respaldar la CSI

Documentación de los roles y las responsabilidades

Asignación de los roles y las responsabilidades para trabajar en las iniciativas de la CSI

Documentación y mantenimiento de las políticas, planes y procedimientos de la CSI

Comunicación y capacitación sobre las políticas, planes y procedimientos documentados

Aseguramiento de que se cuenta con herramientas de monitoreo, análisis, evaluación de

tendencias y generación de reportes

Integración con la Estrategia del Servicio, Diseño del Servicio, Transición del Servicio y Operación

del Servicio.

REVISAR — Comparación del ambiente implementado con las medidas de éxito establecidas en la fase

Planear. La comparación determina si sigue existiendo una brecha entre los objetivos de la mejora del

proceso y el estado del proceso operacional. Las brechas no requieren necesariamente un cierre. Una

brecha se puede considerar tolerable si el rendimiento real se encuentra dentro de los límites

permitidos de rendimiento.

El objetivo de esta etapa es monitorear, medir y revisar que se consigan los objetivos y planes

de la CSI. Al igual que con otros procesos, esto incluye generar reportes contra los planes y la

revisión de la documentación, así como realizar evaluaciones y auditorias del proceso. La clave

es identificar y recomendar oportunidades de mejora para el proceso de la CSI.

ACTUAR — El proceso de decisión para determinar si se requiere un trabajo posterior para cerrar las

brechas restantes, mediante la asignación de los recursos necesarios para respaldar otra ronda de

mejora. Las decisiones del proyecto en esta etapa son la información para la siguiente ronda del ciclo de

vida, lo que cierra el circuito como se informa en la etapa Planear.


208 | P á g i n a

Una línea base es el estado registrado de algo en un punto específico en el tiempo. Se puede crear una

línea base para una Configuración, un Proceso o para cualquier otro conjunto de datos. Por ejemplo, una

línea base se puede utilizar en:

• La Mejora Continua del Servicio, para establecer un punto de inicio para la planificación de mejoras

• La Gestión de la Capacidad, para documentar las características de rendimiento durante las

operaciones normales

• La Gestión de Configuraciones, para permitir que la Infraestructura de TI se restaure a una

configuración conocida en caso de que haya un fallo en el Cambio. Las líneas base también se utilizan

para especificar una Configuración estándar para fines de captura, publicación o auditoria de datos


209 | P á g i n a


210 | P á g i n a

El Rol del Gobierno

El gobierno corporativo tiene que ver con la promoción de la:

Imparcialidad

Transparencia

Responsabilidad

“Gobierno Empresarial es un término emergente... para describir un marco que cubre tanto los aspectos

del gobierno corporativo como de la administración de negocios de la organización. La consecución de

una panacea de buen gobierno corporativo que se vincula estratégicamente con las métricas de

rendimiento permitirá que las compañías concentren toda su energía en los impulsores clave que

mueven su negocio hacia adelante.”

El gobierno de TI toca casi todas las áreas detalladas en la figura de la página anterior. Por un lado, la TI

ahora debe cumplir reglas y leyes nuevas y demostrar continuamente su conformidad a través de

auditorías independientes exitosas realizadas por organizaciones externas. Por otro lado, cada vez se

pide más que la TI haga más con menos y cree un valor adicional al tiempo que maximiza el uso de los

recursos existentes.

Estas presiones cada vez mayores encajan perfectamente con la premisa básica de ITIL: la TI es un

negocio de servicios. Las organizaciones de TI internas existentes deben transformarse en proveedores

de servicios de TI efectivos y eficientes o dejarán de ser relevantes para el negocio y, poco después,

dejarán de existir. Este incesante impulso continuo hacia un mayor valor al negocio con una mayor

eficiencia interna se localiza en el corazón de la CSI.

Un enfoque completo e integrado sobre el diseño, la implementación y conformidad continúa de los

estándares aceptados de Administración de Servicios de TI.

Éste incluye:

Estructuras, roles y responsabilidades organizativos

Procesos, políticas y controles de TI

Technology

Gobernabilidad de ti