F un damentos de I TI L ®
Todos los derechos reservados. Ninguna parte de esta documentación puede ser reproducida, almacenada en un sistema de recuperación, o transmitida por medio alguno, electrónico, mecánico, fotográfico, o de otra forma sin la previa autorización por escrito del propietario de los derechos. No se asume responsabilidad de patente con respecto al uso de la información aquí contenida. Aún cuando todas las precauciones han sido tomadas en la preparación de esta publicación, no podrá hacerse responsable al titular de la patente por los daños causados por el uso de la información aquí contenida. © Pink Elephant, 2013 a menos que se especifique de otra forma. Todos los derechos reservados. 5575 North Service Road, Suite 200 Burlington, Ontario L7L 6M1 Canadá Teléfono: 905-331-5060 Fax: 905-331-5070 ITIL® es una Marca registrada de la Oficina de Comercio del Gobierno en el Reino Unido y otros países. El texto Citado /IITL que se distingue con tipo de letra itálica , proviene de los libros de ITIL® de la OGC (Estrategia del Servicio, Diseño del Servicio, Transición del Servicio, Operación del Servicio, Mejoramiento Continuo del Servicio) Derechos reservados ©Crown 2011. Reproducido bajo la licencia de la OGC. Syllabus version 5.5 – 2013 FDN 5.5.1 marzo2013
1
Tabla de Contenido Descripción del Curso Agenda
8 11
SECCIÓN 1: MÓDULO DE E NTRENAMIENTO
2
Fundamentos de ITIL ¡Bienvenido! Suscríbase a PinkLINK Acuerdos para el Curso Por favor preséntese Objetivos y Agenda del Curso
13 13 14 14 15 15
Introducción a ITIL Buenas Prácticas Por qué ITIL es exitoso Conceptos Generales ¿Qué es un Servicio? Clasificación de Servicios Servicio – Interno y Externo Creación de Valor a través de los Servicios Elementos Primarios del Valor Activos Gestión de Servicios Gestión de Servicios de TI Interesados en la Gestión de Servicios Clientes – Internos y Externos Automatización del Servicio Proceso Modelo del Proceso Características de los Procesos Funciones y Roles Roles Genéricos Modelo RACI El Ciclo de Vida del Servicio Procesos del Ciclo de Vida Tres Tipos de Métricas Acerca de los CSF y KPI El Ciclo de Deming PDCA
16 17 18 20 20 22 23 24 27 29 30 31 32 33 34 36 37 39 41 43 45 47 49 52 53 56
Estrategia del Servicio Propósito y Objetivos de Estrategia del Servicio Alcance de la Estrategia del Servicio Valor al Negocio de Estrategia del Servicio Gobernabilidad
57 57 59 60 61
Tipos de Proveedor de Servicios El Portafolio de Servicios Patrones de Actividad de Negocio (PBA) Gestión de Riesgos Caso de Negocio Gestión del Portafolio de Servicios Propósito de la Gestión del Portafolio de Servicios Objetivos de la Gestión del Portafolio de Servicios Alcance de la Gestión del Portafolio de Servicios Gestión Financiera para Servicios de TI
62 63 64 65 66 67 68 69 70 71
Propósito de la Gestión Financiera Objetivos Alcance de la Gestión Financiera Gestión de Relaciones del Negocio Propósito de la Gestión de Relaciones del Negocio Objetivos de la Gestión de Relaciones del Negocio Alcance de la Gestión de Relaciones del Negocio
72 73 74 75 76 77 78
Diseño del Servicio Propósito del Diseño del Servicio Objetivo y Alcance del Diseño del Servicio Valor al Negocio del Diseño del Servicio Las Cuatro Ps Paquete del Diseño del Servicio (SDP) Diseño del Servicio: Los Cinco Aspectos Principales Coordinación del Diseño Propósito de la Coordinación del Diseño
80 81 82 83 84 85 86 87 87
Objetivos de la Coordinación del Diseño Alcance de la Coordinación del Diseño Gestión de Niveles de Servicio Propósito de Gestión de Niveles de Servicio Objetivos de Gestión de Niveles de Servicio Alcance de Gestión de Niveles de Servicio Conceptos Básicos Otros Conceptos de SLM Actividades de la Gestión de Niveles de Servicio Interfaces de la Gestión de Niveles de Servicio Gestión del Catálogo de Servicios Propósito de la Gestión del Catálogo de Servicios Objetivos de Gestión del Catálogo de Servicios Alcance de la Gestión del Catálogo de Servicios Catálogo de Servicios – Dos Perspectivas Catálogo de Servicios – Tres Perspectivas
88 89 90 91 92 93 94 95 97 98 100 100 101 102 103 104
Gestión de Proveedores Propósito de la Gestión de Proveedores Objetivos de la Gestión de Proveedores Alcance de la Gestión de Proveedores
105 105 106 107
3
Conceptos Básicos Gestión de Seguridad de la Información Propósitos y Objetivos de Gestión de Seguridad de la Información Alcance de la Gestión de Seguridad de la Información Política de Seguridad de la Información Gestión de Disponibilidad Propósito de la Gestión de la Disponibilidad Objetivos de la Gestión de la Disponibilidad Alcances de la Gestión de la Disponibilidad Aspectos de la Disponibilidad
108 109 109 110 111 112 113 114 115 116
Gestión de la Capacidad Propósito de la Gestión de la Capacidad Objetivos de la Gestión de la Capacidad Alcance de la Gestión de la Capacidad Conceptos Básicos Gestión de la Continuidad de Servicios de TI Propósito de Gestión de la Continuidad de Servicios de TI Objetivos de Gestión de la Continuidad de Servicios de TI Alcance de Gestión de la Continuidad de Servicios de TI Requisitos de ITSCM
118 119 120 121 122 124 125 126 127 128
Transición del Servicio Propósito de la Transición del Servicio Objetivos de Transición del Servicio Alcance de Transición del Servicio Valor al Negocio de Transición del Servicio Modelos
4
130 130 131 132 133 134
Planificación de la Transición y Soporte Propósitos y Objetivos de Planificación de la Transición y Soporte Alcance de Planificación de la Transición y Soporte Gestión de Activos de Servicios y Configuración Propósito de la Gestión de Activos de Servicios y Configuración Objetivos de la Gestión de Activos de Servicios y Configuración Alcance de la Gestión de Activos de Servicios y Configuración Otros Conceptos de la Gestión de Activos de Servicios y Configuración Biblioteca Definitiva de Medios (DML) El Sistema de Gestión de Configuración Gestión de Cambios Propósitos y Objetivos de Gestión de Cambios Alcance de la Gestión de Cambios Tipos de Cambios Otros Conceptos de Gestión de Cambios Ciclo de Vida de un Cambio Normal
135 135 137 138 139 140 141 142 143 144 145 146 147 148 149 152
Interfaces de Gestión de Cambios Gestión de Liberación e Implementación Propósito de Gestión de Liberación e Implementación Objetivos de Gestión de Liberación e Implementación
154 156 157 158
Alcance de Gestión de Liberación e Implementación Política de Liberaciones Cuatro Fases de Liberación e Implementación Gestión del Conocimiento Propósito de Gestión del Conocimiento Objetivos de Gestión del Conocimiento Alcance de Gestión del Conocimiento Modelo DIKW Relaciones de CMDB, CMS, SKMS
Operación del Servicio Propósitos y Objetivos de Operación del Servicio Alcance de la Operación del Servicio Valor al Negocio de Operación del Servicio Conceptos de Operación del Servicio Evento Alerta Incidente Impacto, Urgencia y Prioridad Solicitud de Servicio Problema Solución Temporal Error Conocido Base de Datos de Errores Conocidos (KEDB) Gestión de Eventos Propósito de Gestión de Eventos Objetivos de Gestión de Eventos
159 160 161 163 164 165 166 167 168 170 171 172 173 174 174 175 176 177 178 179 180 181 182 183 184 185
Alcance de la Gestión de Eventos Gestión de Incidentes Propósito de Gestión de Incidentes Objetivos de Gestión de Incidentes Alcance de Gestión de Incidentes Conceptos Básicos de Gestión de Incidentes Actividades de Gestión de Incidentes Interfaces de Gestión de Incidentes Cumplimiento de Solicitudes Propósito y Objetivos de Cumplimiento de Solicitudes Alcance de Cumplimiento de Solicitudes Gestión de Problemas Propósito de la Gestión de Problemas Objetivos de la Gestión de Problemas Alcance de Gestión de Problemas Aspectos Reactivos y Proactivos
186 187 188 189 190 191 195 198 200 201 202 203 204 205 206 207
Otros Conceptos Gestión Problemas Actividades de lade Gestión dede Problemas Interfaces de la Gestión de Problemas Gestión de Accesos
208 209 210 214
5
Propósito de Gestión de Accesos Objetivos de Gestión de Accesos Alcance de Gestión de Accesos Funciones en Operación del Servicio Iniciando con el final en mente Función del Service Desk El Service Desk Beneficios del Service Desk Objetivos del Service Desk Estructuras Organizacionales del Service Desk
215 216 217 218 219 220 221 222 223 224
La Función Técnica El doblede rolladeGestión la Gestión Técnica Objetivos de la Gestión Técnica La Función de la Gestión de Aplicaciones Los roles de la Gestión de Aplicaciones Objetivos de Gestión de Aplicaciones Desarrollo de Aplicaciones vs Gestión de Aplicaciones La Función de la Gestión de Operaciones de TI Roles de la Gestión de Operaciones de TI Objetivos de la Gestión de Operaciones de TI Control de Operaciones de TI Gestión de Instalaciones Interacción entre las Funciones Comunicación en Operación del Servicio
227 228 229 230 231 232 233 234 235 236 237 238 239 240
Mejoramiento Continuo del Servicio (CSI) Propósito de Mejoramiento Continuo del Servicio Objetivos de Mejoramiento Continuo del Servicio Alcance de Mejoramiento Continuo del Servicio Valor para el Negocio de Mejoramiento Continuo del Servicio Conceptos básicos de Mejoramiento Continuo del Servicio El enfoque de CSI Objetivos y propósito del Proceso de Mejora en Siete Pasos Alcance del Proceso de Mejora en Siete Pasos El Proceso de Mejora en Siete Pasos
6
242 242 243 244 245 246 247 249 250 251
SECCCIÓN 2: RECURSOS ADICIONALES Rutas de Desarrollo Personal Programa de Estudios Instrucciones para el Registro al Examen
SECCIÓN 3: EXÁMENES DE EJEMPLO Documento de Ejemplo A Documento de Ejemplo B
7
Descripción del Curso – Fundamentos de ITIL El éxito proviene del Conocimiento que se Traduce en Resultados.
Este curso oficial de tres días de certificación de Fundamentos de ITIL le proporciona una visión general del Ciclo de Vida de Gestión de Servicios de TI el cual está resumido en los cinco libros fundamentales de ITIL – Estrategia del Servicio, Diseño del Servicio, Transición del Servicio, Operación del Servicio y Mejora Continua del Servicio. El “ciclo de vida” de ITIL consta de 26 procesos y cuatro funciones. Estas incluyen:
Etapa del Ciclo de Vida del Servicio Estrategia del Servicio Diseño del Servicio
Transición del Servicio
Operación del Servicio
Mejoramiento Continuo del Servicio
Procesos y Funciones Gestión Estratégica para los Servicios de TI, Gestión del Portafolio de Servicios, Gestión Financiera para los Servicios de TI, Gestión de Relaciones del Negocio, Gestión de la Demanda Coordinación del Diseño, Gestión de Niveles de Servicio, Gestión del Catálogo de Servicios, Gestión de Proveedores, Gestión de Seguridad de la Información, Gestión de la Disponibilidad, Gestión de la Capacidad, Gestión de la Continuidad de los Servicios de TI Planificación de la Transición y Soporte, Gestión de Cambios, Gestión de Activos de Servicios y Configuración, Gestión de Liberación e Implementación, Validación y Pruebas del Servicio, Evaluación de Cambios, Gestión del Conocimiento Gestión de Eventos, Gestión de Incidentes, Cumplimiento de Solicitudes, Gestión de Problemas, Gestión de Accesos y la funciones de: Gestión de Operaciones Aplicaciones, Service Desk de TI, Gestión Técnica, Gestión de Proceso de Mejora Continua en Siete Pasos
Actitud, Comportamiento y Cultura (ABC) – ¡Un a exclu siva de la i ndustri a! Pink Elephant hace realidad el aprendizaje en esta clase a nivel de Fundamentos de ITIL a través del empleo de ejercicios significativos para ayudarlo a entender cómo tomar el conocimiento (teoría) y traducirlo en resultados, valor y consecuencias positivas. Cada año existe un alto porcentaje de proyectos de ITSM que fracasan porque algunos elementos culturales clave necesarios para el cambio – organizacional y de comportamiento – no fueron abordados efectivamente. Nosotros somos el único proveedor que incluye educación sobre como definir problemas relacionados con la cultura, para que usted pueda entender los factores que limitan que un proyecto de transformación de ITSM sea exitoso en su organización. Vaya más allá de sólo la teoría – ¡aprenda cómo aplicar su conocimiento al regresar al trabajo! El instructor trabajará con usted para especificar y documentar elementos de acción que usted pueda poner en práctica inmediatamente al volver del curso a su organización.
8
El ejercicio de aprendizaje ABC sólo se ofrece a través de cursos públicos o entregas en sitio ( no está incluido dentro de los cursos en línea).
LO QUE USTED APRENDERÁ El curso está diseñado como una introducción a ITIL y le permite entender cómo puede utilizarse un marco de referencia de ITSM integrado para alcanzar la integración del negocio de TI, reducción de costos e incrementar la productividad. La agenda incluye:
Actitud, Comportamiento y Cultura (Para Cursos Públicos y Entregas en Sitio): ¿Cuáles es la percepción del cliente/usuario con respecto a TI?
¿Cuál es la “Declaración del Problema” de su organización? ¿Qué partes de ITIL resuelven esta Declaración del Problema? ¿Cuáles son los elementos de resistencia ABC a los que usted se enfrentará al estar de vuelta en su organización? ¿Cuáles serán sus acciones inmediatas al volver a su trabajo y cómo le ayudará ITIL a afrontarlas?
Para Todos los Entregables del Curso:
¿Qué es ITIL; sus beneficios estratégicos y operacionales; y una revisión general del programa de certificación de ITIL. Conceptos clave, definiciones y objetivos de ITIL Enfoque del “ciclo de vida de ITIL con base en el servic io” y la estructura, componentes, procesos y funciones de los cinco fundamentales de ITIL. Para cadaeluno de los cinco libros fundamentales y suslibros procesos y funciones relacionados curso le proporciona: Una descripción de alto nivel de las principales actividades, metas y beneficios Interrelaciones e interdependencias entre los procesos, qué significa realmente “integración del proceso ” e “integración del negoc io” Métricas clave y reporte gerencial. o o
o
El curso lo prepara para el examen que lo lleva a la obtención del Certificado en Fundamentos de Gestión de Servicios de TI. Este certificado es el prerrequisito para los niveles Intermedio y Experto de la certificación de ITIL.
BENEFICIOS
Tomar el curso presencial de ITIL más popular en el mundo de los pioneros en la capacitación de ITIL en Norteamérica. Liderazgo en Pla consultores reputación de inkindustriade proveerbenefíciese las tasas dede aprobación másaltamente altas de la conocedores industria. y de la Conveniencia- cursos programados con regularidad en las principales ciudades a lo largo del año.
9
Exhaustivo – el material acreditado del curso cubre áreas clave de ITIL V3, preparándolo para el examen oficial.
ACREDITACIÓN DEL CURSO E INSTRUCTOR Pink Elephant está acreditado a nivel global para proporcionar educación de ITIL para el programa de certificación. La organización está acreditada por el Instituto de Examinación para las Ciencias de la Información (EXIN), el Comité de Examinación de Sistemas de Examinación (ISEB), y los Servicios de Certificación Oficiales (LCS). Su instructor esenunITIL, miembro del está equipo de consultoría de Pinkeste Elephant experimentado él o ella calificado para impartir curso decertificado acuerdo ayloaltamente definido en el Programa interno de Instructor Certificado de Pink Elephant. Puede esperar aprender de un individuo con el conocimiento más profundo de la industria en cómo dirigir un proyecto exitoso de implementación. Este conocimiento es el resultado directo de la neutralidad de Pink Elephant con respecto al proveedor- así como muchos años de experiencia implementando procesos de ITIL en una gran variedad de organizaciones en todo el mundo.
QUIÉN DEBE ASISTIR Fundamentos de ITIL es adecuado para cualquier persona que esté trabajando en servicios de TI que requiera más información sobre el marco de referencia de ITIL, o bien, individuos que están certificados en la V2 y que desean actualizar sus conocimientos. No existen pre-requisitos mandatorios. Se recomienda contar con experiencia en servicios de TI.
RECONOCIMIENTOS CERTIFICACIONES Este curso prepara Ya los participantes para el examen para la obtención del certificado de “Fundamentos en Gestión de Servicios de TI”. El último día del curso se programa un examen con 40 preguntas de opción múltiple con una duración de 60 minutos que es administrado por un cuerpo examinador independiente. Para los cursos en línea, el examen puede ser programado y completado en línea. Se requiere de un porcentaje mínimo del 65% para recibir la certificación. Durante el curso se utilizan exámenes de muestra para ayudar a los asistentes a prepararse para el examen final. 2 créditos ITIL Obtendrá 18 unidades de desarrollo profesional (PDUs) para Administradores de Proyectos. Obtendrá 1.8 Unidades de Educación Continua.
10
Agenda Los horarios del curso serán los siguientes. Por favor tenga en cuenta que todos los tiempos son estimados y que algunos horarios pueden moverse.
Días 1 y 2 Tema 8:30
9:30
9:30 9:40 10:45 10:55 12:00 13:00 14:00 14:10 15:15 15:25 16:30
9:40 10:45 10:55 12:00 13:00 14:00 14:10 15:15 15:25 16:30 17:00
Receso Receso Comida Receso Receso Revisión / Recapitulación / Fin
Día 3 Tema 8:30 9:50 10:00 11:00 11:10 12:00 13:00 14:00 14:15 15:15 15:30 16:00
9:50 10:00 11:00 11:10 12:00 13:00 14:00 14:15 15:15 15:30 16:00 17:00
Receso Receso Comida Revisión Receso Revisión Receso Registro Examen
11
NOTAS:
12
Bienvenido
13
Bienvenido
14
Bienvenido
15
Introducción a ITIL
ITIL es el enfoque de Gestión de Servicios de TI más ampliamente aceptado en el mundo. Brinda orientación a los proveedores de servicios de TI con respecto a as capacidades (procesos, funciones, etc.) necesarias para entregar dar soporte de servicios de TI de calidad. ITIL toma el enfoque de ciclo de vida para implementar La Gestión de Servicios y está basado en cinco libros fundamentales:
Estrategia del Servicio Diseño del Servicio Transición del Servicio Operación del Servicio Mejoramiento Continuo del Servicio
Tenga en mente que no existe algo así como estar “En cumplimiento co n ITIL”. Más bien, se invita a los proveedores a que adapten las buenas prácticas de ITIL a sus ambientes específicos buscando cubrir sus propias necesidades. ISO/IEC 20000 proporciona un estándar formal y universal para las organizaciones que buscan tener sus capacidades de Gestión de Servicios auditadas y certificadas. Mientras que ISO/IEC 20000 es un estándar para ser alanzado y mantenido, ITIL ofrece un cuerpo de conocimientos útil para alcanzar el estándar.
16
Introducción a ITIL
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 puedan tener. La adopción de buenas prácticas de la industria puede ayudar a una organización a desarrollar o mejorar las capacidades necesarias para lograr la entrega de servicios de calidad. La adopción de buenas prácticas necesita considerar las Fuentes, Habilitadores, Escenarios involucrados.
e Impulsores
Fuentes: Generan opciones de buenas prácticas de entre las cuales elegir Ignorar los marcos de referencia y estándares públicos puede poner innecesariamente a una organización en desventaja. Las organizaciones deben cultivar su propio conocimiento interno sobre un cuerpo de conocimientos basado en marcos de referencia y estándares públicos.
Habilitadores: Agregan la facultad de llevar a cabo las buenas prácticas seleccionadas. Impulsores (un filtro): Eventos o actividades que crean la necesidad de adoptar una práctica. Escenarios (un filtro): La(s) situación(es) que causan que una organización se enfoque en prácticas específicas.
17
Introducción a ITIL
ITIL es exitoso porque es práctico, una guía estructurada que ha comprobado funcionar en organizaciones en todas partes. Proporciona un marco de referencia común de prácticas destinadas a entregar valor al negocio. Esta lista resalta algunas razones de su éxito global:
18
Neutr al h acia proveedores Las prácticas de gestión de servicios de ITIL son aplicables dentro de cualquier organización de TI porque no están basadas en una plataforma tecnológica en particular o tipo de industria. ITIL es propiedad del gobierno de Reino Unido y no está ligado ninguna práctica comercial o solución propietaria. No-prescriptivo ITIL ofreces prácticas robustas, maduras y probadas a lo largo del tiempo que pueden aplicarse a todo tipo de organización de servicios. Continúa siendo útil y relevante en sectores público y privado, proveedores de servicios internos y externos, empresas pequeñas medianas y grandes, y dentro de cualquier ambiente técnico. Las Organizaciones deben adoptar ITIL y adaptarlo para satisfacer las necesidades de la organización de TI y sus clientes. Buenas prácticas ITIL representa las experiencias de aprendizaje y pensamiento de liderazgo de los mejores proveedores de servicios en su clase a nivel mundial.
Introducción a ITIL ITIL ha sido adoptado por las organizaciones para permitirles:
Entregar valor a los clientes a través de los servicios Integrar la estrategia de los servicios con la estrategia de negocio y las necesidades del cliente Medir, monitorear y optimizar los Servicios de TI y el desempeño del proveedor de servicios Gestionar la inversión y el presupuesto de TI
Gestionar el riesgo
Gestionar el conocimiento
Gestionar las capacidades y recursos para entregar servicios efectiva y eficientemente
Permitir la adopción de un enfoque estándar para gestión de servicios a través de la empresa
Cambiar la cultura organizacional para soportar un logro sostenido del éxito
Mejorar la interacción y la relación con los clientes
Coordinar la entrega de bienes y servicios a través de la cadena de valor
Optimizar y reducir costos
19
Conceptos generales
20
Conceptos generales
Lo siguiente nos puede ayudar a recordar la definición de un servicio (VRCR):
Valor Resultados Costos Riesgos
Los resultados de los clientes son alcanzados por el desempeño de tareas, pero pueden estar limitadas por cie rtas restricciones. Los servicios correctos pueden incrementar la probabilidad de que un cliente alcance los resultados deseados al aumentar la capacidad del cliente para desempeñar las tareas necesarias y/o reducir alguna restricción existente.
Es crítico entender que los servicios no son análogos a sistemas o componentes de tecnología. Los servicios son percibidos por el cliente como una entidad integral de punta a punta, compuesta de tecnología, gente, procesos, proveedores, fondos, instalaciones, cumplimiento de regulaciones, etc. Ejemplo Un negocio está lanzando un sitio de compras en línea. Una oferta como esta requiere de personal, equipo, instalaciones e infraestructura para que el sitio sea exitoso. La unidad de negocios responsable de esta oferta no tiene el grado de dominio necesario – ni lo desea adquirir – para hacer realidad esta oferta. Tampoco desea hacerse responsable de los riesgos y costos asociados. Afortunadamente, existe un grupo dentro del negocio con conocimientos especializados y experiencia en proveer la infraestructura necesaria y la habilidad para controlar los costos y riesgos asociados. La unidad de negocios sigue siendo responsable de atender los pedidos en línea. Sin embargo, no es responsabl e de la operación y mantenimiento de los distintos componentes de la infraestructura requeridos para el sitio de compra en línea.
21
Conceptos generales
Podemos considerar a los servicios en términos de la relación entre ellos y con sus clientes y podemos clasificarlos de la siguiente manera: Servicio Base: cimentan la propuesta de valor para el cliente y proporciona las bases para su utilización y satisfacción continua.
Servicio H abil itante: Son servicios necesarios para que un servicio base pueda ser entregado. Estos servicios no son percibidos por el cliente como servicios por si mismos. Los clientes los consideran como elementos básicos que permiten la entrega de los servicios fundamentales (reales). Servi cio Compleme ntar io: Son servicios que son agregados a un servicio base con la finalidad de hacerlo más emocionante o atractivo al cliente. Estos no son servicios esenciales para la entrega de un servicio base. Piense en ellos como factores de “emoción”; el tipo de cosas que se usan para animar a los clientes a que hagan mayor uso de un servicio base, o hasta llegar a elegir un proveedor de un servicio base por encima de otros.
22
Conceptos generales
23
Conceptos generales
L os cli entes no compr an ser vici os; ellos compran la sati sfacción de necesidades par ti cul ar es.
‘L a
gente no qu iere br ocas de un cuar to de pul gada, ellos qui er en agujeros d e un cuarto de pul gada .’ Pr ofesor Emé r ito Th eodore L evitt, H ar vard Bu siness School
Es importante recordar que frecuentemente lo que el cliente valora es diferente de lo que la organización de TI cree que está entregando. El verdadero valor radica en lo que el servicio le permite lograr al cliente. Las características del valor son:
El val or estádefi nido por l os clientes
–
El cliente toma la decisión final sobre si un
servicio es valioso o no
– Los servicios con valor representan la mejor mezcla de características a un precio que el cliente está dispuesto a pagar
M ezcla de características asequibles
L ogro de los objetivos
–
Los servicios deben lograr los objetivos deseados, los cuales
pueden noobjetivos ser de naturaleza financiera. Algunos servicios estándediseñados para alcanzar otros deolos de una organización, tales como la gestión recursos humanos
24
– las necesidades y valores del servicio cambian conforme se modifican las necesidades del cliente
El valor cambia dependi endo del tiempo y las cir cun stan cias
Conceptos generales
Debido a que los servicios son vistos como que aportan valor, cuando el costo de obtenerlos es menor que el valor que se percibe que entregan, se requiere de tres partes de información para entender el valor de TI:
¿Qué servicio(s) proporcionó TI? ¿Qué logró (lograron) el (los) servicio(s)? ¿Cuánto costó (costaron) el (los) servicio(s) – o cuál es el precio del (de los) servicio(s)?
Creando Valor El valor necesita ser definido en términos de tres áreas: los resultados del negocio logrados, las preferencias del cliente y la percepción del cliente sobre lo que fue entregado.
Las percepciones del cliente sobre el valor están directamente influenciadas por los atributos de un servicio, aquellas características que proporcionan el aspecto de Utilidad del servicio. También están influenciadas por las expectativas del cliente y su propia imagen o posición actual en el mercado. El diagrama de abajo muestra cómo perciben el valor los clientes (según Nagle y Holden, 2002). Diferencia positiva
Diferencia negativa
Ganancia por el utilizar servicio
+
Diferencia neta
Pérdida por utilizar el servicio
Basada en la estrategia de hacerlo uno mismo o con arreglos existentes Valor de referencia
Valor económico del servicio
© Derechos reservados de la Corona 2011. Reproducido bajo la licencia de la OGC. Diagrama 3.7 Estrategia del Servicio 3.2.3.1
En este diagrama el punto de partida para la percepción del cliente es el valor de referencia. Este puede basarse en lo que el cliente ha escuchado sobre el servicio, o en el hecho de que el cliente está realizando por él mismo la actividad, o tiene alguna experiencia previa con ese o un servicio similar. El valor de referencia puede estar vagamente definido o basado en hechos reales. Un ejemplo de valor de referencia es la línea base que los clientes mantienen sobre el costo de las funciones o servicios internos (la estrategia DIY, o hágalo usted mismo)
25
Conceptos generales La diferencia positiva del servicio está basada en los beneficios adicionales percibidos y las ganancias que brinda el proveedor de servicios. Estas diferencias están basadas en la Garantía y Utilidad adicionales que el proveedor de servicios es capaz de entregar. La diferencia negativa de el servicio es la percepción de lo que el cliente perdería al invertir en el servicio. Por ejemplo, pueden percibir algún problema de calidad o costo oculto. El servicio puede no tener la funcionalidad completa que ellos quisieran por el precio solicitado. La diferencia neta es la percepción actual que el cliente tiene de qué tanto es mejor (o peor) el servicio comparado con el valor de referencia después de descontar la diferencia negativa. Esta es el área que impulsará la decisión del cliente para invertir o no en el servicio. El valor económico es el valor total que el cliente percibe en el servicio a entregar. Incluye el valor de referencia más (o menos) la diferencia neta del servicio que ellos reciben, y es medible por el cliente en la capacidad de obtener los resultados deseados.
26
Conceptos generales
El valor de un servicio para los clientes está relacionado con la definición de un servicio, en parte, como un medio de entregar valor a los clientes al facilitarles los resultados que el cliente quiere. Tales resultados son posibles al mejorar el desempeño de las tareas o al reducir las restricciones. Para los clientes, el valor de un servicio se basa en dos elementos primarios: Utilidad y Garantía.
Utilidad – Adecuado para el Propósito Se trata de lo que hace el servicio Se deriva de los atributos de un servicio que mejoran el desempeño de los activos de un cliente, o elimina o reduce las restricciones en dicho desempeño, llevando a una mayor posibilidad de lograr los resultados.
Garantía – Adecuado para el Uso Se trata de cómo se entrega el servicio al cliente Es la seguridad de que los objetivos de desempeño están siendo cumplidos, reduciendo por lo tanto, las pérdidas potenciales debido a variaciones en el desempeño del servicio Se deriva del efecto positivo de que el servicio esté disponible cuando se necesita y en la capacidad o magnitud suficiente. También se refiere a la fiabilidad en términos de la continuidad y seguridad del servicio.
Ambas, la Utilidad y la Garantía son necesarias para que el servicio tenga valor. Los clientes no pueden percibir los beneficios de un servicio que es adecuado al propósito (Utilidad) pero no adecuado para el uso (Garantía), o viceversa.
27
Conceptos generales El aspecto de la Garantía del servicio necesita ser diseñado al mismo tiempo que el aspecto de la Utilidad para entregar el valor requerido al negocio. Los intentos por diseñar los aspectos de la Garantía después de que un servicio ha sido implantado pueden ser caros y perjudiciales.
El definir los resultados esperados por el cliente – además del levantamiento de requerimientos – se convierte en la preocupación fundamental de los gerentes de producto. Los requerimientos son necesarios y ayudan en los esfuerzos internos de coordinación y control del proveedor, pero para garantizar el valor de los servicios, los resultados del cliente deben estar bien definidos y ser bien comprendidos. La información con respecto a los resultados esperados del negocio, oportunidades, clientes, Utilidad y Garantía del servicio es usada para desarrollar la definición de un servicio. Utilizar una definición basada en el resultado ayuda a garantizar que los gerentes planeen y ejecuten todos los aspectos de la Gestión del Servicio desde la perspectiva de lo que es valioso para el cliente.
28
Conceptos generales
Las Capacidades se desarrollan a través del tiempo y representan la habilidad de la organización para controlar, coordinar y desplegar recursos para producir valor. Normalmente son alcanzadas a través de la experiencia, son intensivas en cuanto al conocimiento y están firmemente incrustadas dentro de una organización Las capacidades por sí solas, no son suficientes para generar valor; también se requieren de recursos adecuados y apropiados. Los Recursos son las entradas directas requeridas para la producción y en general, son más fáciles de adquirir en comparación con las capacidades.
29
Conceptos generales
Hoy en día, la gestión de servicios tradicional está en la esencia de muchos negocios: bancos, viajes, detallistas, servicios públicos y muchos otros. Todas estas organizaciones tienen como esencia su habilidad para tomar los recursos requeridos, combinarlos con las capacidades requeridas y entregar los servicios deseados a su base de clientes.
30
Conceptos generales
Debido a que hoy en día los servicios de TI son esenciales para alcanzar los resultados del negocio, se han convertido en verdaderos artículos de uso cotidiano. Justo como cuando esperamos que las luces se prendan cuando apretamos el interruptor, el negocio espera que los servicios de TI estén ahí cuando los necesitan, desempeñando las tareas que se espera que desempeñen. Los mismos principios de gestión de servicios encontrados en las organizaciones tradicionales de servicios, ahora aplican a TI. Toda organización de TI debe actuar como un proveedor de servicios, usando los principios de gestión de servicios para garantizar que entreguen los resultados requeridos por el cliente.
Gestión de Servicios de TI:
Está compuesta de funciones y procesos para gestionar los servicios a lo largo de un ciclo de vida Se enfoca en la estrategia, diseño, transición, operación y mejoramiento continuo Posiciona a la organización como un agente de cambio para facilitar la transformación del negocio.
Conforme los proveedores de servicios de TI incrementan y maduran sus capacidades de gestión de servicios, son capaces de entregar niveles más altos de Utilidad y Garantía sin un aumento proporcional de recursos – concretamente costos y personal.
31
Conceptos generales
Dentro de una organización proveedora de servicios, existen diferentes partes interesadas que contribuyen a la entrega de los servicios de TI, concretamente, las distintas funciones, grupos y equipos. Sin embargo, también existen interesados que son externos a la organización proveedora de servicios.
32
Clientes – Aquellos que compran bienes o servicios. El cliente de un proveedor de servicios es la persona o grupo que define y acuerda los objetivos de niveles de servicio. Este término es empleado de manera informal para referirse al usuario – por ejemplo, ‘Esta es una organización orientada al cliente ’. Usuarios – Aquellos que utilizan el servicio cotidianamente. Los usuarios son distintos de los clientes, ya que algunos clientes no utilizan el servicio de TI directamente. Proveedores – Terceras partes responsables de proveer los bienes o servicios que son requeridos para entregar servicios de TI. Como ejemplos de proveedores se incluyen fabricantes de artículos de hardware y software, proveedores de redes y telecomunicaciones y organizaciones de ‘outsourcing’.
Conceptos generales
Clientes Internos Un ejemplo de un cliente interno es el departamento de Recursos Humanos el cual está soportado por el departamento interno de TI, siendo ambos, parte de la misma o
o
organización. El cobro es opcional y si TI cobra por sus servicios, el dinero es pagado como una transacción interna
Clientes Externos Los clientes externos compran servicios de TI de una tercera parte proveedora y los servicios son cubiertos bajo un contrato o acuerdo de vinculación legal. o
33
Conceptos generales
La Automatización puede tener un impacto significativo en el desempeño de activos del servicio tales como gestión, organización, gente, proceso, conocimiento e información Las aplicaciones por sí mismas son medios de automatización pero su desempeño también puede ser mejorado cuando se necesiten compartir entre personas y activos de procesos Los Avances en áreas tales como inteligencia artificial, aprendizaje de máquina y tecnologías ricas en medios elevan las capacidades de agentes de servicios basados en software para desempeñar diversidad de tareas e interacciones. La automatización puede mejorar directamente la Utilidad y la Garantía de los servicios y puede tener las siguientes ventajas: o
o
o
La capacidad de los recursos automatizados puede ajustarse con mayor facilidad para responder a las variaciones de los volúmenes de demanda. Los recursos automatizados pueden manejar la capacidad con menores restricciones de tiempo de acceso; por lo tanto, pueden ser utilizados para atender la demanda a lo largo de husos horarios y fuera del horario de trabajo. Los sistemas automatizados son una buena base para medir y mejorar los procesos de servicio al mantener constante el factor de recursos humanos. En forma inversa, pueden ser utilizados para medir el impacto diferencias en la calidad y costos del servicio debido a los niveles variados de conocimientos, competencias y experiencia de los recursos humanos.
34
Conceptos generales o
o
Muchos problemas de optimización tales como la programación, ruteo y asignación de recursos, requieren de poder de cómputo que está más allá de la capacidad humana. La automatización es un medio para capturar el conocimiento requerido por un proceso de servicio. El conocimiento codificado es relativamente fácil de distribuir a través de la organización de una forma consistente y segura. Reduce la depreciación del conocimiento cuando los empleados se cambian de puesto dentro de la organización o se van permanentemente.
Preparándose para la automatización Simplifique los procesos de servicios antes de automatizarlos. Aclare el flujo de actividades, la asignación de las tareas, necesidad de información e interacciones. En situaciones de autoservicio, reduzca el área de contacto que los usuarios tienen con los sistemas y procesos subyacentes. Haga las interacciones tan amigables como sea posible para que la experiencia general del usuario sea positiva. No corra prisa por automatizar tareas e interacciones complejas o no rutinarias. Busque los patrones de actividad recurrentes para atenderlos antes que las actividades poco frecuentes y menos consistentes.
35
Conceptos generales
Procesos Los procesos bien definidos pueden traer consigo valor para las partes interesadas de diferentes maneras, tales como incrementar la productividad dentro y a lo largo de las organizaciones y las funciones, así como mejorar la efectividad y la eficiencia de los servicios soportados por los procesos.
36
Conceptos generales
Modelo del Proceso Al definir las actividades de la organización, las entradas requeridas y las salidas deseadas, se hace posible ganar en eficiencia y efectividad. La efectividad aumenta a través de la medición y la gestión de las actividades lo cual incluye:
Consta de actividades estructuradas encaminadas a lograr un conjunto de objetivos Toma una o más entradas y genera salidas definidas que son encaminadas por los objetivos e incluyen mejoras en mediciones, reportes y procesos Es detonado por uno o más eventos Incluye los roles, responsabilidades, herramientas y controles de gestión necesarios para entregar en forma confiable las salidas deseadas Debe ser documentado y controlado para ser repetible y administrable Requiere de recursos y capacidades para habilitarlo – de otro modo, sólo es documentación Debe tener un Dueño del Proceso – una persona que se responsabilice de su éxito (que se cumplan sus objetivos, sea adoptado, documentado, mejorado, en cumplimiento, etc.) Debe apegarse a las normas operacionales (las condiciones y los resultados deben ser alcanzados) derivados de los objetivos del negocio También puede edefinir o revisardepolíticas, lineamientos, actividades, proceso, procedimientos instrucciones trabajo siestándares, son necesarias.
37
Conceptos generales
Control del Proceso El “cerebro” del proceso global que asegura que existan objetivos generales, políticas de soporte, un Dueño del Proceso identificado, documentación de referencia y la capacidad de solicitar y registrar retroalimentación.
El Proceso El proceso por si mismo, consiste en un conjunto estructurado de actividades diseñadas para lograr los objetivos del proceso, con roles y métricas para mediciones claramente definidas.
Habilitadores del Proceso Garantizan que el proceso está soportado por los recursos y capacidades apropiadas para que trabaje efectivamente.
38
Conceptos generales
39
Conceptos generales
Las cuatro siguientes características aplican a todos los procesos:
Medible El proceso es impulsado por el desempeño y puede ser medido en una forma relevante El enfoque de las métricas variará dependiendo de la audiencia; los gerentes se enfocan en la calidad, costos, etc., mientras que los que lo ejecutan se enfocan en el tiempo, el alcance y la entrega
Entrega Resultados Específicos
Los Procesos individualmente, existen para entregar resultados específicos (salidas) los cuales deben ser identificables medibles y constatables. Un ejemplo de un resultado del proceso de Gestión de Cambios sería una lista de Cambios aprobados.
Tiene Clientes Los resultados principales son entregados a clientes o partes interesadas internos(as) y/o externos(as) El proceso debe cubrir las expectativas del cliente o parte interesada Un ejemplo de un cliente del proceso de Gestión de Cambios es el Departamento de Mercadotecnia con una Solicitud de Cambio para una nueva partición de red.
Responde a eventos específicos Aunque que un proceso puede ser continuo o iterativo, debe ser rastreable con respecto a un detonador específico Un ejemplo de un detonador para el proceso de Gestión de Cambios sería una nueva
Solicitud de Cambio.
40
Conceptos generales
41
Conceptos generales
Funciones Dependiendo del tamaño de la organización, una función puede ser una sola unidad organizacional o ser desempeñada por varios departamentos, equipos y grupos. En organizaciones más pequeñas, un solo individuo o grupo puede desempeñar varias funciones – por ejemplo, un departamento técnico podría incluir la función de Service Desk. Los Roles y responsabilidades para los procesos deben estar claramente definidos a fin de que el ciclo de vida del servicio sea exitoso. Una estructura organizacional apropiada de equipos, grupos o funciones necesitará ser establecida y gestionada. Estos se definen como sigue:
Grupo: Un grupo es un número de personas que son similares de alguna forma. En ITIL, los grupos se refieren a la gente que desempeña actividades similares – aún cuando puedan trabajar en tecnologías diferentes o reportar a diferentes estructuras organizacionales o inclusive a diferentes compañías. Los grupos por lo general son estructuras organizacionales informales, pero son muy útiles al definir procesos comunes a lo largo de la organización – por ejemplo, garantizar que las personas que resuelven los incidentes completen el registro de incidentes de la misma manera. Equipo: Un equipo es un tipo de grupo más formal. Estos son personas que trabajan juntos para alcanzar un objetivo común, pero no necesariamente en la misma estructura organizacional. Los miembros del equipo pueden estar ubicados o trabajar en distintas localidades y operar virtualment e. Los equipos son útiles para la colaboración, o bien para lidiar con una situación de naturaleza temporal o de transición. Como ejemplos de equipo se incluyen los equipos de proyecto, equipos de desarrollo de aplicaciones (que frecuentemente constan de personas de distintas unidades de negocio) y equipos de resolución de incidentes o problemas. Departamento: Los Departamentos son organizaciones formales que existen para desempeñar un conjunto específico de actividades definidas cotidianamente. Los departamentos tienen una estructura jerárquica de reporte con gerentes que normalmente son responsables de la ejecución de las actividades y también de la gestión diaria del personal dentro del departamento. División: Una división se refiere a un número de departamentos que han sido agrupados juntos, frecuentemente por ubicación geográfica o línea de producción. Normalmente una división está auto-contenida.
Roles Los Roles, definidos en un proceso o función, son utilizados para asignar actividades y otorgar responsabilidades y autoridad a una persona o equipo. Son sombreros a usar en un determinado momento, y una persona o equipo puede usar varios sombreros. Por ejemplo, un solo individuo puede jugar el rol de Gerente de Configuración y Gerente de Cambios.
42
Conceptos generales
Dueño del Servicio El Dueño del Servicio es responsable de la entrega de un servicio específico de TI y es el principal interesado en todos los procesos de TI subyacentes que habilitan o soportan el servicio.
Definir un punto único de responsabilidad para un servicio es esencial para proporcionar el nivel de atención y enfoque requerido para garantizar que un servicio sea manejado con un enfoque de negocio. Las responsabilidades incluyen:
Entender y representar al servicio a lo largo y ancho de la organización Proporcionar información de entrada sobre los atributos del servicio, tales como desempeño, disponibilidad, etc. Servir como punto de escalación para incidentes mayores. Representar al servicio durante las reuniones del Comité Asesor de Cambios (CAB) para la gestión de cambios que afectan el servicio bajo su cuidado Proporcionar información de entrada y priorización de las iniciativas de Mejoramiento Continuo del Servicio (CSI) Participar en las juntas de revisión del servicio dentro de TI y con el negocio Garantizaren quenegociar el registro el Catálogo de Servicios es preciso y se yleendalos mantenimiento Participar los en Acuerdos de Niveles de Servicio (SLAs) Acuerdos de Nivel Operacional (OLAs)
43
Conceptos generales
Dueño del Proceso El Dueño del Proceso es el responsable de garantizar que el proceso sea adecuado al propósito.
Esta debe ser una posición de tipo senior dentro de la organización para que el proceso sea apoyado efectivamente. Las tareas del Dueño del Proceso incluyen:
Documentar y difundir el proceso Definir, revisar y tomar acción en los Indicadores Clave de Desempeño (KPIs) Ayudar en el diseño y ser el responsable final del diseño del proceso Elevar la efectividad y la eficiencia del proceso Revisar propuestas de mejora al proceso y atender cualquier situación al respecto.
Proveer información de entrada en el Planydeesté Mejora del Servicio Garantizar que el personal esté entrenado consciente de sus (SIP) roles en el proceso Garantizar que el proceso y sus roles y responsabilidades asociados sean revisados y auditados con regularidad Garantizar que los recursos necesarios estén disponibles
Gestor del Proceso El Gestor del Proceso es el responsable de la gestión operacional de un proceso. Es posible que
existan varios gestores para un proceso, por ejemplo en el caso de gerentes regionales de cambio. Este rol puede estar combinado o separado del Dueño del Proceso. Las responsabilidades incluyen:
Planear y coordinar todas las actividades de los procesos con el Dueño del Proceso Garantizar que todas las actividades sean llevadas a cabo conforme a lo requerido a través del ciclo de vida del servicio Garantizar que las personas estén asignadas apropiadamente a los roles requeridos
Gestionar los asignadosmarchen con fluidez en conjunto con los Dueños del Servicio Garantizar queroles los servicios y otros Gerentes de Proceso Monitoreo y Reporte del desempeño del Proceso Identificar las oportunidades de mejora Apoyar al Gerente de CSI y al Dueño del Proceso en revisar y asignar prioridad a las mejoras listadas en el registro de CSI Llevar a cabo la implementación de mejoras del proceso
Practicante del Proceso El Practicante del Proceso es responsable de llevar a cabo uno o más actividades del proceso.
Un ejemplo de Practicante del Proceso sería un Analista de Cambios o un miembro de un equipo técnico llenando una Solicitud de Cambio. Sus responsabilidades típicas incluyen:
44
Desempeñar una o más actividades de un proceso Entender el impacto de su rol en la entrega de todo el servicio y la creación de valor para el negocio Garantizar que sus contribuciones sean efectivas y que las entradas, salidas e interfaces sean correctas Creación o actualización correcta de los registros para indicar que las actividades han sido llevadas a cabo correctamente
Conceptos generales
El Modelo RACI es una matriz de autoridad utilizada para ubicar recursos y responsabilidades en relación a los procesos y actividades. Puede ser utilizada para ayudar en la definición de la estructura de una organización. Responsable
(Responsible)
Reponsable Final (A ccountable) Consultado
(Consulted)
Informado (I nformed)
La persona o personas que desempeñan las actividades Un solo individuo que tiene la propiedad de la calidad de principio a fin; autoridad con la última palabra en la decisión, diseño o actividad del proceso. Proporcionar conocimiento e información; comunicación en dos vías, usualmente un experto en la materia Recibe información, es notificado con respecto a la ejecución y calidad del proceso
45
Conceptos generales
Los siguientes son algunos de los problemas potenciales que se deben tener en mente:
Contar con más de una persona como responsable final del proceso significa que nadie es responsable. Delegar la responsabilidad sin la autoridad requerida causa i nefectividad Relacionar procesos y actividades contra los departamentos puede hacer que se ignore a otros que tengan necesidad de participar Dividir o/combinar funciones incorrectamente; creando agendas o metas que entren en conflicto Combinar responsabilidades para procesos íntimamente relacionados puede crear conflictos interés; por Cambios ejemplo ycombinar Gestión de Incidentes y de Problemas o Gestión de de Configuración, Liberaciones
Un ejemplo de RACI Rol o Dueño Empleado del
Dueño del Proceso Servicio
Service Equipo Equipo Soporte Usuario Cliente Desk Externo de de Soporte Soporte #2 #3
Actividades del Proceso
46
Actividad #1
A
R
R
R
R
R
R
R
Actividad #2
A
C
R
C
Actividad #3
A
C
R
C/I
Actividad #4
A
R
C/I
Actividad #5
A
C
R
R
R
R
R
C
Actividad #6
A
C
R
R
R
R
R
C/I
Actividad #7
A
R
C/I
C/I
C/I
C/I
C/I
Conceptos generales
El Fundamento de ITIL ITIL está fundamentado en cinco publicaciones del ciclo de vida. Cada una proporciona una parte de la guía necesaria para un enfoque integral de acuerdo a lo requerido por la especificación del estándar ISO/IEC 20000. Cada una aborda las capacidades que tienen impacto directo en el desempeño de un proveedor de servicios. El fundamento tiene la finalidad de brindar estructura, estabilidad y fortaleza a las capacidades de gestión de servicios, con principios, métodos y herramientas perdurables. Esto sirve para proteger las inversiones y proporciona las bases necesarias para la medición, el aprendizaje y la mejora.
47
Conceptos generales
Las cinco publicaciones que constituyen el Fundamento de ITIL y que abordan las cinco fases del ciclo de vida de un servicio proporcionan orientación sobre la mejor práctica que puede ser utilizada por las organizaciones de TI independientemente de su tipo o tamaño.
Estrategia del Servicio – Proporciona orientación para desarrollar habilidades que permiten a la organización funcionar de manera más estratégica Diseño del Servicio – La orientación se enfoca en crear integridad a través del diseño y el desarrollo de los servicios y prácticas de gestión de servicios de forma integra, consistente y efectiva. –
a desarrollar mejorar lasa capacidades una delvaServicio tTransición ransición e fecti y eficiente Ayuda de servicios nuevos oymodificados la operación, para mientras controla los riesgos asociados con una falla o interrupción. Operación del Servicio – Orientación sobre los procesos del día a día que son requeridos para la entrega y gestión de servicios. Mejoramiento Continuo del Servicio – Orientación encaminada a la evaluación y mejora de la calidad de los servicios, procesos y del Ciclo de Vida del Servicio
Publicaciones Complementarias de ITIL Estas publicaciones, complementarias al Fundamento de ITIL, proporcionarán orientación que está dirigida específicamente a sectores de la industria, diferentes tipos de organizaciones, variedad de modelos operativos y arquitecturas tecnológicas. El propósito de estas publicaciones es ayudar a la implementación de los esfuerzos en distintos ambientes.
48
Conceptos generales
49
Conceptos generales
Procesos del Ciclo de Vida Estrategia del Servicio Representa las políticas y los objetivos.
Diseño del Servicio Una de las tres fases progresivas que representan el cambio y la transformación.
Entender los objetivos organizacionales y las necesidades del cliente: Convertir una estrategia de servicio en un plan para entregar los objetivos del negocio y diseñar servicios consistentes, Gestión Estratégica para Servicios de de alta calidad, efectivos en costo: TI Coordinación del Diseño Gestión del Portafolio de Servicios Gestión del Catálogo de Servicios Gestión de Relaciones del Negocio Gestión de Niveles de Servicio Gestión Financiera para Servicios de TI Gestión de la Disponibilidad Gestión de la Demanda Gestión de la Capacidad Gestión de la Continuidad de Servicios de TI Gestión de la Seguridad de la Información Gestión de Proveedores •
•
•
•
•
•
• •
•
• •
•
•
Transición del Servicio Una de las tres fases progresivas que representa el cambio y la trasformación.
Operación del Servicio Una de las tres fases progresivas que representa el cambio y la transformación.
Hacer la transición de servicios nuevos y modificados a operaciones:
Para lograr la efectividad y la eficiencia en la gestión, soporte y entrega de los servicios:
•
•
•
• • •
Planificación de la Transición y Soporte Gestión de Cambios Gestión de Activos del Servicios y de Configuraciones Gestión de Liberación e Implementación Validación y Pruebas del Servicio Evaluación del Cambio Gestión del Conocimiento
Gestión de Eventos Gestión de Incidentes Cumplimiento de Solicitudes Gestión de Problemas Gestión de Accesos Funciones: Service Desk Gestión Técnica Gestión de Operaciones de TI Gestión de Aplicaciones • • • • •
• • • •
50
Conceptos generales
Mejoramiento Continuo del Servicio Representa el aprendizaje y mejora. Continúa para crear y elevar el valor a través de mejoras y adiciones de funcionalidad:
Mejora en Siete Pasos
51
Conceptos generales
Métricas Técnicas Normalmente estas métricas se refieren a componentes del servicio y aplicaciones y son referencias como desempeño, disponibilidad, etc. Estas son cruciales para la entrega efectiva y eficiente de los servicios, pero no son de interés para el cliente. Métricas de Servicio Estas métricas reflejan el servicio de punta a punta y representan la vista del cliente sobre el servicio. Las métricas del servicio son calculadas utilizando métricas para la tecnología/componentes subyacentes. Métricas de Proceso Estas métricas ayudan a los interesados, clientes y Dueños de Procesos para evaluar y entender la salud y calidad general de un proceso. Los Factores Críticos de Éxito (CSFs), Indicadores Clave de Desempeño (KPIs) y métricas de actividad son definidos durante la etapa de diseño del proceso. El Mejoramiento Continuo del Servicio (CSI) utiliza estas métricas cuando identifica oportunidades de mejora.
52
Conceptos generales
Factor Crítico de Éxito (CSF) Algo que debe ocurrir para que un servicio, proceso, plan, proyecto u otra actividad tenga éxito.
Indicador Clave de Desempeño (KPI) Una métrica que es usada para ayudar a gestionar un servicio, proceso, plan, proyecto u otra actividad. Los KPIs son utilizados para medir el logro de los factores críticos de éxito.
Mientras que muchas métricas pueden ser establecidas y utilizadas, normalmente sólo las más importantes son utilizadas como KPIs, ya que estos son indicadores del nivel de logro de los CSFs. Ejemplos de KPIs que ayudarían a establecer si el CSF “Proteger los servicios de TI al implementar cambios” está siendo alcanzado podrían ser: la reducción del porcentaje de cambios no exitosos, o porcentaje de reducción de cambios que causan incidentes.
Dos Tipos de KPI: Cualitativo y Cuantitativo Aquí hay algunos ejemplos de acuerdo a lo mencionado en las publicaciones de ITIL: Ej emplo Cuali tativo : CSF: Mejorar la calidad del Servicio de TI KPI: incremento del 10% en la satisfacción del cliente en el manejo de Incidentes durante los próximos 6 meses. Métricas Requeridas: Calificación srcinal de satisfacción del cliente en el manejo de Incidentes
53
Conceptos generales
Calificación final de satisfacción del cliente en el manejo de Incidentes
Ej emplo Cuanti tativ o: CSF: Reducir Costos de TI KPI: Reducción de un 10% en los costos del manejo de Incidentes de impresoras Métricas requeridas Costo srcinal del manejo de Incidentes de impresoras Costo final del manejo de Incidentes de impresoras Costo del esfuerzo de mejora
Cuatro Categorías de KPI Al definir los KPIs se toma un enfoque balanceado para la evaluación de los CSFs para administrar la eficiencia, efectividad y la efectividad en el costo. Para este fin, normalmente se consideran las cuatro categorías de KPI, cada una de las cuales podría ser evaluada usando un enfoque cualitativo o cuantitativo:
Cumplimiento: Una medición del nivel de adopción del servicio o proceso. Los servicios o procesos pueden tener un buen valor percibido, buena calidad y desempeño rápido pero sólo ser adop tadas por una fracción de la organización. Calidad: Los indicadores de calidad típicamente están basados en la actividad y son establecidos para mediar la calidad de las actividades conforme se relacionan con el objetivo del servicio o el proceso de punta a punta. Desempeño: Métricas para la velocidad y el desempeño del servicio o proceso objetivo Valor: Reportes o Encuestas para medir la efectividad y el valor percibido por los interesados y usuarios
Es recomendado que no más de dos a cinco KPI sean definidos por cada CSF en algún momento y que el servicio o proceso no tenga más de dos a cinco CSF asociados en algún momento. Es recomendado que en las etapas tempranas de una iniciativa de mejoramiento continuo del servicio solo dos a tres KPI para cada CSF sean definidos, monitoreados y reportados. Conforme la madurez del servicio y de la gestión del servicio aumente, otros KPI pueden ser agregados. Basado en lo que es importante para el negocio y a la gestión de servicios, los KPI pueden cambiar en un periodo de tiempo. También tenga en mente que en cuanto los procesos de gestión de servicios sean implementados, los KPI cambiaran para los demás procesos. Como ejemplo, el incremento de la solución en el primer contacto es un KPI común para la gestión de incidentes. Este es un buen KPI para iniciar, pero en cuanto se implemente la gestión de problemas esto deberá cambiar. Uno de los objetivos de la gestión de problemas es reducir el número de soluciones en el primer contacto. En este caso una reducción en el primer contacto es una tendencia positiva.
54
Conceptos generales ¿El KPI es adecuado para su uso? Un aspecto importante a considerar es si el KPI es adecuado para su uso. Las principales preguntas son:
¿El indicador de desempeño realmente nos indica acerca del alcance de la meta? Si fallamos en el alcance de la meta para este indicador, ¿quiere decir que fallamos en alcanzar alguna de nuestras metas? Si tenemos éxito en ciertas metas, ¿quiere decir que alcanzamos nuestras metas?
¿Qué tan fácil es interpretar el indicador de desempeño? ¿Nos ayuda a decidir un
curso de acción? ¿Cuando necesitaremos la información? ¿Qué tan seguido? ¿Qué tan rápidamente la información debe estar disponible?
¿Qué tanto tiempo este indicador es estable y veraz? ¿Es sensible a influencias externas incontrolables? ¿Qué cantidad de esfuerzo es necesario para un cambio que no es marginal? ¿Qué tan fácil es cambiar el indicador de desempeño? ¿Qué tan fácil es adaptar el sistema de medición para circunstancias cambiantes o cambios en nuestras metas para la provisión de los servicios de TI? ¿Qué tanto el indicador de desempeño puede ser medido ahora? ¿Bajo qué condiciones las mediciones pueden continuar? ¿Qué condiciones impiden las mediciones? ¿Qué condiciones entregan resultados sin sentido? ¿Quién es el propietario de este KPI? ¿Quién es el responsable de recolectar y analizar los datos? ¿Quién es el que autoriza las mejoras basadas en la información?
55
Conceptos generales
El Ciclo de Vida de Deming es un ciclo de efectividad basado en la calidad para gestión de procesos que se le atribuye a W. Edwards Deming siendo su mensaje clave: ‘Si no lo puedes medir, no lo puedes gestionar .’
El ciclo consta de las siguientes cuatro etapas clave: PLANIFICAR
Diseñar o revisar los procesos que soportan los servicios de TI
HACER
Implementar el plan y gestionar los procesos
VERIFICAR
Medir los procesos y los Servicios de TI, comparar con los objetivos y generar reportes
ACTUAR
Planear e implementar cambios para mejorar los procesos
Estas etapas van seguidas de una fase de consolidación la cual previene tener una regresión hacia viejos comportamientos. Dentro del marco de ITIL, la aplicación del Ciclo de Deming tiene la finalidad de alcanzar una meta de mejora regular y continua. Visite www.deming.org para mayor información sobre el Ciclo de Deming para la mejora de procesos.
56
Estrategia del Servicio
57
Estrategia del Servicio
Objetivos de Estrategia del Servicio:
58
La capacidad para definir cómo se crea y entrega el valor Un medio para identificar las oportunidades para proveer servicios y cómo explotarlos Un modelo claro de provisión de servicios, que describe cómo serán entregados y con qué fondos serán financiados los servicios, a quién le serán entregados y para qué propósito Los medios para entender la capacidad de la organización requerida para entregar la estrategia Documentación y coordinación de cómo son utilizados los activos del servicio para entregar el servicio y cómo optimizar su desempeño Abarca procesos que definen la estrategia de la organización, cuáles servicios lograrán la estrategia, qué nivel de inversión será requerido, y a qué niveles de demanda, y los medios para garantizar que exista una relación de trabajo entre el cliente y el proveedor de servicios
Estrategia del Servicio
59
Estrategia del Servicio
La Estrategia del Servicio establece la dirección al identificar, adoptar e implementar un enfoque consistente y establecer los estándares para:
60
Ligar resultados, que son críticos para el éxito del cliente (interno o externo) con las actividades del proveedor. El cliente verá al proveedor de servicios como un contribuyente al éxito de su organización al entregar valor Garantizar que se adopte un enfoque consistente y repetible para definir estrategias y servicios, el cual identificará y entregará valor a los clientes e interesados. Esto sólo podrá ser logrado si el proveedor de servicios es capaz de identificar los tipos de servicios y los niveles que verdaderamente entregan valor. Habilitar al proveedor de servicios para identificar y reaccionar con rapidez ante los cambios en el ambiente de negocios, permitiendo así al cliente lograr una ventaja competitiva Desarrollar y mantener un Portafolio de Servicios que soporte las metas de la organización, entregue valor y logre un retorno de inversión positivo Mejorar la comunicación entre el cliente y el proveedor de servicios a través del diálogo honesto y directo para que todas las partes tengan un claro entendimiento de lo que se requiere, así como de los pasos a seguir Facilitar la capacidad de un proveedor de servicios de estructurarse a sí mismo para entregar servicios de forma eficiente y efectiva
Estrategia del Servicio
La Gobernabilidad vincula a TI con el negocio para su beneficio mutuo. Los servicios permiten que el negocio logre la gobernabilidad. La orientación provista a través de la gobernabilidad es lo que ayuda a definir directrices, reglas y políticas comunes que el negocio y TI usan para dirigir al negocio. Las estrategias de ITSM tienden a fallar porque TI construye un proceso o estructura basado en cómo cree que debería funcionar el negocio y no en base a trabajar dentro de las estructuras de gobernabilidad o procesos actuales. Para que la gobernabilidad sea exitosa, es necesario ser capaz de monitorear, dirigir y evaluar los planes, políticas y estrategias. Así, la gobernabilidad aplica un enfoque gestionado consistentemente a todos los niveles del negocio. Esto garantiza que ha sido creada una estrategia clara, y también define las políticas para lograr la estrategia. A su vez, las políticas definen los parámetros o límites de lo que el negocio no hace como parte sus operaciones.
61
Estrategia del Servicio
La mayoría de los aspectos de Gestión de Servicios aplican a todos los tipos de proveedores de servicios; sin embargo, los clientes, contratos, competencia, espacios de mercado, ganancias y estrategias pueden cambiar su significado dependiendo de los siguientes tres tipos:
Tipo I – proveedor de servicios interno: Un proveedor de servicios interno que está incrustrado dentro de la unidad de negocio. Puede haber varios proveedores de servicios de Tipo I dentro de una organización Tipo II – unidad de servicios compartidos: Es un proveedor de servicios interno que proporciona Servicios compartidos de TI a más de una unidad de negocios. Tipo III – proveedor de servicios externo: Es un proveedor de servicios que proporciona Servicios de TI a clientes externos
Mientras que en los conceptos de ITSM normalmente se describe como uno de estos tipos para un tipo de proveedor de servicios de TI, la mayoría de los negocios tienen más de un proveedor de servicios de TI. Por ejemplo, algunas unidades de TI están alineadas a una unidad de negocio, mientras que otras comparten servicios o inclusive pueden estar por outsourcing. Ya sea por outsourcing o trabajando directamente con usuarios externos, La estrategia del servicio proporciona orientación sobre cómo interactúan las organizaciones de TI con los usuarios y cómo se maneja la relación.
62
Estrategia del Servicio
El Portafolio de Servicios es un conjunto de servicios gestionados por un proveedor de servicios y representa los compromisos y las inversiones del proveedor a través de todos los clientes y espacios de negocio. El Portafolio de Servicios también representa los compromisos contractuales, planes de mejora de servicios en curso iniciados por Mejoramiento Continuo del Servicio así como el desarrollo de nuevos servicios. El Portafolio de Servicios también puede incluir servicios de terceras partes. El Portafolio de Servicios representa tres áreas separadas:
Servicios bajo Consideración (Pipeline ) representa aquellos servicios que aún están bajo consideración o desarrollo, pero todavía no disponibles para los clientes, y normalmente no es visible para los clientes. Catálogo de Servicios representa todos los servicios actualmente en vivo (en producción) así como aquellos disponibles para implantación. El catálogo soporta la venta y entrega de los servicios de TI y es parte del portafolio visible para los clientes Servicios Retirados son aquellos que se han hecho obsoletos o han sido retirados. Estos servicios están disponibles para los nuevos clientes o contratos sólo cuando se lleva a cabo un caso especial de negocios.
63
Estrategia del Servicio
Los Servicios son creados para habilitar el desempeño de las actividades del negocio, lo cual ayuda al negocio a lograr sus objetivos. Los Servicios son demandados cada vez que un negocio desempeña una actividad. Las actividades de negocio que tienden a ser desempeñadas en patrones, son completadas por los activos de los clientes, tales como gente, procesos y aplicaciones. Estos patrones de actividad de negocio, conocidos como PBAs, incluyen interacciones con asociados, proveedores, clientes y otros interesados. Como los patrones de actividad del negocio logran los resultados del negocio, es importante que los PBAs sean comprendidos claramente y estén alineados a los servicios. Una vez que un PBA ha sido identificado, se debe preparar un perfil del PBA y se deben documentar los detalles del PBA.
64
Estrategia del Servicio
Riesgo: Un posible evento que puede causar daño o pérdida o afectar la habilidad de lograr objetivos. Un riesgo es medido por la probabilidad de una amenaza, la vulnerabilidad del activo ante esa amenaza y el impacto que tendría si ocurriera. El riesgo también puede ser definido como incertidumbre de un resultado y puede ser usado en el contexto de medir la probabilidad de resultados positivos así como negativos.
65
Estrategia del Servicio
Un caso de negocio demuestra el beneficio neto del proyecto para la organización. Incluye analizar el costo del proyecto y después compararlo con los beneficios del proyecto. Comúnmente contiene un análisis de lo que sucedería si el proyecto no continuara. Existen tres desafíos al preparar un caso de negocio: Estimar los costos
66
Cuantificar los beneficios que son indirectos e intangibles
Obtener información precisa del desempeño del negocio y de TI
Estrategia del Servicio
67
Estrategia del Servicio
La Gestión del Portafolio de Servicios es el proceso responsable de definir qué servicios serán ingresados en el Portafolio de Servicios y cómo serán rastreados esos servicios y progresarán a lo largo del ciclo de vida. Es el guardián para el proveedor de servicios, y garantiza que los servicios provistos contribuyan a los objetivos estratégicos y los resultados esperados del negocio.
68
Estrategia del Servicio
Los Objetivos de la Gestión del Portafolio de Servicios son:
Proporcionar un proceso y mecanismos para permitir a la organización investigar y decidir qué servicios proveer, con base en el análisis del retorno potencial y del nivel aceptable de riesgos. Mantener el portafolio actualizado con los servicios provistos, articulando las necesidades del negocio que cada servicio cubre así como los resultados del negocio que soporta. Proporcionar un mecanismo para que la organización evalúe cómo es que los servicios lo ayudan a alcanzar su estrategia y responder a los cambios en sus ambientes internos o externos Controlar qué servicios son ofrecidos, bajo qué condiciones y a qué nivel de inversión Dar seguimiento a la inversión en servicios a través de su ciclo de vida, permitiendo así a la organización evaluar su estrategia, así como su habilidad para desempeñarse con relación a esa estrategia Analizar cuáles servicios ya no son viables y cuándo deben ser retirados
69
Estrategia del Servicio
El interés fundamental de Gestión del Portafolio de Servicios es si el proveedor de servicios es capaz de generar valor a partir de los servicios. La Gestión del Portafolio de Servicios compara
las inversiones en servicios a las cuales se da seguimiento contra los resultados deseados del negocio. Antes de que los proveedores internos de servicios puedan comparar las inversiones con los resultados, ellos necesitan trabajar con las unidades de negocio en la organización para relacionar cada servicio con los resultados del negocio. Debido a que cada servicio necesita generar directamente un ingreso, o soportar a los servicios que generan los ingresos, los proveedores de servicios externos tienden a evaluar el valor más directamente. La rentabilidad es facilitada por la generación de ingresos de una forma eficiente. La Gestión del Portafolio de Servicios evalúa el valor de los servicios a través de su ciclo de vida y debe ser capaz de comparar qué es lo que los nuevos servicios han ofrecido por encima de los servicios retirados a los que reemplazaron.
70
Estrategia del Servicio
71
Estrategia del Servicio
La Gestión Financiera para Servicios de TI ayuda a los proveedores de servicios de TI a jugar un papel estratégico para el negocio al cuantificar el valor y la contribución de TI, así como cuantificar las oportunidades del negocio que los servicios de TI permitirán. Específicamente, la Gestión Financiera proporciona a la organización la cuantificación del valor de los servicios de TI y de los activos para proveer estos servicios, y proporciona la cualificación del pronóstico operacional, en forma de presupuestos. La Gestión Financiera es el proceso responsable de gestionar el presupuesto, la contabilidad y los requerimientos de cargos de un proveedor de servicios de TI.
72
Estrategia del Servicio
Los objetivos de la Gestión incluyen:
Evaluar el impacto financiero que tendrán las estrategias nuevas o modificadas en el proveedor de servicios Obtener los fondos para gestionar la provisión de los servicios Facilitar una buena administración del servicio y de los activos del cliente para garantizar que la organización cumpla sus objetivos. Esto debe hacerse conjuntamente con Gestión de Activos del Servicio y de Configuraciones y con Gestión del Conocimiento Entender la relación entre los gastos y los ingresos y garantizar que los dos estén balanceados de acuerdo con las políticas financieras de la organización Administrar y reportar los gastos en la provisión de servicios a nombre de los interesados de la organización.
Ejecutar las políticas y prácticas financieras en la provisión de servicios
Rendir cuentas sobre el dinero gastado en la creación, entrega y soporte de los servicios
Pronosticar los requerimientos financieros de la organización para poder cumplir con sus compromisos de servicio con sus clientes, y cumplir con los requerimientos regulatorios y legales Cuando aplique, definir un marco de referencia para poder recuperar los costos de la provisión de servicios a partir del cliente
73
Estrategia del Servicio
Normalmente, el proceso de Gestión Financiera es una función separada que reporta ya sea al CIO o al CFO, con algunos reportes cruzados entre las dos áreas, requiere un entendimiento de finanzas y de negocios, así como del mundo de la tecnología. Las políticas y prácticas financieras dentro de TI deben ser consistentes con las utilizadas en otros departamentos de la organización. Esto no sólo permite reportar y comunicar de mejor manera entre las distintas partes, sino que también es una buena práctica de Gestión Financiera, la cual frecuentemente es cubierta por las leyes y regulaciones.
74
Estrategia del Servicio
75
Estrategia del Servicio
La Gestión de Relaciones del Negocio permite a los gerentes crear vínculos entre el proveedor de servicios y los clientes a nivel estratégico y táctico. Estos vínculos aseguran que el proveedor de servicios comprenda los requerimientos de negocio del cliente y pueda proveer los servicios que cubran estas necesidades. La medida básica de si este propósito se está cumpliendo o no es el nivel de satisfacción del cliente .
76
Estrategia del Servicio
Los objetivos de Gestión de Relaciones del Negocio incluyen:
Garantizar que el proveedor de servicios entienda la perspectiva del cliente sobre el servicio, y por lo tanto sea capaz de dar prioridad a sus servicios y activos del servicio apropiadamente. Garantizar altos niveles de satisfacción del cliente, lo que indica que el proveedor de servicios está cumpliendo con los requerimientos del cliente. Establecer y mantener una relación constructiva entre el proveedor de servicios y el cliente basada en el entendimiento del cliente y de los factores que influencian su negocio Identificar los cambios en el ambiente del cliente que podrían impactar potencialmente el tipo, nivel o utilización de lo servicios provistos Identificar las tendencias tecnológicas que podrían impactar potencialmente el tipo, nivel o utilización de los servicios provistos Establecer y articular los requerimientos de nuevos servicios o cambios a los servicios existentes Garantizar que el proveedor de servicios está cubriendo las necesidades de negocio del cliente Trabajar con los clientes para garantizar que los servicios y niveles de servicio puedan entregar valor Mediar en casos donde exista conflicto entre los requerimientos de servicio de diferentes unidades de negocio Establecer procesos formales de queja y escalamiento para el cliente.
77
Estrategia del Servicio
La Gestión de Relaciones del Negocio se centra en entender cómo es que los servicios de TI cubren los requerimientos del cliente. Esto requiere entender y comunicar lo siguiente: Los resultados de negocio deseados por el cliente Los servicios actualmente ofrecidos al cliente, y cómo son utilizados Cómo están siendo ofrecidos actualmente los servicios, incluyendo la responsabilidad por los servicios, los niveles de servicio que han sido acordados, la calidad de los servicios entregados y cualquier cambio anticipado El impacto potencial de las tendencias tecnológicas en los servicios actuales y el cliente Niveles de satisfacción del cliente y planes de acción para enfrentar las causas de cualquier insatisfacción Optimización futura de servicios La representación del proveedor de servicios ante el cliente. Esto puede significar presentar inquietudes a cerca de compromisos que el negocio ha hecho con TI que no están siendo cumplidos. Debido a que la Gestión de Relaciones del Negocio depende de una variedad de otros procesos y funciones de gestión de servicios, es importante establecer fronteras y responsabilidades claras para cada uno. Un ejemplo de esto incluye Gestión de Niveles de Servicio, un proceso que es similar debido al importante nivel de interface que tiene con los clientes. La siguiente tabla
describe tres aspectos de estos dos procesos para ayudarle a entender sus diferencias.
78
Estrategia del Servicio
Propósito
Enfoque
Medida Básica
Gestión de Relaciones del Negocio Establecer y mantener una Relación de Negocios entreel proveedor de servicios y el cliente basada en el entendim iento del cliente y sus necesidades de negocio.
Gestión de Niveles de Servicio Negociar Acuerdos de Niveles de Servicio (Términos de la Garantía) con los clientes y asegurar que todos los procesos de gestión de servicios, Acuerdos de Nivel Operacional y contratos de soporte sean adecuados a Identificar las necesidades del cliente los objetivos de nivel de servicio (Utilidad y Garantía) y asegurar que el acordados. proveedor de servicios sea capaz de cubrir estas necesidades. Estratégico y táctico – se enfoca en la relación general entre el proveedor de servicios y su cliente, y en cuáles servicios entregará el proveedor de servicios para cubrir las necesidades del cliente.
Táctico y operacional – el enfoque está en lograr un acuerdo en el nivel de servicio que será entregado para los servicios nuevos y existentes, y si el proveedor de servicios fue capaz de cumplir esos acuerdos.
Satisfacción del Cliente, también un Alcanzar los niveles acordados de incremento en la intención del cliente servicio (lo que lleva a la satisfacción de usar mejor y pagar por el servicio. del cliente). Otra métrica es si los clientes están deseando recomendar el servicio a otros clientes (potenciales).
Derechos Reservados de ©Crown 2011. Reproducido bajo licencia de la OGC. Tabla 4.10 Estrategia del Servicio 4.5.2.1
79
Diseño del Servicio
80
Diseño del Servicio
La etapa del ciclo vida de Diseño del Servicio se enfoca en el diseño de servicios nuevos o cambios a los servicios existentes. Traduce la estrategia del servicio en un plan centrado en entregar los objetivos del negocio. Es importante tener un enfoque holístico para garantizar un diseño integral y exitoso. Resulta igualmente importante, adoptar este enfoque al modificar o corregir cualquier elemento individual del diseño. En otras palabras, cuando una aplicación está siendo diseñada y desarrollada, no debe de hacerse en forma aislada. Otros aspectos a considerar incluirían el impacto en el servicio global, los sistemas y herramientas de gestión, las arquitecturas y tecnologías, y los procesos, las mediciones y métricas requeridas para gestionar tanto el servicio como el Portafolio de Servicios.
81
Diseño del Servicio
82
Diseño del Servicio
Los beneficios de un buen Diseño del Servicio incluyen:
Menor Costo Total de Propiedad (TCO): el costo de la propiedad sólo puede ser minimizado si todos los aspectos de los servicios, procesos y tecnología son diseñados adecuadamente e implementados de acuerdo al diseño Mejor calidad del servicio: tanto la calidad del servicio como la calidad operacional se elevarán Mejor consistencia del servicio, ya que los servicios son diseñados dentro de la estrategia, arquitectura y restricciones corporativas. Implementación más fácil de servicios nuevos o modificados, ya que existe un Diseño del Servicio integrado y completo, así como la producción de Paquetes de Diseño del Servicio (SDP) completos. Mejor alineación con el servicio: involucramiento desde la concepción del servicio garantizando que los servicios nuevos o modificados coincidan con las necesidades del negocio, con servicios diseñados para cubrir los Requerimientos de Nivel de Servicio. Desempeño del servicio más efectivo: con la incorporación y el reconocimiento de los Planes de Capacidad, Financiero, Disponibilidad y Continuidad del Servicio de TI Mayor gobernabilidad de TI: ayuda con la implementación y comunicación de un conjunto de controles para la gobernabilidad efectiva de TI Gestión de servicios y procesos de TI más efectiva: los procesos serán diseñados con calidad óptima y de forma efectiva en costo mediciones y métricas más completas y Mejor información y toma de decisiones: efectivas permitirán una mejor toma de decisiones y el mejoramiento continuo de las prácticas de gestión de servicios en la etapa de diseño del ciclo de vida del servicio.
83
Diseño del Servicio
Muchas veces, la falta de preparación y gestión se traduce en la falla de diseños, planes y proyectos. Ya sea que se esté preparando la implementación de Gestión de Servicios de TI como una práctica o se estén diseñando servicios nuevos o modificados, asegurar el uso efectivo y eficiente de las cuatro Ps es esencial para el éxito:
Personas Se refiere a la organización de personas a través de las funciones, roles, equipos, grupos, divisiones y departamentos. Esto es definido usando diagramas organizacionales y descripciones de puesto. Procesos Se refiere a toda la documentación relevante de los procesos, como políticas, diagramas de procesos, procedimientos e instrucciones de trabajo. Productos/Tecnología Se refiere a los servicios, la tecnología y las herramientas. Proveedores/Socios Se refiere a los proveedores, fabricantes y vendedores.
84
Diseño del Servicio
El paquete de Diseño del Servicio (SDP) representa los documentos que definen todos los aspectos de un servicio de TI y sus requerimientos a través de cada etapa de su ciclo de vida.
Durante la etapa de diseño, un SDP debe ser preparado para cada nuevo servicio, cuando se planean cambios mayores a un servicio, para la eliminación de un servicio, o cuando se hacen cambios al mismo Paquete de Diseño del Servicio. El paquete de diseño, que contiene todos los aspectos y requerimientos del servicio a lo largo de las fases subsecuentes de su ciclo de vida, será entregado entonces a Transición del Servicio y a Operación del Servicio.
85
Diseño del Servicio
Se recomienda adoptar un enfoque global e integrado para las distintas actividades del diseño para incluir específicamente:
86
Soluciones del Servicio, incluyendo todos los requerimientos funcionales, recursos y capacidades necesarias y acordadas Tecnologías, herramientas y Sistemas de Gestión de la información, especialmente el Portafolio de Servicios para la gestión y el control de los servicios a través de su ciclo de vida Arquitecturas de tecnología y gestión, así como herramientas requeridas para proporcionar los servicios Métricas, métodos y sistemas de medición para los servicios, las arquitecturas y los componentes que las constituyen, así como los procesos. Procesos necesarios para diseñar, hacer la transición, operar y mejorar los servicios.
Diseño del Servicio
87
Diseño del Servicio
88
Garantizar el diseño consistente de servicios apropiados, sistemas de información de gestión de servicios, arquitecturas, tecnología, procesos, información y métricas para alcanzar y cubrir los resultados y los requerimientos actuales y futuros del negocio. Coordinar todas las actividades del diseño a través de los proyectos, cambios, proveedores y equipos de soporte así como manejar los calendarios, recursos y conflictos cuando sea necesario Planear y coordinar los recursos y capacidades requeridas para diseñar servicios nuevos o modificados Generar los paquetes de diseño del servicio (SDPs) con base en el estatuto del servicio y las solicitudes de cambio Garantizar que se generen diseños del servicio y/o SDPs apropiados y que sean entregados a Transición del Servicio según lo acordado Gestionar los criterios de calidad, requerimientos y puntos de entrega entre la etapa de Diseño del Servicio y Estrategia del Servicio y Transición del Servicio Garantizar que todos los modelos del servicio y todos los diseños de soluciones del servicio se ajusten a los requerimientos estratégicos, de arquitectura, gobernabilidad y otros requerimientos corporativos. Mejorar la efectividad y la eficiencia de las actividades y procesos de diseño del servicio Garantizar que todas las partes adopten un marco común de referencia de prácticas de diseño reutilizables en forma de actividades, procesos y sistemas de soporte, cuando aplique Monitorear y mejorar el desempeño de la etapa del ciclo de vida de diseño del servicio
Diseño del Servicio
Ayudar y soportar cada proyecto u otro cambio a través de todas las actividades y los procesos de Diseño del Servicio Mantener las políticas, lineamientos, estándares, presupuestos, modelos, recursos y capacidades de las actividades y procesos de Diseño del Servicio Coordinar, priorizar y calendarizar todos los recursos de Diseño del Servicio para satisfacer las demandas de recursos en conflicto para proyectos y cambios Planear y pronosticar los recursos que se requerirán para cubrir la demanda futura para las actividades de Diseño del Servicio Revisar, medir y mejorar el desempeño de todas las actividades y procesos de Diseño del Servicio Garantizar que todos los requerimientos sean tratados apropiadamente en los diseños del servicios, en particular los requerimientos de utilidad y garantía Garantizar la generación de diseños de servicios y/o SDPs y su entrega a Transición del Servicio
89
Diseño del Servicio
90
Diseño del Servicio
Gestión de Niveles de Servicio (SLM) es responsable de acordar y documentar los objetivos y responsabilidades de niveles de servicio según se relacionan con los Acuerdos de Niveles de Servicio (SLAs) y los Requerimientos de Niveles de Servicio (SLRs) para todas las actividades dentro de TI. El contenido del Portafolio de Servicios y del Catálogo de Servicios debe mantenerse actualizado y en buen nivel para proporcionar información precisa y de calidad a SLM.
91
Diseño del Servicio
Los objetivos de la Gestión de Niveles de Servicio son:
92
Definir, documentar, acordar, monitorear, medir, reportar y revisar el nivel de los servicios de TI proporcionados y fomentar las medidas correctivas cuando sea adecuado Proporcionar y mejorar las relaciones y la comunicación con el negocio y los clientes de manera conjunta con gestión de la relación con el negocio. Garantizar que se desarrollen objetivos específicos y medibles para todos los servicios de TI Monitorear y mejorar la satisfacción del cliente con la calidad de los servicios entregados Garantizar que TI y los clientes tengan una clara y precisa expectativa del nivel de servicios a ser entregado Garantizar que aun cuando todos los objetivos acordados se cumplan, los niveles de servicio entregados sean sujetos de un mejoramiento continuo proactivo y efectivo en costo.
Diseño del Servicio
El proceso de Gestión de Niveles de Servicio debe incluir:
Cooperación con el proceso de Gestión de relaciones de Negocio: esto incluye el desarrollo de relaciones con el negocio conforme se requiera para alcanzar los objetivos del proceso de SLM Negociación y acuerdo de los requerimientos y objetivos de niveles de servicios actuales y futuros y la documentación y gestión de los SLRs para t odos los servicios en operación así como para los de servicios nuevos o modificados propuestos. Desarrollo y gestión de OLAs apropiados para garantizar que los objetivos estén alineados con los objetivos de los SLAs Revisión de los acuerdos con proveedores y de los contratos ligados a ellos con Gestión de Proveedores para garantizar que los objetivos estén alineados con los objetivos de los SLAs Prevención proactiva de fallas de servicios, reducción de riesgos en los servicios y mejora en la calidad del servicio, en conjunto con todos los otros procesos Reportar y gestionar todos los logros de nivel de servicio y revisar todas los incumpl imientos en el SLA Verificación periódica, renovación y/o revisión de los SLAs, alcance del servicio y OLAs según sea conveniente Identificar oportunidades de mejora para su inclusión en el registro CSI
Revisión de mejoras en el registro CSI (SIP) para la gestión, planeación e Fomentary ypriorización coordinar Planes de mejora del servicio implementación de mejoras en el servicio y los procesos
93
Diseño del Servicio
94
Diseño del Servicio
SLA basado en el Servicio Este tipo de SLA resulta ser un enfoque eficiente cuando un acuerdo aplicará a todos los clientes de un mismo servicio, tal como el correo electrónico. Para aumentar la efectividad de este tipo de SLA, puede ser deseable incluir varias clases (niveles) tales como oro, plata y bronce. SLA basado en el Cliente En algunos casos, puede ser deseable desarrollar un acuerdo con un grupo de clientes particular que cubrirá todos los servicios que ellos usan. Un ejemplo típico sería un acuerdo con el departamento de finanzas de la organización, que cubre todos los servicios que ellos usan, tales como los sistemas financieros, de contabilidad, nómina y facturación, así como cualquier otro. Frecuentemente los clientes prefieren este enfoque porque en un solo documento se trata todo lo que les atañe y les simplifica las cosas. SLAs Multinivel Algunas organizaciones han elegido adoptar una estructura de SLA multinivel. Por ejemplo, una estructura de tres capas como la siguiente:
Nivel Corporativo: Este cubrirá todos los temas genéricos de la gestión de niveles de servicios adecuados a cada cliente a través de toda la organización. Estos incluyen temas que es más probable que sean poco volátiles, de tal modo que las actualizaciones se requieran con menor frecuencia Nivel Cliente: Este cubrirá todos los temas de la Gestión de Niveles de Servicios relevantes al grupo de clientes en particular o a la unidad de negocio, sin importar el servicio que esté siendo utilizado 95
Diseño del Servicio
Nivel Servicio: Este cubrirá todos los temas del Gestión de Niveles de Servicios relevantes al servicio en específico, en relación a un grupo de clientes específico (uno para cada servicio cubierto por el SLA)
Requerimientos de Niveles de Servicio (SLRs) Los SLRs representan los requerimientos de servicios de TI de un cliente, y están basados en los objetivos del negocio. Ellos sirven como base para negociar los objetivos de niveles de servicio acordados. Se utiliza un SLR para documentar y acordar los objetivos y responsabilidades para cada servicio nuevo o modificado propuesto Plan de Mejora del Servicio (SIP) Un SIP es un plan de acción formal con la finalidad de implementar mejoras a un proceso o servicio de TI. Todas las acciones y los planes son documentados y acordados entre los proveedores de servicios y sus propios proveedores de ser necesario. Los SIPs son usados para gestionar el progreso de las acciones de mejora acordadas. Revisión del Servicio Las reuniones con los clientes son llevadas a cabo periódicamente (normalmente de forma mensual o trimestral como mínimo) para revisar los logros del servicio durante el último periodo y para prever cualquier situación para el siguiente periodo. Tabla SLAM Las Tablas SLAM (Monitoreo de SLA) pueden ser utilizadas como una portada de los reportes de servicio para presentar un vistazo general comparativo de los logros contra los objetivos. Las tablas (también SLAM resultan más como efectivas si seRAG utilizan ejemplo, Rojo, Ámbar, Verde se conocen gráficas por códigos las siglasdedecolor, estos por colores en inglés).
96
Diseño del Servicio
97
Diseño del Servicio
Gestión de Relaciones de Negocio La meta de Gestión de Relaciones de Negocio es garantizar que la Gestión de Niveles de Servicio represente en su planeación las prioridades del negocio y las necesidades de los clientes Gestión del Catálogo de Servicios La Gestión de Niveles de Servicios utiliza el Catálogo de Servicios para entender qué procesos de negocio son soportados por qué servicios. A su vez, la Gestión de Niveles de Servicios proporciona información a Gestión del Catálogo de Servicios para ayudar a garantizar que el Catálogo de Servicios se mantenga actualizado y preciso. Gestión de Incidentes Los datos de Gestión de Incidentes son utilizados para medir el desempeño contra los objetivos del SLA. Los objetivos de tiempos de restauración del servicio y otros objetivos de soporte relacionados son determinados por la Gestión de Niveles de Servicios y cumplidos por Gestión de Incidentes. Gestión de Proveedores La Gestión de Niveles de Servicios trabaja con Gestión de Proveedores para garantizar que los contratos con los proveedores estén alineados con los SLAs y con las necesidades del negocio. La Gestión de Proveedores también es responsable de dar seguimiento al desempeño de los proveedores y garantizar que todos los objetivos del SLA mencionados en el contrato sean cumplidos. Gestión de la Disponibilidad, Capacidad, Continuidad de Servicios de TI y Seguridad de la Información 98
Diseño del Servicio
Los Objetivos de Niveles de Servicio son definidos por cada uno de los procesos anteriormente mencionados conforme se relaciona con su área de dominio. Cada proceso debe validar que los objetivos sean realistas y monitorear las operaciones diarias del proceso para confirmar que los objetivos estén siendo cumplidos.
Gestión Financiera para Servicios de TI La Gestión Financiera es responsable de garantizar que los costos predichos y los costos reales de entregar los niveles de servicio solicitados por el cliente sean validados y estén alineados. El proceso también es responsable de gestionar la efectividad general de los costos del servicio. Coordinación deldel Diseño La Coordinación Diseño es responsable de que se completen todas las actividades de Diseño del Servicio durante la etapa de Diseño del Servicio. Los SLRs y los objetivos de servicio asociados son desarrollados por SLM y deben ser incluidos en el diseño del servicio nuevo o modificado.
Gestión de Niveles de Servicio – Una aplicación práctica 1. Permita a sus clientes describir que es lo más importante de los servicios que usted ofrece. ¿Qué los impacta negativamente? 2. Defina impacto y urgencia desde la perspectiva del cliente. 3. Asegúrese que usted estáentender. midiendo¿Un la provisión servicio de para la manera que sus clientes puedan 99.999%del significa algo ellos? 4. Asegúrese que sus servicios puedan cumplir las metas del SLA. 5. Encueste a sus clientes. Arregle lo negativo cuando sea justificable hacerlo y celebre lo positivo.
99
Diseño del Servicio
100
Diseño del Servicio
Los objetivos de Gestión del Catálogo de Servicios son:
Gestionar la información contenida dentro del catálogo de servicios Garantizar que el catálogo de servicios sea preciso y refleje los detalles, estado, interfaces y dependencias actuales de todos los servicios que se están operando o están siendo preparados para operar en el ambiente de producción, de acuerdo a las políticas definidas. Garantizar que el catálogo de servicios esté a disponibilidad de aquellos aprobados para tener acceso a él de forma que soporte el uso efectivo y eficiente de la información del catálogo de servicios Garantizar que el catálogo de servicios soporte las necesidades evolutivas de todos los otros procesos de gestión de servicios con respecto a información del catálogo de servicios, incluyendo toda la información relativa a interfaces y dependencias.
101
Diseño del Servicio
El proceso de Gestión del Catálogo de Servicios cubre:
La contribución a la definición de los servicios y los paquetes de servicio El desarrollo y mantenimiento de descripciones del servicio y los paquetes de servicio apropiados para el catálogo del servicio
102
La generación y mantenimiento de un catálogo serviciosde preciso Interfaces, dependencias y consistencia entre eldecatálogo servicios y el portafolio de servicios general Interfaces y dependencias entre todos los servicios y los servicios de soporte dentro del catálogo de servicios y el CMS Interfaces y dependencias entre todos los servicios y los componentes de soporte y elementos de configuración (CIs) dentro del catálogo de servicios y el CMS
Diseño del Servicio
103
Diseño del Servicio
104
Diseño del Servicio
105
Diseño del Servicio
106
Diseño del Servicio
Cada proveedor de servicios debe contar con procesos establecidos para gestionar a sus proveedores y contratos. El nivel de impacto que tenga el proveedor sobre el negocio debe afectar la cantidad de participación que el proveedor tenga en la estrategia del negocio. Los proveedores con un menor valor de contribución tendrán una interacción limitada con el negocio y serán manejados a un nivel operacional. Los proveedores con un mayor valor de contribución estarán más involucrados en el desarrollo y la elaboración de la estrategia del negocio y habrá una mayor interacción y esfuerzo por parte del proveedor de servicios. El proceso de Gestión de Proveedores debe incluir:
Implementación y cumplimiento de la política de proveedores Mantenimiento de un Sistema de Información de la Gestión de Proveedores y Contratos (SCMIS) Clasificación de proveedores y contratos y evaluación de riesgos Evaluación y selección de proveedores y contratos Desarrollo, negociación y acuerdo de contratos Revisión, renovación y terminación de contratos Gestión de proveedores y desempeño de proveedores Identificación de oportunidades de mejora para su inclusión dentro del registro CSI y la implementación de planes de mejora del servicio y proveedores Mantenimiento de contratos estándar, términos y condiciones Gestión de disputas contractuales Gestión de proveedores sub-contratados
107
Diseño del Servicio
Categorización de proveedores La categorización de proveedores es crucial para manejar la cantidad de tiempo y esfuerzo que se invierte en ciertos proveedores con base en el valor potencial y la importancia que ellos conllevan. La forma más efectiva de categorizar a los proveedores es evaluar el riesgo y el impacto asociado con el proveedor y determinar el valor potencial para el negocio. Las categorías clave de proveedores incluyen: Estratégico: Esta categoría es para proveedores que manejan información confidencial y estratégica y que contribuyen a los planes a largo plazo. Se requiere un alto nivel de contacto y la relación normalmente es manejada a un nivel de alta gerencia (senior). Táctico: Esta categoría es para proveedores que proporcionan actividades comerciales. Se recomienda un contacto y revisión de desempeño frecuente. Normalmente la relación está en manos de una gerencia de nivel medio. Operacional: Los proveedores de productos o servicios operacionales caen dentro de esta categoría. Los contactos y revisiones de desempeño son menos frecuentes y la relación es manejada por una gerencia operativa de nivel básico (junior). Insumos básicos Esta categoría es para proveedores que surten productos y servicios que pueden ser conseguidos fácilmente en otro lugar (por ejemplo: consumibles de oficina o impresión). Aportan un bajo valor y se requiere de una mínima comunicación.
Las relaciones con proveedores que caen dentro de la categoría estratégica deben tener la prioridad más alta. Estas relaciones normalmente se extienden más allá de los términos del contrato al extender la cultura de la organización del proveedor de servicios dentro de los dominios del proveedor.
108
Diseño del Servicio
109
Diseño del Servicio Para la mayoría de las organizaciones, el objetivo de seguridad se cumple cuando: La información es observada por o es revelada sólo a aquellos que tienen el derecho de conocerla (confidencialidad) La información está completa, es precisa y está protegida contra la modificación no autorizada (integridad) La información está disponible y puede ser utilizada cuando se requiere y los sistemas que la proporcionan pueden resistir apropiadamente ataques y recuperarse de o prevenir fallas (disponibilidad) Las transacciones de negocios, así como los intercambios de información entre las empresas o con los socios, pueden ser confiables (autenticidad y no rechazo)
110
Diseño del Servicio
La Política de Seguridad de la Información guía las actividades de Gestión de Seguridad de la Información. La Política de Seguridad de la Información está soportada por políticas de seguridad que la apuntalan y debe incluir:
Política de seguridad global Política de uso e uso inapropiado de activos de TI Política de control de accesos Política de control de contraseñas Política de correo electrónico Política de internet Política de antivirus Política de clasificación de la información Política de clasificación de la documentación Política de acceso remoto Política con relación al acceso a proveedores a los servicios de TI, información y componentes Política de violación de derechos de autor para el material electrónico Política de disposición de activos Política de retención de registros
111
Diseño del Servicio
112
Diseño del Servicio
La disponibilidad del servicio es crucial para la garantía de un servicio y abarca todo el ciclo de vida del servicio. Si un servicio no entrega la disponibilidad requerida, entonces el servicio fracasa en el cumplimiento de los objetivos establecidos por el negocio.
113
Diseño del Servicio
114
Diseño del Servicio
Gestión de la Disponibilidad necesita entender los requerimientos desde la perspectiva del negocio en términos de:
Procesos actuales del negocio, su operación y requerimientos Planes y requerimientos futuros de negocio Objetivos del servicio y la operación y entrega actual del servicio de TI Infraestructura de TI, datos, aplicaciones y ambiente y su desempeño Impactos y prioridades del negocio en relación a los servicios y su utilización
Un profundo entendimiento de lo anterior asegurará que los servicios y componentes sean capaces de cumplir los objetivos establecidos por el negocio. Gestión de la Disponibilidad debe:
Aplicar a los servicios de TI que son considerados como críticos para el negocio y a todos los servicios y tecnología en operación (especialmente aquellos cubiertos por los SLAs) Aplicar a todos los servicios de TI nuevos y existentes donde se hayan establecido SLRs o SLAs Aplicar a los servicios de soporte, asociados internos y externos, así como los proveedores que conforman la organización de soporte de TI Tomar todos los componentes de los servicios de TI y las organizaciones de soporte en quecuenta podrían impactar potencialmente la disponibilidad (por ejemplo capacitación, procedimientos y herramientas)
115
Diseño del Servicio
Disponibilidad del Servicio Cubre todos los aspectos de la disponibilidad y no disponibilidad del servicio y el impacto de la disponibilidad de los componentes, o el impacto potencial de la no disponibilidad de los componentes en la disponibilidad del servicio. Disponibilidad de Componentes Incluye todas las áreas de disponibilidad y no disponibilidad de los componentes. Confiabilidad Define por cuánto tiempo un servicio, componente o Elemento de Configuración (CI) puede desempeñarse sin tener una falla o interrupción en el servicio. Capacidad de Mantenimiento Mide que tan rápidamente un servicio, componente o CI puede ser restablecido después de una interrupción o falla. Capacidad de Servicio La capacidad de terceras partes proveedoras para cumplir los términos del contrato. Esto incluye los niveles acordados de confiabilidad, capacidad de mantenimiento y disponibilidad de un CI. Diseño para funciones Vitales del Negocio (VBFs) Las funciones vitales del negocio son aquellas partes de un proceso de negocio que son críticas para el éxito del negocio. Los aspectos de diseño incluyen:
116
Diseño del Servicio
Alta Disponibilidad: Se refiere a un servicio de TI que minimiza los efectos de la falla de un component e de TI para los usuarios del servicio Tolerancia Fallas: Qué tan bien puede un servicio, componente o CI operar después de una falla. Operación Continua: Un concepto para reducir los efectos para el usuario de un tiempo planeado fuera de servicio (como cambios y mantenimientos preventivos). A pesar de que algunos componentes individuales o CI’s puedan estar caídos, el servicio permanece disponible. Disponibilidad Continua: Diseñado para lograr un 100% de disponibilidad (en el horario acordado). Este servicio de TI no tiene tiempos planeados o no planeados fuera de servicio (no hay interrupciones dentro del horario acordado).
117
Diseño del Servicio
118
Diseño del Servicio
Gestión de la Capacidad se extiende a lo largo del Ciclo de vida del Servicio y es vital para la garantía del servicio. Si un servicio no proporciona los niveles de capacidad y desempeño requeridos, entonces el negocio no estará recibiendo el valor que le fue garantizado.
119
Diseño del Servicio
Los objetivos de la Gestión de la Capacidad son:
120
Generar y mantener un plan de capacidad apropiado y actualizado, el cual refleje las necesidades actuales y futuras del negocio Dar consejo y orientación a todas las otras áreas del negocio y a TI sobre los temas relacionados con la capacidad y el desempeño Garantizar que los logros en el desempeño del servicio cumplen todos los objetivos establecidos gestionando el desempeño y la capacidad tanto de los servicios como de los recursos Ayudar en el diagnóstico y la resolución de incidentes y problemas relativos con el desempeño y la capacidad Evaluar el impacto de todos los cambios en el plan de capacidad, y el desempeño y capacidad de los servicios y recursos Garantizar que se implementen medidas proactivas para mejorar el desempeño de los servicios siempre que sea justificable en términos de costo
Diseño del Servicio
Dentro del alcance de la Gestión de la Capacidad están:
Todos los aspectos de tecnología incluyendo hardware y software para los componentes de tecnología y ambientes de TI Planeación para sistemas ambientales Recursos de personas; la falta de personal podría llevar a que no se cumplieran los SLAs
o losdeOLAs El proceso Gestión de la Capacidad debe incluir: Monitoreo de patrones de actividad de negocio a través del desempeño, la utilización y el desempeño de los servicios de TI y la infraestructura de soporte, los componentes ambientales, de datos y aplicaciones y la producción de reportes regulares y bajo demanda sobre la capacidad y el desempeño del servicio y sus componentes Llevar a cabo actividades de puesta a punto para hacer el uso más eficiente posible de los recursos de TI existentes Entender las demandas acordadas actuales y futuras que están siendo hechas por el cliente en cuanto a recursos de TI y generar un pronóstico de los requerimientos futuros Influenciar la demanda de servicios de TI en conjunto con los procesos de gestión financiera para Servicios de TI y gestión de la demanda Generar un plan de capacidad que permita al proveedor de servicios continuar brindando servicios de la calidad definida en los SLAs y que cubra un lapso de tiempo de planeación suficiente para cumplir los niveles de servicio futuros requeridos de acuerdo a lo definido en el portafolio de servicios y en los SLRs
Ayudar en la identificación y resolución de cualquier incidente o problema asociado con la capacidad o desempeño del componente o del servicio El mejoramiento proactivo del desempeño del servicio o del componente, siempre que sea justificable en costo y cumpla con las necesidades del negocio
121
Diseño del Servicio
Equilibrio de Costos Contra Recursos Necesarios La capacidad de procesamiento que se compra debe ser justificable en costo en términos de la necesidad del negocio y el proveedor debe esforzarse por garantizar el uso eficiente de dichos recursos. Equilibrio de Oferta Contra Demanda La capacidad adecuada debe coincidir con las demandas del negocio, tanto al día de hoy como en el futuro. El proveedor también puede buscar manejar o influenciar la demanda de servicios o recursos particulares. Plan de Capacidad Una actividad clave de la Gestión de la Capacidad es la generación de un plan que documente tanto la utilización actual de recursos como el desempeño del servicio. También pronostica los requerimientos futuros de recursos nuevos necesarios para soportar actividades anticipadas del negocio. El Plan de Capacidad debe ser publicado como mínimo anualmente (junto con un plan de inversión de capital propuesto) y después actualizado de forma regular (trimestralmente) para tomar en cuenta los cambios tecnológicos y del negocio. Gestión de la Capacidad del Negocio La Gestión de la Capacidad del Negocio es responsable de garantizar que las necesidades del negocio estén incluidas dentro de los servicios futuros y la planeación de TI. Estos requerimientos futuros, que vienen de Estrategia del Servicio y del Portafolio de Servicios, detallarán los nuevos procesos y requerimientos de servicios, así como cambios, mejoras y crecimiento esperado para los servicios existentes. 122
Diseño del Servicio
Gestión de la Capacidad del Servicio La actividad clave de Gestión de la Capacidad del Servicio es la gestión, control y predicción del desempeño y la capacidad de la utilización y cargas de trabajo del servicio de TI. Los Acuerdos de Niveles de Servicio (SLAs) y los Requerimientos de Niveles de Servicio (SLRs) son monitoreados y medidos para identificar situaciones relacionadas con la capacidad. Los límites automatizados son útiles para ayudar a gestionar los servicios. Las alertas de límites, cuando son diseñadas adecuadamente, proporcionarán a operaciones o a gestión técnica un margen de tiempo suficiente para realizar ajustes y evitar un Incidente relacionado con la capacidad. Gestión de laclave Capacidad del Componente La actividad de la Gestión de la Capacidad del Servicio es la gestión, control y predicción del desempeño y la capacidad de los componentes individuales de tecnología de TI. Se da un énfasis específico al monitoreo y la gestión de los componentes individuales en línea con los requerimientos del servicio.
123
Diseño del Servicio
124
Diseño del Servicio
Los objetivos, alcance y requerimientos de Gestión de la Continuidad de Servicios de TI son establecidos a través de Gestión de la Continuidad del Negocio (BCM), el proceso de negocio responsable de gestionar los riesgos que podrían impactar seriamente al negocio. BCM busca proteger los intereses de las partes involucradas, la reputación y marca del negocio, así como todas las actividades que generan valor.
125
Diseño del Servicio
Los objetivos de ITSCM son:
Generar y mantener un conjunto de planes de continuidad del servicio de TI que soporten los planes generales de continuidad del negocio de la organización Completar con regularidad ejercicios de BIA para garantizar que todos los planes de continuidad sean mantenidos en línea con los impactos y requerimientos cambiantes del negocio Llevar a cabo con regularidad ejercicios de evaluación y gestión de riesgos para gestionar los servicios de TI dentro de un nivel acordado de riesgos de negocio en conjunto con los procesos de negocio, de la gestión de la disponibilidad y de gestión de seguridad de la información Dar asesoría y orientación a otras áreas del negocio y a TI sobre todos los asuntos relacionados con continuidad Garantizar que los mecanismos apropiados de continuidad sean establecidos para cumplir o exceder los objetivos de continuidad del negocio acordados. Evaluar el impacto de todos los cambios en los planes de continuidad del servicio de TI así como en los métodos de soporte y los procedimientos Garantizar que se implementen medidas proactivas para mejorar la disponibilidad de los servicios cuando sea justificable en costo hacerlo. Negociar y acordar contratos con los proveedores para la provisión de la capacidad de recuperación necesaria para soportar todos los planes de continuidad en forma conjunta con el proceso de gestión de proveedores
126
Diseño del Servicio
Cada organización en particular tendrá una definición diferente de lo que considera un desastre. La estructura organizacional, la cultura y la dirección estratégica determinarán el alcance de ITSCM. Los riesgos a largo plazo como restructuración, fracaso de la competencia y diversificación no están dentro del alcance de ITSCM. Aunque estos son riesgos significativos para el servicio de TI, típicamente existe suficiente margen de tiempo para evaluar el riesgo e implementar cambios o redirigir la estrategia. Estos cambios pasarían a formar parte de la estrategia general de Gestión de Cambios del negocio y de TI. Las pequeñas fallas técnicas, normalmente no entran dentro del alcance de ITSCM a menos de que tengan un impacto mayor en el negocio. Estos riesgos están cubiertos en el alcance de la Mesa de Servicio y de Gestión de Incidentes. La mitigación de este tipo de riesgos frecuentemente se planea dentro de los procesos de Gestión de la Disponibilidad, Gestión de Problemas, Gestión de Cambios, Gestión de los Activos del Servicio y de la Configuración y Gestión de Operaciones.
127
Diseño del Servicio
Análisis de Impacto del Negocio (BIA) El BIA identifica: La forma que puede tomar el daño o la pérdida – por ejemplo: Pérdida de ingresos y cualquier otro costo Daño a la reputación o pérdida del prestigio Pérdidas de ventaja competitiva Incumplimiento de regulaciones legales, sanitarias y de salud así como cualquier riesgo de seguridad personal Pérdida de participación en el mercado, tanto inmediata como a largo plazo Vergüenza política, corporativa o personal Pérdida de capacidad operacional en un ambiente de comando y control Grado de escalamiento del daño o pérdida después de la interrupción del servicio, y cuando será más severo Qué se necesita en términos de personal, habilidades, instalaciones y servicios (incluyendo los servicios de TI) para garantizar al menos un nivel mínimo operativo aceptable para los procesos de negocio críticos y esenciales Tiempo de recuperación con niveles mínimos de personal, instalaciones y servicios Tiempo para la recuperación completa de los procesos de negocio requeridos y el personal de soporte, instalaciones y servicios Prioridad de recuperación para cada uno de los servicios de TI
Evaluación del del Riesgo La Evaluación Riesgo es utilizada para evaluar y reducir los incidentes potenciales para garantizar la capacidad de dar mantenimiento, la disponibilidad y la confiabilidad. Es parte de Gestión de la Disponibilidad. 128
Diseño del Servicio
NOTAS:
129
Transición del Servicio
130
Transición del Servicio
131
Transición del Servicio
132
Transición del Servicio
Adoptar e implementar un enfoque estándar y consistente para Transición del Servicio:
Permitirá a los proyectos estimar el costo, tiempo, requerimiento de recursos y riesgos asociados con la etapa de Transición del Servicio con mayor exactitud Dará como resultado un volumen más alto de cambios exitosos Será más fácil para las personas adoptarlo y seguirlo Permitirá que los activos de Transición del Servicio sean compartidos y reutilizados a través de los proyectos y servicios Reducirá retrasos por colisiones y dependencias inesperadas – por ejemplo, si varios proyectos necesitan usar el mismo ambiente de pruebas al mismo tiempo. Reducirá el esfuerzo invertido en administrar los ambientes de prueba y de piloto en la Transición del Servicio Mejorará las expectativas creadas por los interesados involucrados en la Transición del Servicio incluyendo clientes, usuarios, proveedores, socios y proyectos Incrementará la confianza en que el servicio nuevo o modificado pueda ser entregado de acuerdo a las especificaciones sin afectar inesperadamente a otros servicios o interesados Garantizará que los servicios nuevos o modificados tendrán capacidad de ser mantenidos y serán efectivos en costo Mejorará el control de los activos del servicio y las configuraciones
133
Transición del Servicio
134
Transición del Servicio
135
Transición del Servicio Los objetivos de Planificación de la Transición y Soporte son:
136
Planear y coordinar los recursos para garantizar que los requerimientos de Estrategia del Servicio codificados en Diseño del Servicio sean llevados a cabo efectivamente en la Operación del Servicio Coordinar las actividades a través de los proyectos, proveedores y equipos de servicio donde sea necesario Establecer servicios nuevos o modificados en los ambientes soportados dentro del costo previsto, la calidad y los tiempos estimados Establecer sistemas de información gerenciales y herramientas nuevas o modificadas, arquitecturas de tecnología y de gestión, de gestión de servicios y métodos de medición y métricas para cumplir con losprocesos requerimientos establecidos durante la etapa del ciclo de vida de Diseño del Servicio Garantizar que todas las partes adopten un marco común de referencia de procesos estándar reutilizables y de sistemas de soporte para mejorar la efectividad y la eficiencia de la planeación integrada y de la coordinación de actividades Proporcionar planes claros e integrales que permitan al cliente y al negocio crear proyectos de cambio para alinear sus actividades con los planes de Transición del Servicio Identificar, gestionar y controlar los riesgos para minimizar la posibilidad de falla e interrupción a través de las actividades de transición; y garantizar que los puntos de Transición del Servicio, riesgos y desviaciones sean reportados a los interesados apropiados y a quienes toman las decisiones Monitorear y mejorar el desempeño de la etapa del ciclo de vida de Transición del Servicio
Transición del Servicio
El alcance de Planificación de la Transición y Soporte incluye:
Mantener las políticas, estándares y modelos de las actividades y procesos de Transición del Servicio Guiar cada cambio mayor o nuevo servicio a través de todos los procesos de Transición del Servicio Coordinar los esfuerzos necesarios para permitir manejar varias transiciones al mismo tiempo Priorizar los requerimientos que entren en conflicto por el uso de recursos de Transición del Servicio Planificar el presupuesto y los recursos necesarios para cubrir los requerimientos futuros para Transición del Servicio Revisar y mejorar el desempeño de las actividades de Planeación de la Transición y Soporte Garantizar que la Transición del Servicio se coordine con las actividades de gestión de programas y proyectos, Diseño del Servicio y el desarrollo del servicio
Dentro del alcance de Planificación de la Transición y Soporte no está incluida la planeación de la construcción, pruebas e implantación de cambios o liberaciones individuales. Estas actividades caen dentro de Gestión de Cambios y Gestión de Liberaciones e Implementación.
137
Transición del Servicio
138
Transición del Servicio
Cabe hacer notar que la información mantenida por Gestión de Activos de Servicios y Configuraciones incluye detalles de configuración de los activos junto con las relaciones entre los activos. Una relación es un vínculo entre dos CIs que identifica una dependencia o conexión entre ellos. Por ejemplo, las aplicaciones pueden estar vinculadas a los servidores en los que corren; los servicios de TI tienen muchos vínculos con todos los CIs que contribuyen a ellos.
139
Transición del Servicio
140
Garantizar que los activos bajo el control de la organización de TI están identificados, controlados y cuidados adecuadamente a través de todo su ciclo de vida. Identificar, controlar, registrar, reportar, auditar y verificar los servicios y otros elementos de configuración (CIs), incluyendo versiones, líneas base, componentes constitutivos, sus atributos y relaciones Responsabilizarse por el manejo y protección de la integridad de los CIs a través del ciclo de vida del servicio al trabajar con Gestión de Cambios para garantizar que sólo se utilicen componentes autorizados y que sólo se efectúen los cambios autorizados Garantizar la integridad de los CIs y de las configuraciones requeridas para controlar los servicios al establecer y mantener un Sistema de Gestión de la Configuración (CMS) preciso y completo Mantener información precisa de la configuración sobre el estado histórico, planeado y actual de los servicios y otros CIs Soportar procesos de gestión de servicios eficientes y efectivos al proveer información precisa de configuración para permitir a la gente tomar decisiones en el momento correcto – por ejemplo, para autorizar cambios y liberaciones, o para resolver incidentes y problemas
Transición del Servicio
El alcance incluye interfaces hacia los proveedores de servicios internos y externos donde existen activos y elementos de configuración que necesiten ser controlados (por ejemplo, activos compartidos).
141
Transición del Servicio
142
Transición del Servicio
La biblioteca segura en la cual son almacenadas y protegidas las versiones definitivas autorizadas de todos los medios de CIs Almacena las copias maestras de las versiones que han pasado las verificaciones de aseguramiento de calidad Puede constar de una o más bibliotecas de software o áreas de almacenamiento de archivos, separadas de las áreas de almacenamiento de archivos de desarrollo, pruebas o producción Contiene copias maestras de todo el software controlado, incluyendo copias definitivas de software comprado (junto con los documentos de licencias o información), así como todo el software desarrollado internamente Las copias maestras de documentación controlada de un sistema también son almacenadas en la DML de forma electrónica También incluirá un almacén físico para guardar copias maestras, por ejemplo una caja fuerte a prueba de incendios En la DML sólo deben aceptarse medios autorizados, estrictamente controlados por SACM Es el fundamento para Gestión de Liberación e Implementación
143
Transición del Servicio
El Glosario de ITIL define el CMS como: Un conjunto de herramientas, datos e información que es utilizado para soportar a Gestión de Activos del Servicio y de Configuraciones. El CMS es parte del Sistema de Gestión del Conocimiento de Servicios e incluye herramientas para recolectar, almacenar, gestionar, actualizar, analizar y presentar datos sobre todos los elementos de configuración y sus relaciones. El CMS también puede incluir información sobre incidentes, problemas, errores conocidos, cambios y liberaciones. El CMS es mantenido por Gestión de Activos del Servicio y Configuración y es utilizado por todos los procesos de gestión de servicios de TI.
144
Transición del Servicio
145
Transición del Servicio
146
Responder a los requerimientos cambiantes de negocio del cliente al mismo tiempo que se maximiza el valor y se reducen los incidentes, interrupciones y el re-trabajo Responder a las solicitudes de cambio del negocio y de TI que alinearán los servicios con las necesidades del negocio Garantizar que los cambios sean registrados y evaluados y que los cambios autorizados sean priorizados, planeados, probados, implementados, documentados y revisados de forma controlada Garantizar que todos los cambios a los elementos de configuración sean registrados en el Sistema de Gestión de Configuración Optimizar el riesgo global del negocio – con frecuencia lo correcto es minimizar el riesgo del negocio, pero a veces es apropiado aceptar intencionalmente un riesgo debido a su beneficio potencial
Transición del Servicio
Cabe hacer notar que las organizaciones deben identificar los cambios que están fuera del alcance de su proceso de Gestión de Cambios. Por ejemplo:
Puede haber cambios que tienen un alcance o impacto más amplios, como cambios en las operaciones del negocio Cambios a nivel operacional, como reparación de impresoras u otros componentes rutinarios del servicio
147
Transición del Servicio
148
Transición del Servicio
Modelos de Cambios Para garantizar la consistencia y la repetición cuando se manejan los cambios y también para aumentar la eficiencia, es útil incorporar el uso de modelos de proceso de cambios. Los modelos de cambios establecen maneras predefinidas de manejar un cambio de cierto tipo en particular. Frecuentemente se pueden usar herramientas de soporte para automatizar algunas de las actividades y ayudar a gestionar el proceso. Cualquier cambio que requiera un manejo especial se puede beneficiar de usar un modelo de cambios; por ejemplo, los cambios de emergencia que requieren una autorización diferente de la normal y que pueden ser documentados posteriormente. A manera de recordatorio, un modelo incluye:
Los pasos a seguir El orden cronológico de los pasos Las responsabilidades Las escalas de tiempo y los límites Los procedimientos de escalamiento
Propuestas de Cambio Con frecuencia se requiere de una Propuesta de Cambio para manejar los cambios con un costo, riesgo o impacto significativo al negocio y normalmente se iniciarían mediante el proceso de Gestión del Portafolio de Servicios 149
Transición del Servicio
La propuesta de cambio debe incluir:
Una descripción de alto nivel del servicio nuevo, modificado o retirado, incluyendo los resultados del negocio a ser soportados y la Utilidad y Garantía a ser provista Un caso completo de negocio incluyendo riesgos, problemáticas y alternativas, así como expectativas de presupuesto y financieras Un programa general con los tiempos del diseño y la implementación del cambio
Plan de Remediación Remediación: Acciones tomadas para la recuperación después de un cambio o liberación fallida. La remediación puede incluir dar marcha atrás, la invocación de planes de continuidad del servicio u otras acciones diseñadas para permitir al proceso de negocio continuar.
Antes de la autorización, Gestión de Cambios debe asegurar que existan planes de remediación en caso de que el cambio no sea exitoso. La intención es devolver a la organización a su estado previo al cambio. Esto puede implicar dar marcha atrás al cambio y regresar los CIs a su línea base, en particular en el caso de software y datos. En caso de que el cambio no sea reversible, debe definirse un enfoque para poder regresar a la línea base anterior
Comité Asesor de Cambios (CAB) El Comité Asesor de Cambios (CAB) es un grupo que existe para soportar la autorización de los cambios y para ayudar a Gestión de Cambios en la evaluación, priorización y calendarización de los cambios.
Comité Asesor de Cambios de Emergencia (ECAB) Es un subgrupo del comité asesor de cambios que toma las decisiones con respecto a los cambios de emergencia.
Los miembros del ECAB pueden ser identificados cuando se convoca a una reunión y de hecho puede depend er del tipo de cambio de emergencia que se esté considerando. Los cambios de emergencia tendrán niveles pre-definidos de autorización, justo como en otros tipos de cambios y estos deben estar claramente documentados y entendidos por todas las partes apropiadas.
Tipos de Solicitudes de Cambio Una solicitud de cambio es una comunicación formal en busca de la alteración de uno o más elementos de configuración. El tipo de cambio determinará el tipo de solicitud de cambio. Las solicitudes vienen en distintas formas, incluyendo “una solicitud de cambio ”, un docume nto, una
llamada al centro de atención al usuario o un documento de inicio de proyecto.
150
Transición del Servicio Ejemplos de tipos de solicitudes por etapa del ciclo de vida del servicio:
Procedimientos de Trabajo SS Documentados Solicitud de cambio al portafolio de Gestión de servicios: Cambios del Nuevo elemento de línea del Servicio portafolio El alcance predicho, caso de Ti po de Cambio con E jemplos
SD
ST
SO
CSI
negocio, línea base Servicios bajo consideración Solicitud de cambio al servicio o a la definición del servicio: A los atributos del servicio existentes o planeados Cambio al proyecto que impacta Diseño del Servicio (i.e.: garantías pronosticadas Mejora del servicio) Propuesta de cambio del proyecto: Cambio de negocio Sin impacto en el servicio o la línea base del diseño
Gestión Cambios Servicio
de del
Procedimiento de Gestión de Cambios del proyecto
Solicitud de acceso de usuario
Procedimiento de Acceso de Usuarios
Solicitud de servicio de usuario
Proceso de Cumplimiento de Solicitudes
Cambio estándar Actividad operacional: Puesta a punto (dentro de especificaciones/restricciones) Reiniciar una aplicación que falló si no hubo impacto en los servicios Mantenimiento planeado Reparación operacional
Procedimiento local (frecuentemente pre-autorizado)
Cambio de emergencia
Gestión Cambios Servicio
de del
Cabe hacer notar que pueden existir procedimientos específicos (i.e. para evaluación de impacto y autorización de cambios, para distintos tipos de cambios). 151
Transición del Servicio
Actividades de Gestión de Cambios para un Cambio Normal: Crear el Cambio Un individuo o un grupo (también conocido como el iniciador) efectuará la solicitud de cambio. Registrar RFC El cambio es registrado formalmente en la herramienta de Gestión de Cambios Revisar RFC Gestión de Cambios debe considerar brevemente cada solicitud y filtrarla con base en: Razones para Aceptar Práctica Nuevo RFC Información completa Información precisa Tiene la aprobación necesaria
presupuestal
Razones para Rechazar Impráctica Se repite en RFCs anteriores: Ya aceptado o o Rechazado Todavía en revisión o Solicitudes incompletas: Descripción inadecuada o o
152
Sin la aprobación presupuestal necesaria
Transición del Servicio
Evaluar y Valorar el Cambio El tema del riesgo para el negocio que trae consigo un cambio debe ser considerado antes de la autorización de cualquier cambio. Muchas organizaciones usan una simple matriz para categorizar el riesgo. Autorizar la Construcción del Cambio y Pruebas El nivel de autorización requerida dependerá del tipo, tamaño, riesgo e impacto potencial al negocio del cambio. La autorización será otorgada por una autoridad de cambio que puede ser un rol, persona o grupo de personas. Coordinar la Construcción del Cambiocontrola y Pruebas Gestión de Liberaciones e Implantación la construcción y pruebas de los cambios que son parte de una liberación. Los cambios que no son parte de una liberación están controlados por el proceso de Gestión de Cambios. Autorizar la Implementación del Cambio Para poder manejar los riesgos y garantizar que el desempeño previsto y el actual coincidan con los requerimientos del negocio, es necesario que ocurra la evaluación del diseño, la construcción y pruebas del cambio. El tipo de evaluación variará con base en el tamaño del cambio; para cambios pequeños se llevará a cabo una evaluación apropiada, para los cambios significativos se creará un reporte de evaluación. Los resultados de la evaluación se entregan a la autoridad de cambios quien autorizará el cambio. La autoridad de cambios puede rechazar el cambio y solicitar que se hagan cambios en la calendarización del diseño o implantación. Esto puede traer como consecuencia que los procesos de pruebas y autorización ocurran varias veces hasta que el cambio cumpla con los requerimientos de la autoridad de cambios. Coordinar la Implementación del Cambio Gestión de Liberación e Implementación es dueño de la implantación de los cambios aprobados. Gestión de Cambios se encarga de los cambios menores que no son parte de una liberación. Garantizar que t odos los cambios sean implementados de acuerdo a lo programado queda bajo el control de Gestión de Cambios
Revisar y Cerrar el Registro de Cambio Al completarse el cambio:
Los resultados son reportados La revisión se ejecuta en conjunto con el proceso de Evaluación del Cambio Si es exitosa se cierra el registro Si es fallida, el registro se cie rra Es una buena idea mantener un historial de lecciones aprendidas de los cambios fallidos para garantizar que no se cometan nuevamente los mismos errores.
153
Transición del Servicio
Gestión de Programas y Proyectos La integración de las actividades de la Gestión de Cambios con la gestión de programas y proyectos ayudara a tener un claro entendimiento de las limitantes, dependencias y reglas Gestión de cambios del negocio (Integración con el proceso de cambios del negocio) Los procesos de gestión de cambios y las actividades necesarias para estar alineado con los equipos de gestión de proyectos del negocio para permitir que las problemáticas y los desarrollos sean compartidos con los miembros de la organización y comunicadas adecuadamente. Gestión del cambio organizacional y de interesados En algunas organizaciones hay una función separada que administra los cambios en la organización, en otras, este aspecto de la gestión del cambio puede ser llevado dentro de la organización de TI. Esto es como sea, un aspecto esencial que los aspectos organizacionales de la gestión del cambio están propiamente considerados y que los procesos de la gestión del cambio tienen interfaces apropiadas con la gente que lo lleva a cabo.
Otros procesos de la gestión de servicios de ITIL Planificación de la Transición y Soporte El proceso de Planificación de la Transición y Soporte ayuda a garantizar que exista un enfoque coordinado para la transición de los cambios. Evaluación del cambio La planeación es crítica para identificar los tipos de cambio que requerirán una evaluación del cambio formal para que ese tiempo este incluido en la planeación para el cambio 154
Transición del Servicio
Gestión de Proveedores Deben implementarse prácticas efectivas de Gestión de Cambios con todos los fabricantes y proveedores que brindan servicios a la organización para garantizar que la entrega del servicio sea gestionada teniendo en mente las necesidades del negocio. Gestión del Portafolio de Servicios Gestión del Portafolio de Servicios es responsable de los cambios estratégicos y las propuestas de cambio correspondientes. Las propuestas de cambio son vitales para la revisión y autorización de RFCs y juegan un papel muy importante al crear la calendarización de cambios. Gestión de activos de servicio y configuración Los sistemas de gestión de la configuración proveen un confiable, rápido y fácil acceso a información de la configuración que permitan a los interesados y staff evaluar el impacto de los cambios propuestos y darles seguimiento durante el cambio. Esta información permitirá que las versiones correctas de CIs sean liberadas a las partes apropiadas o en un ambiente correcto. Conforme los cambios hayan sido implementados, la información de la gestión de configuración es actualizada.
Gestión de Problemas La gestión de problemas es otro proceso principal, dado que los cambios a veces requieren implementar soluciones temporales y arreglar errores conocidos. La gestión de Problemas es una fuente mayor de RFCs y también contribuye a las discusiones del CAB
Gestión de Continuidad de los Servicios de TI La Gestión de continuidad de los servicios de TI tiene muchos procedimientos y planes, los cuales deben ser actualizados vía la gestión de cambios para asegurar que ellos están validados y actualizados y que los interesados estén al tanto de los cambios. Cada cambio debe ser evaluado por su impacto en los arreglos de continuidad de los servicios de TI. Para un cambio estándar esto debe ser hecho al tiempo que el modelo de cambio es autorizado, para los cambios normales y de emergencia, la evaluación es hecha durante la evaluación del cambio.
Gestión de Seguridad en la Información Las interfaces de la Gestión de seguridad de la información con la gestión de cambios son aquellas donde la seguridad será implementada a través de los procesos de gestión de cambios y la seguridad será una principal fuente de discusión del CAB en muchos servicios. Cada cambio significativo será evaluado por su potencial impacto en la gestión de seguridad en la información
Gestión de la Capacidad y Demanda La gestión de la capacidad y demanda son aspectos críticos para la gestión de cambios. Una demanda pobremente gestionada es una fuente de costo y riesgo para el proveedor de servicios porque siempre hay un nivel de incertidumbre en la demanda de los servicios. La gestión de la capacidad tiene un importante rol en la evaluación de los cambios propuestos, no solo en los cambios individuales sino en el impacto total de la capacidad del servicio.
155
Transición del Servicio
156
Transición del Servicio
157
Transición del Servicio
158
Definir y acordar los planes de Gestión de Liberación e Implementación con los clientes e interesados Probar y liberar paquetes que consisten en elementos de configuración relacionados que son compatibles entre ellos Garantizar que se mantenga la integridad de un paquete de liberación y sus componentes constitutivos a través de las actividades de transición y que todos los paquetes de liberación sean almacenados en una DML y registrados adecuadamente en la CMS Implantar paquetes de liberación de la DML al ambiente productivo siguiendo un plan y programa acordados Garantizar que todos los paquetes de liberación puedan ser rastreados, instalados, probados, verificados y/o desinstalados o revertidos de ser necesario Garantizar que el cambio de la organización y de los interesados sea gestionado durante las actividades de Liberación e Implementación Garantizar que el servicio nuevo o modificado y los sistemas, tecnología y organización que lo habilitan sean capaces de entregar la Utilidad y Garantía acordadas Registrar y gestionar las desviaciones, riesgos y situaciones relacionadas con el servicio nuevo o modificado y tomar las acciones correctivas necesarias Garantizar que exista una transferencia de conocimientos para permitir a los clientes y usuarios optimizar su uso del servicio para soportar sus actividades de negocio Garantizar que las habilidades y conocimientos son transferidos a las funciones de Operación del Servicio para permitirles entregar, soportar y mantener el servicio efectiva y eficientemente de acuerdo a las garantías y niveles de servicio requeridos
Transición del Servicio
Gestión de Liberación e Implementación es responsable de garantizar que las pruebas se lleven a cabo, pero no es quien lleva a cabo las pruebas como tales. Las pruebas en si, son ejecutadas por Validación y Pruebas del Servicio. La autorización de los cambios viene de Gestión de Cambios.
159
Transición del Servicio
Las políticas de liberación deben ser acordadas entre el proveedor de servicios y el negocio para uno o más servicios e incluir las características que se enlistan en la diapositiva. Se requiere de un identificador único para cada liberación, el cual será usado por Gestión de Activos del Servicio y de Configuraciones así como por estándares de documentación. Las liberaciones deben ser definidas por tipo como una forma de manejar las expectativas del cliente y los interesados. A continuación un ejemplo de una liberación:
Liberaciones mayores: Normalmente contienen grandes áreas de funcionalidad nueva, algunas de las cuales pueden eliminar correcciones temporales a problemas. Una actualización (upgrade) o liberación mayor normalmente reemplaza a todas las actualizaciones o liberaciones menores anteriores así como correcciones de emergencia Liberaciones menores: Normalmente contienen mejoras y correcciones menores algunas de las cuales pueden haber sido liberadas como correcciones de emergencia. Una actualización o liberación menor normalmente remplaza todas las correcciones de emergencia anteriores Liberaciones de emergencia: Normalmente contienen correcciones a un pequeño número de errores conocidos, o a veces mejoras para cumplir un requerimiento del negocio de alta prioridad.
Una política de liberación puede especificar de manera estricta, por ejemplo, que solamente ‘correcciones de emergencia’ serán emitidas entre liberaciones formalmente planeadas de mejoras y correcciones que no sean de emergencia.
160
Transición del Servicio
Fase 1 – Planeación de Liberación e Implementación La primera fase comienza cuando Gestión de Cambios autoriza la planeación de la liberación y finaliza cuando Gestión de Cambios autoriza la creación de la liberación. Esta fase incluye:
Planeación de liberación e implementación Criterio de éxito/fracaso Planeación de construcción y pruebas Planeación de liberación de paquetes y construcción Preparación para la construcción y pruebas de la liberación Planeación de la Implementación Planeación de logística y entrega Planeación de pilotos Planeación financiera/comercial
161
Transición del Servicio
Fase 2 – Construcción de la Liberación y Pruebas Durante esta segunda etapa, que ocurre sólo una vez por cada liberación, el paquete de liberación es construido, probado y colocado en la Biblioteca Definitiva de Medios. La fase comienza cuando Gestión de Cambios autoriza que la liberación sea construida y finaliza con Gestión de Cambios autorizando que la línea base del paquete de liberación sea colocada en la DML, por Gestión de Activos del Servicio y de Configuraciones. Esta fase incluye:
Documentación de la liberación y la construcción Adquirir y probar los elementos de configuración y componentes de entrada Empaquetar la liberación Construir y gestionar los ambientes de prueba Pruebas y pilotos del servicio Ensayos del servicio Pilotos
Fase 3 – Implementación El paquete de liberación en la DML es implementado en el ambiente de producción. La tercera fase comienza con Gestión de Cambios autorizando la implementación del paquete de liberación en uno o más ambientes objetivo y culmina con la entrega a las funciones en Operación del Servicio y soporte inicial. Esta fase incluye:
Planear y preparase para la implementación Evaluar si el grupo objetivo está listo Desarrollar los planes Ejecutar la transferencia, implementación y retiro Verificar la implementación Remediar/ dar marcha atrás a la liberación Soporte inicial
Fase 4 – Revisión y Cierre Durante esta cuarta fase, se llevan a cabo revisiones con el fin de obtener retroalimentación, evaluar los objetivos de desempeño y los logros, y documentar las lecciones aprendidas. Esta fase incluye:
162
Revisar y cerrar una implementación Revisar y cerrar la transición del servicio
Transición del Servicio
163
Transición del Servicio
El conocimiento y entendimiento del contexto y de las circunstancias de la situación afectarán directamente la capacidad del personal del servicio para entregar un servicio de calidad. Para garantizar que todas las partes estén bien informadas, los datos e información subyacentes deben ser precisos, estar actualizados y listos para ser accedidos por todas las partes involucradas.
164
Transición del Servicio
Mejorar la calidad de la toma de decisiones de gestión al garantizar que los conocimientos, información y datos confiables y seguros estén disponibles a lo largo del ciclo de vida del servicio Permitir al proveedor de servicios ser más eficiente y mejorar la calidad del servicio, aumentar la satisfacción y disminuir el costo del servicio al reducir la necesidad de redescubrir el conocimiento Garantizar que el personal tenga un entendimiento claro y común sobre el valor que los servicios proporcionan a los clientes y las formas en que se experimentan los beneficios al usar dichos servicios Mantener un Sistema de Gestión del Conocimiento de Servicios (SKMS) que proporcione un acceso controlado al conocimiento, la información y los datos que sea apropiado para cada audiencia Recolectar, analizar, almacenar, compartir, usar y mantener el conocimiento, la información y los datos a través de la organización proveedora de servicios
165
Transición del Servicio
166
Transición del Servicio
DIKW representa la progresión jerárquica desde datos hasta sabiduría
Datos son un conjunto de hechos discretos Información surge de dar contexto a los datos Conocimiento está compuesto por las experiencias, ideas, profundo entendimiento, valores y juicios tácitos de los individuos Sabiduría utiliza el conocimiento para crear valor a través de las decisiones correctas y bien informadas. La sabiduría implica tener conciencia de la aplicación y el contexto para proporcionar un juicio sólido basado en el sentido común
167
Transición del Servicio
Específicamente dentro de ITSM, el proceso de Gestión del Conocimiento se centra en establecer el Sistema de Gestión del Conocimiento de Servicios (SKMS) para permitir el conocimiento necesario para una toma de decisiones informada y para entregar y soportar los servicios exitosamente. El fundamento para este conocimiento será una cantidad considerable de datos, comenzando con aquellos que se pueden encontrar en el Sistema de Gestión de Configuraciones (CMS) y en las Bases de Datos de Gestión de Configuraciones (CMDB) Algunos ejemplos de elementos que deben estar almacenados en una SKMS incluyen:
168
El portafolio de servicios Acuerdos de Niveles de Servicio (SLAs), contratos y Acuerdos de Nivel Operacional (OLAs) Planes de negocio Registro CSI El plan de Capacidad y el Sistema de Información de Gestión de la Capacidad (CMIS) El plan de Disponibilidad y el Sistema de Información de Gestión de la Disponibilidad (AMIS) El sistema de información para la gestión de proveedores y contratos (SCMIS), incluyendo los requerimientos, habilidades y expectativas de los proveedores y socios Una Base de Datos de Errores Conocidos proporcionada por un fabricante que enliste los problemas comunes que se presenten en sus productos y cómo resolverlos Registro de habilidades, y niveles de habilidades comunes y anticipadas de los usuarios
Transición del Servicio
NOTAS:
169
Operación del Servicio
170
Operación del Servicio
Por supuesto, la Operación del Servicio es una etapa crítica en el ciclo de vida del servicio. La operación diaria de los servicios requiere de procesos que además de estar bien planificados e implementados, también sean llevados a cabo, controlados y gestionados apropiadamente. Se requiere de actividades para monitorear el desempeño, evaluar las métricas y recopilar los datos operacionales para identificar oportunidades de mejora. Además de gestionar los servicios según lo acordado con los clientes del negocio, Operación del Servicio es también responsable de la gestión eficiente y efectiva de la tecnología subyacente usada para entregar y soportar los servicios de TI.
171
Operación del Servicio
.
172
Operación del Servicio
Un enfoque estándar y consistente en Operación del Servicio traerá valor a través de:
La reducción de los trabajos no planeados y los costos del negocio y de TI a través un mejor manejo de las caídas de los servicios y la identificación de las causas de srcen La disminución de la duración y frecuencia de las caídas del servicio permitiendo al negocio aprovechar al máximo las ventajas del valor creado por los servicios El Mejoramiento continuo de los servicios y la justificación de las inversiones de mejora a través del análisis de los resultados operacionales y los datos El logro de las metas y los objetivos de la política de seguridad de la organización a través de los procesos destinados a garantizar que los servicios de TI sean accedidos únicamente por aquellos autorizados para utilizarlos Una mayor productividad o calidad de los servicios y productos del negocio a través acceso rápido y efectivo a los servicios estándar El aumento de la eficiencia a través de operaciones automatizadas que permiten que el costoso tiempo de los recursos humanos se emplee más en trabajos de innovación que puedan aumentar la ventaja competitiva de la organización.
173
Operación del Servicio
174
Operación del Servicio
Los Eventos pueden requerir de acción por parte del personal de TI, y la notificación normalmente es iniciada a través de una Alerta. Las Alertas pueden ser generadas por los servicios de TI, los Elementos de Configuración o las herramientas de monitoreo y son gestionadas por el proceso de Gestión de Eventos. Una Alerta también puede llevar a que un Incidente sea registrado.
175
Operación del Servicio
Los incidentes pueden ser detectados de varias form as:
176
Por el personal técnico al desempeñar sus actividades cotidianas Por herramientas de monitoreo de eventos Por los usuarios, que normalmente los reportan con una llamada telefónica al Service Desk A través de reportes de terceras partes proveedoras y socios
Operación del Servicio
Impacto es una medida del efecto de un incidente, problema o cambio en el proceso del negocio. Con frecuencia, el impacto se base en cómo serán afectados los niveles de servicio. El impacto y la urgencia son utilizados para asignar la prioridad. Urgencia es una medida de cuanto tiempo pasará hasta que un incidente, problema o cambio tenga un impacto significativo en el negocio. Por ejemplo, un incidente de alto impacto, puede tener una urgencia baja si el impacto no afectará al negocio hasta el final del año fiscal. El impacto y la urgencia son utilizados para asignar la prioridad Prioridad se usa para identificar la importancia relativa de un incidente, problema o cambio y es usada para identificar los tiempos requeridos para las acciones a seguir. Por ejemplo, el acuerdo de nivel de servicio puede establecer que los incidentes con Prioridad 2 deben ser resueltos dentro de un lapso de 12 horas.
177
Operación del Servicio
El término ‘Solicitud de Servicio’ generalmente se usa para describir distintos tipos de demandas de los usuarios. Normalmente, estos tipos de solicitudes son iniciadas a través del Service Desk y son manejadas a través del proceso de Cumplimiento de Solicitudes. Estos tipos de solicitudes son análogas a las órdenes de trabajo y se diferencian de los incidentes en que no se deben a un retraso inesperado o interrupción del servicio.
178
Operación del Servicio
Los registros de problemas son independientes de los registros de incidentes, aunque los registros de i ncidentes deben estar asociados o ligados a registros de problemas para indicar el impacto de un problema y ayudar a su priorización.
179
Operación del Servicio
Las soluciones temporales se caracterizan por los pasos documentados para enfrentar los síntomas conocidos, pasos que pueden ser reutilizados según sea necesario para reducir o eliminar el impacto. En caso de un Problema, el registro de problema contendrá la mejor solución temporal conocida con sus detalles hasta que una solución definitiva pueda ser implementada. Las soluciones temporales para incidentes que no tienen un registro de problema asociado, son documentadas en el registro de incidente.
180
Operación del Servicio
Documentar los Errores Conocidos facilita un diagnóstico y solución más ágil (restauración del servicio) si ocurren más incidentes.
181
Operación del Servicio
La Base de Datos de Errores Conocidos puede ser parte del Sistema de Gestión de Configuraciones, o puede ser almacenada en otra parte en el Sistema de Gestión del Conocimiento de Servicios. El documentar información dentro de la Base de Datos de Errores Conocidos (KEDB) refleja una sólida interfaz con Gestión del Conocimiento, y de hecho, la KEDB será usada por ambos procesos.
La efectividad de la KEDB requiere que los datos sean ingresados de cierta forma para permitir una consulta rápida y precisa y que sean agregados tan pronto como sea posible cuando se detectan y diagnostican nuevos problemas. La información puede ser usada por Gestión de Incidentes para restaurar rápidamente el servicio a su normalidad o por Gestión de Problemas en su búsqueda por eliminar permanentemente los defectos y e rrores de los servicios y/o la tecnología. A lo largo del tiempo, esta información ayudará a la organización a reducir tanto el número como el impacto de los incidentes.
182
Operación del Servicio
183
Operación del Servicio
La efectividad en la Operación del Servicio depende de conocer el estado de la infraestructura y ser capaz de detectar cualquier desviación del estado normal en operación. Gestión de Eventos, es el proceso responsable del monitoreo y control operacional. Las actividades operacionales de rutina pueden ser automatizadas cuando los eventos comunican información operacional así como advertencias y excepciones. Un ejemplo puede ser la ejecución de scripts enmúltiples dispositivos remotos, para o aún el equilibrar dinámicamente la demanda del servicio a través de dispositivos mejorar el desempeño.
184
Operación del Servicio
185
Operación del Servicio
Elementos de Configuración (CIs): Algunos CIs serán incluidos porque necesitar permanecer en un estado constante (p.ej.: en una red, un switch necesita permanecer encendido y las herramientas de Gestión de Eventos lo confirman al monitorear las respuestas a los ‘pings”) Algunos CIs serán incluidos porque su estatus necesita cambiar frecuentemente y Gestión de Eventos puede ser usado para automatizar esto y actualizar el Sistema de Gestión de Configuraciones (CMS) (p.ej.: la actualización de un servidor de archivos) Condiciones ambientales (p.ej.: detección de fuego y humo) Monitoreo de uso de licencias de software para asegurar su utilización óptima/legal y su ubicación Seguridad (p.ej.: detección de intrusos) Actividad normal (p.ej.: rastrear el uso de una aplicación o el desempeño de un servidor)
186
Operación del Servicio
187
Operación del Servicio
La Gestión de Incidentes es responsable de gestionar el ciclo de vida de todos los Incidentes, sin importar quién los detectó o cómo fueron detectados. La ‘Operación Normal del Servicio’ se define como un estado operacional donde los servicios y los CIs se están desempeñando dentro de sus niveles de servicio y operación acordados.
188
Operación del Servicio
Los objetivos del proceso de Gestión de Incidentes son:
Garantizar que se utilicen métodos y procedimientos estandarizados para una pronta y eficiente respuesta, análisis, documentación, gestión y reporte de incidentes
Incrementar la visibilidad personal de soporte de TI y la comunicación de los incidentes para el negocio y el
Mejorar la percepción del negocio con respecto a TI a través del uso de un enfoque profesional para resolver y comunicar los incidentes cuando ocurran
Alinear las actividades y prioridades de gestión de incidentes con las del negocio
Mantener la satisfacción del usuario con la calidad de los servicios de TI.
189
Operación del Servicio
Este enunciado no quiere decir que todos los eventos son Incidentes. Muchas clases de eventos son solamente informativos o indicativos de una operación normal y no están relacionados con una interrupción en lo absoluto. También, aunque tanto los incidentes comoa las solicitudes de servicio son de reportados al Service Desk, los Incidentes son manejados través del proceso de Gestión Incidentes, mientras que las Solicitudes de Servicio son manejadas por el proceso de Cumplimiento de Solicitudes.
190
Operación del Servicio
Escalas de tiempo Durante su vida, los incidentes progresarán a través de varias etapas. La conciencia y el monitoreo del tiempo empleado en estas etapas es crucial para cumplir los niveles de servicio acordados para los clientes. Para cumplir con los objetivos de respuesta y solución de Incidentes especificados en los Acuerdos de Nivel de Servicio, las escalas de tiempo para las etapas de manejo de Incidentes deben ser acordadas y comunicadas a los grupos de soporte. Modelos de Incidentes Cada incidente reportado no es necesariamente nuevo, puede tratarse de algo que ya ha ocurrido antes y que puede ocurrir de nuevo. Identificar y predefinir modelos ‘estándar’ (formas de manejarlos) puede ayudar a garantizar que los incidentes sean manejados siguiendo una ruta predefinida y dentro de escalas de tiempo establecidas. Pueden utilizarse herramientas de soporte para automatizar y gestionar las etapas requeridas. Un Modelo de Incidentes incluye:
Los pasos a seguir al manejar un Incidente El orden cronológico de los pasos a seguir, con las dependencias o co-procesamientos definidos Responsabilidades- quién hace qué, escalas de tiempo y límites para completar las acciones Precauciones que deben ser tomadas para garantizar el cumplimiento de los lineamientos sanitarios y de seguridad. Escalas de tiempo y límites
191
Operación del Servicio
Procedimientos de escalamiento – a quién contactar y cuándo Cualquier actividad de preservación de evidencia que sea necesaria
Incidentes Mayores Un Incidente Mayor es la categoría más alta de impacto para cualquier Incidente resultando en una interrupción significativa para el negocio. Normalmente se establecen procedimientos
independientes para manejar este tipo de Incidentes y tendrán escalas de tiempo menores y mayor urgencia asignada a ellos. Es esencial definir qué se considera como un Incidente Mayor para lograr un consenso con el negocio. Este criterio normalmente estará mapeado con el esquema general de priorización de Incidentes para que exista la seguridad de que se manejará apropiadamente a través del procedimiento correcto. Se debe tener en mente que los Incidentes Mayores y los Problemas son entidades independientes. Ya sea que un Incidentes sea mayor o no, el hecho de que un Incidente ocurrió persiste, y por lo tanto el registro debe conservarse por siempre. Los registros de Incidentes no se convierten en registros de Problemas. Un problema es la causa de uno o más Incidentes y ¡siempre permanece como una entidad independiente! Si no se mantiene esta distinción y registros independientes entre Incidentes y Problemas, podría ocurrir lo siguiente:
Que los incidentes sean cerrados prematuramente y que no se tome acción alguna para prevenir su recurrencia Que los incidentes permanezcan abiertos esperando el análisis de la causa raíz, perdiendo de vista cuándo se restauró en realidad el servicio del usuario. Podría parecer como que objetivos de SLA no se cumplieron a pesar de que el servicio haya quedado restaurado dentro de las expectativas del usuario
Seguimiento al estado del Incidentes Para garantizar el manejo y reporte adecuado del estatus de los Incidentes, es indispensable que los Incidentes sean rastreados de alguna forma. Asignar códigos de estado que sean representativos de dónde están en relación con el ciclo de vida de Incidentes permite hacer el y rastreo y reporte necesarios. Algunos ejemplos pueden incluir:
Abierto: Reconocido pero aún no asignado a un recurso de soporte para su solución En pr ogreso: En el proceso de ser investigado y resuelto Resuelto: La Solución ha sido implementada pero la validación de que volvió a la normalidad por parte del negocio o el usuario final todavía no ha ocurrido Cerrado : El usuario o el negocio ha acordado que el incidente ha sido resuelto y que el estado normal de las operaciones ha sido restaurado
Herramientas de Gestión de Incidentes Gestión de Incidentes utiliza distintas herramientas disponibles para ayudar con la pronta restauración del servicio normal. Estas incluyen:
192
Operación del Servicio
Sistema de Gestión de Conocimientos del Servicio Base de Datos de Errores Conocidos Calendario de Cambios Correspondencia con Incidentes parecidos (matching) Modelos de Incidentes Scripts de Diagnóstico
193
Operación del Servicio
Ciclo de Vida Extendido del Incidente Como se representa en el siguiente diagrama, los incidentes pasarán a través de varias etapas hasta la solución y restauración del servicio. Gestión de Incidentes lucha por garantizar que los Incidentes pasen a través de las etapas tan rápido como sea posible, en un esfuerzo por minimizar el impacto percibido por el negocio como resultado de la indisponibilidad.
Varias etapas en el ciclo de vida del incidente
194
Operación del Servicio
Actividades de Gestión de Incidentes Gestión de Eventos
Interfaz Web
Telefónico
Correo
Identificación del incidente
Es realmente un incidente?
No
Si
Hacia Cumplimiento de Solicitudes (Solicitud de servicio) o a la Gestión del Portafolio de servicios (Propuesta de cambio)
Registro del incidente Categorización del incidente Prioritización del incidente Procedimiento de incidente mayor
Si
¿Incidente mayor? No Diagnóstico inicial
Escalamiento funcional
Si
¿Escalamiento
Si
funcional?
No
No Si
No ¿Escalamiento jerarquico?
Escalamiento Jerárquico
¿Se require escalación?
Investigación y Diagnóstico
No
¿Solución identificada? Si Solución y recuperación
Cierre del incidente © Crown copyright 2011 Reproduced under license from OGC Figure 4.3 Service Operation 4.2.5
Fin
195
Operación del Servicio
Identificación La detección temprana es crítica – usualmente a través de los eventos de los componentes clave del servicio Idealmente, la meta es resolver los Incidentes antes de que puedan impactar a los usuarios
Registro Todos los incidentes deben ser registrados dejando constancia de la fecha/hora, sin importar su origen Toda la información relevante es registrada Un registro histórico completo debe ser mantenido y estar disponible para ser usado por
otros grupos de soporte
Clasificación Coloca dentro de la categoría apropiada de Incidente para garantizar que se registre el tipo exacto de la llamada Afecta las métricas, el reporte y la activación del Modelo de Incidentes correcto
Priorización Acuerda y coloca una prioridad apropiada (Impacto mas Urgencia) Determina cómo será manejado el incidente por las herramientas y el personal de soporte
Diagnóstico Inicial Trata de descubrir todos los síntomas del Incidente y cómo resolverlo Los scripts de diagnóstico y los registros de Errores Conocidos permiten el diagnóstico temprano y preciso
Correspondencia con Incidentes parecidos (“matching”) Encontrar la correspondencia de los incidentes usando la clasificación de incidentes como criterio para restaurar el servicio rápidamente. Como parte de encontrar la coincidencia el Service Desk también puede consultar problemas y errores conocidos en la búsqueda de resolver el incidente Cuando se hace correctamente, la coincidencia del incidente puede acelerar el descubrimiento de acciones de solución probadas, reduciendo así el tiempo requerido para restaurar el servicio normal.
Escalamiento del Incidente Escalamiento Funcional: asignar un Incidente a otro grupo debido a la falta de conocimiento o dominio o que expiró el lapso de tiempo acordado Escalamiento Jerárquico: para Incidentes Mayores pueden llevarse a cabo acciones correctivas por parte de la gerencia o es probable que el Incidente no se resolverá a tiempo o satisfactoriamente
Investigación y Diagnóstico Investigar e intentar diagnosticar lo que falló, pero no el por qué (p.ej.: la causa raíz causa raíz es ejecutada por Gestión de Problemas)
196
–
la
Operación del Servicio
Las Actividades y detalles de cualquier acción tomada deben ser documentadas en el registro de Incidentes
Resolución y Recuperación Aplicar y probar la solución potencial Las acciones emprendidas y las partes involucradas en las acciones de recuperación serán variables
Cierre
El registro es cerrado una vez que el Service Desk verifica que el incidente ha quedado completamente resuelto, el servicio ha sido restaurado, y los usuarios están satisfechos El incidente debe ser totalmente documentado La clasificación del incidente necesita ser verificada y corregida en caso de que sea incorrecta
Propiedad, Monitoreo, Seguimiento y Comunicaciones Sin importar quién maneje el Incidente, en todas las ocasiones, su propiedad permanecerá en manos del Service Desk, desde el inicio hasta el cierre. El Service Desk es responsable de monitorear y dar seguimiento al progreso, manteniendo a los usuarios informados del estatus del Incidente y el cierre del Incidente
Problemas Actuales o Recurrentes Si el Incidente fue resuelto sin que Gestión de Problemas haya determinado la causa raíz y existe la posibilidad de que el incidente vuelva a ocurrir, el proceso de Gestión de Problemas debe ser notificado para que pueda tomar la acción adecuada (p.ej.: declarar un problema y abrir un registro de problema)
Gestión de Incidentes – Aplicación Práctica 1. Asegúrese de que todos los Incidentes han sido registrados – sin esta información, no entenderá el verdadero impacto negativo en su ambiente 2. Garantiza que el Service Desk sea dueño de todos los Incidentes a través de su ciclo de vida. Si el Service Desk no puede ver todos los Incidentes abiertos, es prácticamente imposible que les asigne prioridad efectivamente, y es probable que se pierdan las tendencias. 3. Asegúrese de que las personas correctas están manejando los Incidentes. Si un Incidente puede ser manejado de forma efectiva por el personal de primer nivel, se le debe proporcionar el Modelo para ese Incidente par a que no tenga que ser escalado. El personal altamente calificado sólo debe ser involucrado en Incidentes el Service Desk no tenga los conocimientos o capacidad paradonde resolverlo dejando a otras partes con más tiempo para tratar con los Problemas, Cambios, Liberaciones, etc. 4. Definir claramente los procedimientos de escalamiento/asignación y escalas de tiempo. 197
Operación del Servicio
Gestión de Niveles de Servicio – Una parte clave para entregar los niveles de servicio acordados es resolver los Incidentes dentro las escalas de tiempo especificadas. Los datos históricos de Gestión de Incidentes ayudan a la Gestión de Niveles de Servicio a definir respuestas medibles a las interrupciones del servicio. Gestión de Incident es genera reportes usados por la Gestión de Niveles de Servicio al revisar el desempeño del servicio y es capaz de ayudar a definir los puntos débiles en los servicios. Esto permite a Gestión de Niveles de Servicio definir las acciones requeridas como parte del Plan de Mejora del servicio (SIP). La Gestión de Niveles de Servicio define los niveles aceptables del servicio para Gestión de Incidentes con relación a:
Tiempos de respuesta de incidentes Definición de impactos Tiempo objetivo de reparación Definición de servicios, los cuales son relacionados directamente con los usuarios Regalas para solicitar servicios Expectativas para proveer retroalimentación a los usuarios
Gestión de Seguridad de la Información – Los incidentes relacionados con la seguridad proporcionan información que puede ser útil durante las actividades de Diseño del Servicio y pueden ayudar a evaluar la efectividad de las medidas de seguridad de forma integral. – Cuando los Incidentes apuntan hacia un problema potencial de Gestión de Ges la Capacidad desempeño, tión de Incidentes sirve como un detonador de monitoreo del desempeño. Por su parte, Gestión de la Capacidad, puede desarrollar soluciones temporales o resoluciones para Incidentes.
198
Operación del Servicio
Gestión de la Disponibilidad – depende de los datos de Gestión de Incidentes para determinar la disponibilidad de los Servicios de TI. Gestión de Activos de Servicio y de Configuración – Proporciona datos que ayudan a identificar y tener avances en los Incidentes. Los datos del CMS ayudan a detectar equipo con fallas, evaluar el impacto e identificar a los usuarios afectados. También puede proporcionar información para determinar qué categorías de Incidente son asignadas a qué grupo de soporte. Gestión de Incidentes puede ayudar a mantener el estado de los CIs con fallas y ayudar a verificar la infraestructura al manejar los Incidentes. Gestión de Cambios – Cuando se requiere de un cambio para implementar una solución temporal o solución definitiva, ésta será registrada como una Solicitud de Cambio. Por su parte, Gestión de Incidentes se encarga la detección y solución de los Incidentes que surjan de los cambios fallidos. Gestión de Problemas – Los Incidentes son la base para identificar los Problemas, así que Gestión de Incidentes es el punto de partida para generar un registro de Problema. La Gestión de Problemas ayuda a eliminar los Incidentes recurrentes a través de la identificación de la causa raíz y la solución subsecuente. Gestión de Accesos – Cuando se detectan intentos de acceso no autorizado y violaciones de seguridad, se deben generar registros de incidentes. Los datos históricos de incidentes deben ser mantenidos y soportados para actividades de investigación forense y solución de las brechas de seguridad.
199
Operación del Servicio
200
Operación del Servicio
Los objetivos del proceso de Cumplimiento de Solicitudes son:
Mantener la satisfacción de usuario y el cliente a través del manejo eficiente y profesional de todas las solicitudes de servicio Proporcionar una vía para que los usuarios puedan solicitar y recibir servicios estándar para los cuales existe un proceso predefinido de autorización y calificación Proporcionar información a los usuarios y clientes sobre la disponibilidad de los servicios y el procedimiento para obtenerlos Proporcionar y entregar los componentes de los servicios estándar solicitados Ayudar con información general, quejas o comentarios
201
Operación del Servicio
En algunas organizaciones las solicitudes de servicio son manejadas como una categoría de ‘Incidente’. Sin embargo, existe una diferencia distinta entre los incidente s y las solicitudes de servicio. Los Incidentes son eventos no planeados, mientras que una solicitud de servicio normalmente representa algo que puede y ¡debería ser planeado! Sería más apropiado separar las solicitudes de servicio de los Incidentes, especialmente cuando existe un gran número de solicitudes con una variedad de acciones necesarias para cumplirlas. Manejar las solicitudes de servicio como un flujo de trabajo completamente independiente, así como registrarlas y gestionarlas como un tipo de registro por separado, permite una generación de reportes más precisa. Los modelos de solicitud, como los vistos en Gestión de Incidentes, pueden ser usados para predefinir las actividades que necesitan ser ejecutadas para tipos específicos de solicitudes, y se pueden usar herramientas para automatizar el manejo de muchos aspectos del proceso de cumplimiento. Finalmente, cada organización debe decidir y documentar qué solicitudes de servicio serán manejadas a través del proceso de Cumplimiento de Solicitudes y cuáles serán direccionadas hacia otros procesos, tales c omo Gestión de Relaciones del Negocio para manejar las solicitudes para servicios nuevos o modificados.
202
Operación del Servicio
203
Operación del Servicio
Gestión de Problemas se enfoca en el diagnóstico de la causa raíz de los Incidentes y en determinar su solución. Mientras que Gestión de Incidentes y de Problemas son procesos separados, están fuertemente relacionados y normalmente usan las mismas herramientas y una clasificación similar, sistemas de codificación de impacto y prioridad para garantizar la comunicación efectiva entre los dos procesos.
204
Operación del Servicio
205
Operación del Servicio
206
Operación del Servicio
Gesti ón de Problemas Reactiva tiene que ver con resolver los problemas en respuesta a uno o más incidentes. Gesti ón de Probl emas Proacti va tiene que ver con identificar y solucionar los problemas y errores conocidos antes de que más incidentes relacionados con ellos puedan ocurrir de nuevo.
Ambos aspectos buscan la causa raíz la identificación y la implementación de soluciones permanentes, pero ellos difieren en cuanto a cómo se detona el proceso de Gestión de Problemas La Gestión de Problemas Reactiva se detona como respuesta a un Incidente. Se centra en diagnosticar la causa raíz y prevenir su recurrencia a través de las resoluciones permanentes y de ser necesario, las soluciones temporales. La Gestión Proactiva de Problemas es detonada por actividades que buscan mejorar los servicios y es un complemento de las actividades de Mejoramiento Continuo del Servicio. Un ejemplo sería el ejecutar un análisis de los Incidentes históricos para prevenir su recurrencia. La Gestión de Problemas Proactiva identifica las soluciones temporales y las acciones de mejora que sirven para mejorar la calidad un servicio. Al redirigir los esfuerzos de una organización de reaccionar a un gran número de incidentes a prevenir incidentes, una organización provee un mejor servicio a sus clientes y hace un uso más efectivo de sus recursos disponibles dentro de la organización de soporte de TI.
207
Operación del Servicio
Modelo de Problema Se pueden crear modelos para el manejo de los problemas, justo como se hace para el manejo de los incidentes, solicitudes de servicio, etc. Incidentes vs. Problemas La diferencia principal entre Incidentes y Problemas radica en la necesidad de una causa raíz. A Gestión adesuIncidentes no se Gestión le pide encontrar la causa sino una lamanera el servicio estado normal. de Problemas buscaraíz, diagnosticar causa de raízrestaurar y después eliminarla para prevenir más Incidentes.
Ejemplos de Cuando Invocar a Gestión de Problemas Debido a que las reglas para invocar a Gestión de Problemas pueden variar, depende de las organizaciones individuales determinar y establecer las políticas, procedimientos, etc. Puede ser útil considerar las siguientes situaciones como oportunidades para abrir un registro de problema:
208
Gestión de Incidentes no puede relacionar un incidente con los problemas existentes y errores conocidos El análisis de tendencias de los incidentes registrados revela que puede existir un problema subyacente Ha ocurrido un incidente mayor en el que se necesitan emprender actividades para identificar la causa raíz Otras funciones de TI identifican que existe una condición de problema El Service Desk puede haber resuelto un incidente pero no ha determinado la causa y sospecha que es posible que vuelva a ocurrir El análisis de un incidente hecho por un grupo de soporte que revela que existe, o es probable que exista un problema subyacente. Una notificación de un proveedor de que existe un problema que tiene que ser resuelto
Operación del Servicio
Actividades de Gestión de Problemas Service Desk
Gestión de eventos
Gestión de incidentes
Gestión proactiva de problemas
Proveedor o contratista
Detección del problema Registro del problema Categorización del problema Priorización del problema Investigación y diagnóstico
CMS
Gestión de incidentes
Implementar Si solucion temp.
¿Solución temporal? No Base de datos de errores conocidos
Crear registro de error conocido (si es necesario)
Gestión de cambios
Si RFC
¿Se necesita cambio? No Resolución de problema
No
¿Resuelto?
Yes
Lecciones aprendidas Revisión del problema
Cierre del problema SKMS ¿Problema mayor?
Si
Revisión de problema
No Fin © Crown copyright 2011 Reproduced under license from OGC Figure 4.7 Service Operation 4.4.5
Mejoramiento continuo del servicio
Acciones de mejora Comunicaciones
209
Operación del Servicio
Detección El Service Desk sospecha de una causa desconocida de uno o más Incidentes Detección automatizada de fallas recurrentes en la infraestructura o aplicación Notificación de grupo de soporte interno o externo de que existe un Problema Análisis proactivo de Incidentes Actividades de mejora del servicio que resultan en un registro de problema para identificar más acciones de mejora
Registro
Todos los detalles relevantes del Problema son documentados para que exista un registro histórico compl eto Registro de fecha/hora para permitir el control adecuado y el escalamiento Referencia cruzada hacia un(os) Incidente(s) que detonó el registro del problema, con los detalles relevante copiados en el registro del problema
Clasificación Usando el mismo sistema de codificación que los Incidentes Permite rastrear la verdadera naturaleza del Problema Proporciona información gerencial significativa
Priorización Usando el mismo criterio que para los Incidentes En base a la frecuencia y el impacto de los Incidentes relacionados
Investigación y Diagnóstico Para determinar la causa raíz del Problema La prioridad manda en la velocidad y naturaleza de esta investigación, así como qué recursos y nivel de expertos son involucrados
Establecer Solución Temporal Descubrir una solución temporal; es posible que se descubran varias soluciones temporales Los detalles de la solución temporal son documentados en el registro de problema y este permanece abierto
Generar un Registro de Error Conocido El registro debe indicar el registro relativo al problema y documentar las acciones que están siendo tomadas junto con la causa raíz y la solución temporal Cuando la causa raíz es descubierta y/o la causa raíz es identificada, o cuando tiene sentido hacerlo
Resolución Idealmente, la resolución es aplicada tan pronto como se ha encontrado una solución
210
Operación del Servicio
Una Solicitud de Cambio (RFC) o Solicitud de Servicio, deberá ser levantada cuando es afectada la línea base de un elemento de configuración Garantizar que la resolución no cause mayores dificultades Cuando la solución definitiva no es encontrada, pero se han establecido soluciones temporales para reducir el impacto del problema, el registro de problema es re-priorizado (con base en el impacto que persiste) y las actividades de investigación y diagnóstico continúan
Cierre
El registro de problema y cualquier registro de Incidente abierto relacionado son cerrados formalmente se hacontiene encontrado solución histórica permanente exitosade todo el evento y Garantizar quecuando el registro unauna descripción completa que la clasificación es precisa Actualizar el estatus de cualquier registro de error conocido relacionado, indicando que la resolución ha sido aplicada
Revisión de Problemas Mayores Conducida después de cada Problema Mayor mientras se tienen los hechos frescos en la memoria Buscar las lecciones a ser aprendidas: Ver las cosas que fueran hechas bien o mal o Decidir qué podría hacerse mejor en el futuro o Determinar cómo podría prevenirse la recurrencia o Identificar cualquier responsabilidad de terceras partes y determinar si se requieren o acciones de seguimiento
Gestión de Problemas – Aplicación Práctica 1. Comience ejecutando un análisis de tendencias de los Incidentes más frecuentemente recurrentes. 2. Asegúrese de que alguien es responsable de los Problemas y Errores Conocidos y de ser adecuado que están progresando hacia su resolución. 3. Asegúrese de que los problemas sean registrados en forma separada de los Incidentes (aun cuando estén relacionados) para que el tiempo de restaurar el servicio sea calculado en forma separada del tiempo en descubrir la causa raíz y el tiempo en corregir el error (puede ser que el error nunca se corrija- esto no quiere decir que el servicio no pueda ser restaurado). 4. Comience asociando los registros de Errores Conocidos con los RFCs (Solicitudes de Cambio) que los resuelven.
211
Operación del Servicio
Gestión Financiera para Servicios de TI– ayuda en la evaluación del impacto de las resoluciones propuestas o soluciones temporales, así como desempeñar un Análisis del Valor del Esfuerzo. Gestión de Problemas proporciona información con relación al costo de resolver y prevenir los problemas, el cual es usado en los sistemas de presupuesto y contabilidad y al ejecutar cálculos de Costo Total de Propiedad (TCO). Gestión de la Disponibilidad – trabaja junto con la Gestión de Problemas proactiva para determinar formas de reducir los tiempos de caída del servicio e incrementar el tiempo de disponibilidad. Mucha de la información de gestión derivada de la Gestión de Problemas será compartida con Gestión de la Disponibilidad. Gestión de la Capacidad – pueden usarse equipos y técnicas para atender algunos Problemas, tanto reactiva como activamente. La información de Gestión de Problemas puede ser relativa a la calidad de las decisiones tomadas durante planeación de la capacidad. Gestión de la Continuidad de Servicios de TI – puede ser involucrada cuando un Problema significativo no es resuelto antes de que comience a ocurrir un impacto mayor en el negocio. Gestión de Niveles de Servicio – mide el nivel de entrega del servicio que puede haber sido afectado por incidentes y problemas. Gestión de Problemas participa en mejorar los niveles de servicio y proporciona información usada durante las revisiones de servicio. La Gestión de Niveles de Servicio también puede proporcionar información a Gestión de Problemas, como información de impacto y cómo podrían ser afectados los servicios por las soluciones y las medidas proactivas propuestas.
212
Operación del Servicio
Gestión de Cambios – Cuando una solución definitiva o solución temporal requiere un cambio a un CI, Gestión de Problemas garantiza que se envíe un RFC a través de Gestión de Cambios. Gestión de Cambios monitorea el progreso y mantiene informada a Gestión de Problemas. Gestión de Problemas también puede estar involucrada en rectificar las situaciones causadas por Cambios fallidos. Gestión de Activos de Servicio y Configuración – Los CIs con fallas son identificados por Gestión de Problemas usando los datos del Sistema de Gestión de Configuración, el cual también es usado para determinar el impacto de los problemas y las soluciones. –
las correcciones a lossean Problemas en Gestión de Liberación e Implementación el ambiente de producción. Garantizará que losimplementará Errores Conocidos del desarrollo ingresados en la Base de Datos de Errores Conocidos. Gestión de Problemas manejará los problemas causados por las fallas durante el proceso de liberación.
Gestión del Conocimiento – El SKMS constituye la base para la KEDB y contiene o se integra con los registros de problemas. Proceso de Mejora en Siete Pasos – Las oportunidades de mejora del servicio pueden surgir de los incidentes y problemas que ocurren. La gestión proactiva de problemas puede ayudar a incrementar la calidad del servicio y la satisfacción del usuario final/cliente a través de la identificación y eliminación de los problemas y cuestiones del servicio.
213
Operación del Servicio
214
Operación del Servicio
Gestión de Accesos es el proceso de otorgar a los usuarios autorizados el derecho de usar un servicio y al mismo tiempo prevenir el acceso a usuarios no autorizados. En diferentes organizaciones, también ha sido referido como gestión de derechos o gestión de identidad. Con mayor frecuencia Gestión de Accesos es detonado por una solicitud de servicio.
215
Operación del Servicio
216
Operación del Servicio
Gestión de Accesos también trabaja para prevenir el acceso de usuarios no autorizados. En algunas organizaciones también se conoce como Gestión de Derechos o Gestión de Identidad. Gestión de Accesos no reside normalmente dentro de una sola unidad funcional, sino que es llevado a cabo por todas las funciones de Gestión Técnica y de Aplicaciones. Sin embargo, puede existir un punto único de control para la coordinación de las solicitudes, que puede estar en Gestión de Operaciones de TI o en el Service Desk.
217
Operación del Servicio
218
Operación del Servicio
La interacción e interdependencia de Gestión Técnica y Gestión de Aplicaciones con Gestión de Operaciones de TI proporciona un control adecuado para la infraestructura operativa de tal forma que todas las áreas puedan ser efectivas. Gestión de Operaciones de TI opera el funcionamiento del día a día de la infraestructura del cual depende la garantía del servicio. Sin embargo, las funciones de Gestión Técnica o de Aplicaciones también pueden ser responsables por la operación diaria de un subgrupo específico de la Infraestructura de TI. Lógicamente, el persona l que desempeña estas actividades diarias forma parte de la función de Gestión de Operaciones de TI.
219
Operación del Servicio
220
Operación del Servicio
El rol del Service Desk El Service Desk es una función crucial para todo el concepto de Gestión de Servicios. Es el Punto Único de Contacto (SPOC) entre el proveedor y los usuarios y clientes con respecto a la entrega y el uso de los servicios. Además, sirve como punto de coordinación de varios grupos y procesos de TI. El Service Desk está centrado en el cliente y está compuesto por personas con habilidades interpersonales, con una perspectiva de sensibilidad del negocio, y orientadas al servicio (basada en el valor). Al ser el ejecutante principal del proceso de Gestión de Incidentes, el Service Desk es dueño de todos los Incidentes sin importar cómo están identificados y registrados. Normalmente, el Service Desk está separado del resto de las funciones de Operación del Servicio. En algunos casos, p.ej. donde se ofrece a los usuarios un soporte técnico a mayor detalle en su primera llamada, puede ser necesario para el personal de Gestión Técnica o de Aplicaciones estar en el Service Desk. Esto no significa que el Service Desk se convierta en parte de la función de Gestión Técnica. De hecho, mientras estén en el Service Desk, dejan de ser parte de las funciones de Gestión Técnica o Gestión de Aplicaciones y se convierten en parte del Service Desk, aun cuando sólo sea temporalmente.
221
Operación del Servicio
222
Operación del Servicio
Dentro de este contexto ‘restauración del servicio’ se entiende en el sentido más amplio posible. Mientras que esto podría implicar corregir una falla técnica, igualmente, también podría implicar cumplir una solicitud de servicio o contestar una pregunta – cualquier cosa que se necesite para permitir a los usuarios regresar a trabajar satisfactoriamente. Sus responsabilidades específicas incluirán:
Registra todos los detalles relevantes de incidentes/solicitudes de servicio, incluyendo sus códigos de clasificación y priorización Proporcionar investigación y diagnóstico de primera línea Resolver incidentes/solicitudes de servicio desde el primer contacto cuando esto sea posible. Escalar los incidentes/solicitudes de servicio que no pueden resolver dentro de las escalas de tiempo acordadas Mantener informados a los usuarios sobre el progreso Cerrar todos los incidentes, solicitudes y otras llamadas que hayan sido resueltos Conducir encuestas de satisfacción de clientes/usuarios según lo acordado Comunicación con los usuarios- mantenerlos informados del progreso de los incidentes, notificándoles de cambios inminentes o cortes al servicio acordados, etc. Actualizar el CMS bajo la dirección y aprobación de Transición del Servicio según lo acordado
223
Operación del Servicio
Service Desk Local Un Service Desk que es colocado dentro o físicamente cerca de la comunidad de usuarios a la que da servicio
Proporciona una presencia visible y facilita la comunicación Puede ser ineficiente y es posible que sea costoso en cuanto a recursos Requiere ser consistente en cuanto a procesos y herramientas a través de la empresa
Las razones para considerar el utilizar un servicio Local incluyen: Husos horarios distintos, idioma, diferencias culturales o políticas Grupos de usuarios altamente especializados o criticidad de los usuarios (p.ej.: VIPs) Servicios personalizados/especializados que requieren un conocimiento específico
224
Operación del Servicio
Service Desk Centralizado Un Service Desk ubicado en una ubicación físicamente centralizada para todas las ubicaciones o sitios de usuarios Permite manejar un volumen más altos de llamadas con menor personal a nivel global Los niveles de habilidad aumentan debido a una mayor exposición a eventos frecuentes
Nota: Puede seguirse requiriendo algún tipo de presencia ‘local’ para manejar las necesidades de soporte físico, pero este tipo de personal puede ser controlado y asignado centralmente.
225
Operación del Servicio
Service Desk Virtual Un Service Desk que para el que llama parece estar en una ubicación, pero geográfica o estructuralmente, en realidad está disperso. Puede estar situado y ser accedido desde cualquier parte del mundo Depende fuertemente de la tecnología, particularmente de internet, junto con las herramientas de soporte corporativo para coordinar y comunicarse Permite la opción de trabajar en casa u oficinas remotas, para cubrir las necesidades de los usuarios Se requiere de consistencia y estandarización en la calidad del servicio y en términos culturales
Service Desk que Sigue el Sol Las organizaciones globales o internacionales pueden requerir combinar dos o más de sus Service Desk dispersos geográficamente para proporcionar servicio las 24 horas que sigue el sol.
El costo es relativamente bajo ya que ningún Service Desk necesita más de un turno Depende de procesos comunes, herramientas e información compartida Las diferencias culturales deben ser manejadas Requiere procesos de escalamiento y transferencia bien controlados
Nota: En algunos casos, crear grupos de gran ser familiaridad entrenamiento especializado dentro de la estructura del especialistas Service Deskconpuede benéfico.y Los incidentes relacionados con un servicio específico de TI pueden ser dirigidos directamente a ellos para una resolución más rápida.
226
Operación del Servicio
227
Operación del Servicio
A través de este doble rol, Gestión Técnica ayuda a garantizar que las organizaciones tengan acceso al tipo y nivel de recursos humanos apropiado para manejar la tecnología que soporta los servicios destinados a cumplir con los objetivos del negocio. La definición de los requerimientos para este tipo de roles comienza en Estrategia del Servicio, se expande en Diseño del Servicio, es validada en Transición del Servicio y es refinada en Mejoramiento Continuo del Servicio. Gestión Técnica:
Juega un papel importante en el diseño, pruebas, liberación y mejora de los Servicios de TI Proporciona orientación a Operaciones de TI sobre cómo llevar a cabo de la mejor manera la gestión técnica diaria de la tecnología: En parte es llevada a cabo durante la etapa de Diseño del Servicio o o Es parte de la comunicación diaria con Gestión de Operaciones de TI para buscar lograr la estabilidad y el desempeño óptimo Garantiza un balance entre el nivel de habilidades, la utilización y el costo de estos recursos: Identifica los momentos en los que se requiere de habilidades poco frecuentes e o incluye contratistas exclusivamente para esas tareas Maximiza el personal especializado a partir de “grupos” centrales para o proporcionar una economía de escala para la organización y minimiza la o
228
necesidad contratistas Identifica de lasutilizar habilidades especializadas dentro de los recursos de TI y los potencia de acuerdo a las necesidades específicas según surgen asignaciones.
Operación del Servicio
229
Operación del Servicio
230
Operación del Servicio
Gestión de Aplicaciones es para las aplicaciones, lo que Gestión Técnica es para la infraestructura de TI. Como fue en el caso de Gestión Técnica, Gestión de Aplicaciones debe
balancear la necesidad y demanda de habilidades técnicas específicas. Gestión de Aplicaciones garantiza que el nivel correcto y el grado de habi lidades y conocimientos estén disponibles para soportar el desarrollo, implementación, operación y mejora apropiados del ambiente de la aplicación para que cumpla con las necesidades actuales del negocio. Gestión de Aplicaciones gestiona las aplicaciones a lo largo de su ciclo de vida y jugará su papel ya sea que las aplicaciones sean compradas o desarrolladas internamente. Gestión de Aplicaciones también juega un papel importante en el diseño, pruebas y mejora de las aplicaciones que forman parte de los Servicios de TI. Como tal, puede estar involucrada en el desarrollo de proyectos, pero normalmente no es del mismo equipo que el de desarrollo de Aplicaciones.
231
Operación del Servicio
Para alcanzar los objetivos:
232
Las aplicaciones deben ser resistentes y conservar su estructura, bien diseñadas y efectivas en costo La utilidad debe alinearse a los resultados requeridos por el negocio Las habilidades técnicas adecuadas mantienen el desempeño operacional óptimo de las aplicaciones Las habilidades con respecto a las aplicaciones deben implementarse eficientemente para enfrentar los Incidentes o Problemas relativos a las aplicaciones.
Operación del Servicio
Gestión de Aplicaciones difiere de Desarrollo de Aplicaciones en que Gestión de Aplicaciones cubre el ciclo completo actual de una aplicación, incluyendo los requerimientos, el diseño, la construcción, la implementación, la operación y optimización. Al desarrollo de aplicaciones le conciernen principalmente las actividades que se ejecutan por una sola ocasión para los requerimientos, el diseño y la construcción de aplicaciones.
233
Operación del Servicio
234
Operación del Servicio
Gestión de Operaciones de TI tiene dos inquietudes: una es la estabilidad de la infraestructura de TI y la segunda es la consistencia de los servicios de TI. Las mejoras en las Operaciones de TI están encaminadas a llevar a cabo las actividades de una manera mejor y más simple. Gestión de Operaciones de TI consiste de dos sub-funciones: Control de Operaciones de TI y Gestión de Instalaciones.
235
Operación del Servicio
236
Operación del Servicio
Control de Operaciones desempeña las siguientes tareas específicas:
Control de Operaciones de TI controla la ejecución y el monitoreo de las actividades operacionales y los eventos en la infraestructura de TI Suministrar personal al puente de operaciones o centro de operaciones de red Ejecutar tareas de rutina de todas las áreas técnicas Gestión de la consola/puente de operaciones lo que se refiere a definir la observación central y la capacidad de monitoreo y posteriormente usar las consolas para ejercer las actividades de monitoreo y control de Gestión Calendarización de trabajos o la gestión de trabajos en lotes o scripts de rutina. Respaldo y restauración en nombre de todos los equipos y departamentos de Gestión técnica y de aplicaciones y frecuentemente en nombre de los usuarios Gestión de las impresiones y salidas, para la compaginación y distribución de todas las impresiones o salidas electrónicas centralizadas Llevar a cabo actividades de mantenimiento en nombre de los equipos o departamentos de Gestión Técnica o de Aplicaciones
237
Operación del Servicio
En algunos casos, la gestión del centro de datos se hace a través de outsour cing, en cuyo caso, la Gestión de Instalaciones se refiere a la gestión del contrato de outsourcing.
238
Operación del Servicio
239
Operación del Servicio
Los tipos más comunes de comunicación en Operación del Servicio incluyen:
Comunicaciones operacionales de rutina Comunicación entre los turnos Reportes de desempeño Comunicación en los proyectos Comunicación relacionada con cambios, excepciones y emergencias Capacitación en procesos nuevos o personalizados y Diseño de Servicios Comunicación de la estrategia y el diseño a los equipos de Operación del Servicio
Tome en cuenta que todas las comunicaciones deben entablarse con un propósito o acción resultante, y debe quedar claro quién es la audiencia. Dicha audiencia debe haber dado su entrada para determinar las necesidades de comunicación y para identificar lo que harán con ella. Aspectos como el medio de comunicación, la frecuencia o la ubicación no son fijos. Las organizaciones definirán estos aspectos, ya sea durante juntas, o usando correo electrónico o alguna funcionalidad dentro de las herramientas de gestión de servicios para cubrir sus necesidades. Una vez que se han definido los procesos, el contenido de las comunicaciones específicas puede permanecer bastante consistente, pero los medios disponibles están cambiando constantemente:
240
Correo electrónico para clientes tradicionales o dispositivos móviles Mensajes de Texto Instantáneos (IM) Voz sobre IP basada en computadora
Operación del Servicio
Teleconferencia, reuniones virtuales con capacidades de compartición de documentos
Es esencial que los interesados entiendan cómo utilizar efectivamente los medios de comunicación seleccionados. Adicionalmente, los medios de comunicación deben cumplir los objetivos de la comuni cación. Por ejemplo la necesidad de una comunicación segura – este objetivo puede hacer que se descarte el uso de mensajes de texto instantáneos. Se deben establecer políticas de comunicación dentro de los equipos o departamentos y para los procesos. Las políticas deben ser formales, pero no incómodas o complejas. Por ejemplo, un gerente de departamento puede requerir que todas las comunicaciones relativas a los cambios sean especificado enviadas pordentro correodeelectrónico. Puede nooperativos ser necesario definir una política para esto si ya está los procedimientos estándar.
241
Mejoramiento Continuo del Servicio
242
Mejoramiento Continuo del Servicio
Estrategia del Servicio, Diseño del Servicio, Transición del Servicio y Operación del Servicio, todos ellos t rabajan para soportar el enfoque de ciclo de vida. Mejorar el servicio, los procesos y la efectividad en el costo son metas constantes de Mejoramiento Continuo del Servicio (CSI).
Los objetivos de Mejoramiento Continuo del Servicio son:
Revisar, analizar, priorizar y dar recomendaciones sobre las oportunidades de mejora en cada etapa del ciclo de vida: Estrategia del Servicio, Diseño del Servicio, Transición del Servicio, Operación del Servicio y la misma CSI Revisar y analizar los logros en cuanto al nivel de servicio Identificar e implementar actividades específicas para mejorar la calidad del servicio de TI y mejorar la eficiencia y efectividad de los procesos habilitadores Mejorar la efectividad en el costo de entregar Servicios de TI sin sacrificar la satisfacción del cliente Garantizar que los métodos de gestión de calidad aplicables son utilizados para soportar las actividades de Mejoramiento Continuo Garantizar que los procesos tienen objetivos claramente definidos y mediciones que llevan a mejoras que se pueden traducir en acciones Entender exitoso qué se debe medir, por qué se está midiendo y qué resultado se considera como
243
Mejoramiento Continuo del Servicio
244
Mejoramiento Continuo del Servicio
Adoptar e implementar un enfoque estándar y consistente para Mejoramiento Continuo del Servicio:
Llevará a una mejora gradual y continua de la calidad del servicio, cuando se justifique Garantizará que los Servicios de TI permanezcan alineados continuamente a los requerimientos del negocio Se traducirá en mejoras graduales en la efectividad del costo a través de una reducción en los costos y/o la capacidad de absorber más trabajo al mismo costo Usará el monitoreo y reportes para identificar las oportunidades de mejora en todas las etapas del ciclo de vida y en todos los procesos Identificará oportunidades de mejora en las estructuras organizacionales, recursos, capacidades, socios, tecnología, habilidades y capacitación del personal y comunicaciones.
245
Mejoramiento Continuo del Servicio
El Registro CSI Se debe mantener un registro CSI categorizado para documentar las oportunidades de mejora. Cada oportunidad debe incluir información sobre el tamaño de la iniciativa (chica, mediana, grande), cantidad de tiempo que tomará (inmediato, mediano plazo, largo plazo), nivel de prioridad (alto, bajo) y beneficios potenciales. Otra consideración que se debe tomar es elevar automáticamente las prioridades conforme pasa el tiempo, para prevenir que los elementos de baja prioridad se queden hasta el fondo de la lista. El registro CSI es parte del Sistema de Gestión de Conocimientos del Servicio (SKMS).
246
Mejoramiento Continuo del Servicio
La figura de arriba muestra el enfoque al mejoramiento continuo del servicio e ilustra el ciclo continuo de mejora. Este enfoque para mejoras puede ser resumido como lo siguiente:
Contempla la visión con el entendimiento de los objetivos de negocio a un alto nivel. La visión debe alinear el negocio y las estrategias de TI
Evalúa la situación actual para obtener un correcto e imparcial estado actual de donde la organización se encuentra en este momento. Esta línea base es un análisis de la posición actual en términos del negocio, organización, gente, procesos y tecnología.
Entiende y está de acuerdo en las prioridades para mejoras basadas en un desarrollo profundo de los principios definidos en la visión. La visión completa puede estar a años de distancia pero este paso provee metas específicas y un tiempo administrable
Detalla el plan de mejoramiento continuo para alcanzar una provisión de servicios de alta calidad con la implementación o mejora de los procesos de la gestión de servicios de TI.
Verifica que las mediciones y métricas estén en su lugar y que los hitos se alcancen, el apego a los procesos es alto y que los objetivos de negocio y prioridades fueron alcanzados en su nivel de servicio.
Finalmente, el enfoque debe asegurar que el impulso de la mejora en la calidad es mantenida, asegurando que los cambios sean integrados en la organización.
247
Mejoramiento Continuo del Servicio
La toma de decisiones de Mejoramiento Continuo del Servicio necesita estar alineada con las metas y valores del negocio. El negocio necesita ser parte del proceso de toma de decisiones para aportar su opinión respecto a si una iniciativa de Mejoramiento Continuo del Servicio debe o no ser llevada a cabo. El enfoque de Mejoramiento Continuo del Servicio incluye preguntas clave para garantizar que tanto el negocio como TI sean considerados. Es importante entender estas preguntas para la ejecución y entrega de una iniciativa sin complicaciones con resultados positivos.
¿Cuál es la visión?
Entendiendo los objetivos del negocio a largo plazo.
¿Dónde estamos ahora?
Una línea base para los servicios.
¿Dónde queremos estar?
Normalmente expresado en términos de requerimientos de negocio. Una lista de oportunidades de mejora en el corto, mediano y largo plazo e iniciativas anotadas en el Registro de CSI.
¿Cómo llegamos ahí?
¿Llegamos ahí?
El logro es determinado a través del monitoreo, reporte y revisando los logros de de nivel de servicio así como el desempeño actual. ¿Cómo hacemos que el Los cambios deben estar incrustados en la organización para mantener el impulso por mejorar la calidad. ímpetu continúe?
248
Mejoramiento Continuo del Servicio
El propósito del proceso de Mejora en Siete Pasos es definir y gestionar los pasos necesarios para identificar, definir, reunir, procesar, analizar, presentar e implementar mejoras. Los objetivos del proceso de mejora en siete pasos son:
Identificar las oportunidades de mejorar los servicios, procesos, herramientas, etc. Reducir el costo de proveer servicios y garantizar que los Servicios de TI permitan que los resultados requeridos por el negocio sean alcanzados. Un objetivo claro será la reducción de costos, pero este no es el único criterio. Si como resultado la entrega o la calidad del servicio se ven reducidas, el impacto global será neutral o incluso negativo. Identificar qué necesita ser medido, analizado y reportado para establecer las oportunidades de mejora Revisar continuamente los logros del servicio para garantizar que sigan alineados a los requerimientos del negocio; alinear y realinear continuamente la provisión del servicio con los requerimientos de los resultados esperados Entender qué se debe medir, por qué está siendo medido y definir cuidadosamente cuál será el resultado exitoso
Cabe hacer notar que las mejoras en la calidad no deben ser implementadas si hay un costo asociado con la mejora y si este costo no está justificado.
249
Mejoramiento Continuo del Servicio
250
Mejoramiento Continuo del Servicio
El proceso de mejora es vital para el Mejoramiento Continuo del Servicio y se expande a toda la organización y a todo el ciclo de vida del servicio. Aunque es fácil identificar las etapas, con frecuencia es difícil entender cómo ocurre el proceso. Los pasos del proceso de mejora a más detalle son:
1. Identificar la estrategia para la mejora Identificar la visión global, la necesidad de negocio, la estrategia y las metas tácticas y operacionales 2. Definir qué se medirá En las etapas de planeación del ciclo de vida (Estrategia del Servicio y Diseño del Servicio) se deben identificar la línea base y las métricas. Con base en CSI, refiérase a ‘¿Dónde estamos ahora? ’ y ‘¿Dónde queremos estar? ’ para determinar ambas metas, las del negocio y las de TI. Para contestar la pregunta ‘¿Cómo llegamos ahí? ’ determine las brechas y establezca las oportunidades de mejora. 3. Obtener los datos Los datos son recopilados de distintas fuentes con base en las metas y los objetivos ‘¿Llegamos ahí? ’ Con frecuencia, identificados y responderán a la pregunta esto se hace ainicialmente través de Operación del Servicio y el resultado es una colección de datos sin procesar.
251
Mejoramiento Continuo del Servicio
4. Procesar los datos En referencia a los CSF y KPIs, los datos provenientes de diversas fuentes son procesados, alineados y puestos en contexto. Los periodos de tiempo son coordinados, los datos no alineados son reorganizados y se les da consistencia, y las brechas en los datos son identificadas. 5. Analizar la información y datos Un paso importante, y al que con frecuencia no se le da la debida atención, es el análisis de los datos. Conforme los datos son puestos en contexto, pasan de ser datos sin procesar a información que puede ser usada para responder a preguntas sobre las tendencias y su impacto al negocio. 6. Presentación y uso de la información Una vez que los datos han sido analizados, se comunican al negocio y a cualquier otro interesado para proporcionar un resumen de la iniciativa de mejora. La información debe ser presentada de modo que sea relevante y aplicable para su audiencia objetivo. En esta etapa es cuando se responde a la pregunta ¿Llegamos ahí?
7. Implementar las mejoras Ahora es cuando se pueden usar a información y las soluciones recopiladas en los pasos anteriores para mejorar los servicios y los procesos. Las iniciativas de mejora deben ser comunicadas a la organización. Es en este punto que se crea una nueva línea base y el proceso de mejora comienza nuevamente. El proceso de mejora actúa dentro de una espiral de conocimiento, más que en un grupo circular de actividades. Esto quiere decir que el conocimiento y la sabiduría adquiridos en un nivel de la organización se convierten en entradas de datos para el siguiente nivel.
252
Educación Pink Elephant - Ruta de desarrollo personal ¿Está considerando tomar un curso con Pink Elephant y no está seguro cuál? Revise esta tabla para saber cuál es el indicado para su necesidad.
Calificación Profesional para PRÁCTICAS de ITIL ® en la GESTIÓN DE SERVICIOS
El Ce rtificado en Fund amento s de IT IL de la Gestión de Servicios de TI PROGRA MA DE ESTUDI O
El Swirl Logo™ es una marca del Cabinet Office ITIL® es una marca registrada del Cabinet Office
© Crown Copyright 2013. This is a Crown Copyright value added product reproduced under license from the Cabinet Office. ITIL Foundation Certificate Syllabus_v5.5_Spanish (Latin American).docx_January 2013 Version Live) 5.5 (Status – Document owner – The Official ITIL Accreditor Page 1 of 11
El CERTIFICADO EN FUNDAMENTOS DE ITIL EN LA GESTIÓN DE SERVICIOS DE TI El propósito del certificado en Fundamentos de ITIL en la Gestión de Servicios de TI es confirmar que el candidato ha obtenido el conocimiento acerca de la terminología, la estructura y conceptos básicos de ITIL y ha comprendido los principios centrales de las prácticas de ITIL en la Gestión de Servicios. n o tiene la intención de El certificado en Fundamentos de ITIL en la Gestión de Servicios de TIde Servicios permitir que sus titulares apliquen las prácticas de ITIL en la Gestión sin una debida supervisión.
Grupo Objetivo El grupo objetivo del certificado en Fundamentos de ITIL en la Gestión de Servicios de TI incluye: •
•
Individuos que necesitan tener una comprensión básica del marco de trabajo de ITIL y cómo utilizarlo para mejorar la calidad de la gestión de servicios de TI dentro de una organización. Profesionales de TI que están trabajando en una organización que ha adoptado y adaptado ITIL y necesitan estar informados acerca de ello para así poder contribuir con un programa de mejora continua de servicios.
Éste puede incluir pero no está limitado a profesionales de TI, gerentes del negocio propietarios de procesos del negocio.
y a
Objetivos de Aprendizaje
Una vez que los candidatos hayan completado con éxito los requerimientos del curso de formación y el correspondiente examen d e esta certificación, ello s podrán conocer y entender las siguientes materias: • • • • • • • • •
Gestión de servicios como una práctica (comprensión) El ciclo de vida de servicios ITIL (comprensión) Conceptos genéricos y definiciones(concientización) Principios y modelos claves (comprensión) Procesos seleccionados (concientización) Funciones seleccionadas (concientización) Roles seleccionados (concientización) Tecnología y arquitectura (concientización) Competencias y formación (concientización)
© Crown Copyright 2013. This is a Crown Copyright value added product reproduced under license from the Cabinet Office.
Version Live)5.5 (Status –
Document owner Page 2 of 11
– The Official ITIL Accreditor
Programa de estudio de Fundamentos El programa de estudio guiará el diseño, desarrollo y uso de los materiales de formación, así como las sesiones de formación dirigidas a elevar el comprensión de las personas y las competencias en Gestión de Servicios de TI según se describe en las publicaciones de Estrategia del Servicio de ITIL, Diseño del Servicio de ITIL, Transición del Servicio de ITIL, Operación del Servicio de ITIL, Mejora Continua del Servicio de ITIL, Introducción a ITIL y Glosario de ITIL. El programa de estudio ha sido diseñado teniendo en mente que sea fácil de consultar, ampliar y actualizar su contenido.
Los candidatos para obtener el certificado en Fundamentos de ITIL en la Gestión de
Servicios de
TI deben completar todas las unidades y aprobar el examen correspondiente. Los proveedores de formación tienen la libertad de estructurar y organizar sus materiales de la manera que consideren más apropiada, siempre y cuando, las unidades de estudio que se presentan a continuación sean adecuadamente cubiertas. Se les recomienda en forma importante a los proveedores de formación que no estructuren sus cursos simplemente siguiendo el orden de las unidades de estudio según lo descrito en este documento. Este programa ha sido diseñado para darles la flexibilidad necesaria en el sentido que pueda añadir valor a sus cursos según lo consideren apropiado. El número de días de estudio recomendado es de 3, dentro de los cuales pueden incluir el examen final. Las unidades cubren los siguientes temas. Unidad ITILFND01
Contenido
Gestión de servicios como una práctica El propósito de esta unidad es ayudar al candidato a definir el concepto de servicio, y a entender y explicar e l concepto de gestión de servicios como una práctica. Específicamente, los candidatos deben poder: 01-1. Describir el concepto de mejores prácticas en el dominio público (SS 2.1.7, Fig 2.3) 01-2. Describir y explicar por qué ITIL es exitoso (SS 1.4) 01-3. Definir y explicar el concepto de servicio (SS 2.1.1) 01-4. Definir y explicar el concepto de clientes internos y externos (SS 3.2.1.2)
01-5. Definir y explicar el concepto de servicios internos y externos (SS 3.2.2.2)
01-6. Definir y explicar el concepto de gestión de servicio (SS 2.1.2) 01-7. Definir y explicar el concepto de gestión de servicio de TI(SS 2.1.3) 01-8. Definir y explicar el concepto de los interesados en la gestión de servicio (SS 2.1.5) 01-9. Definir procesos y funciones (SS 2.2.2, 2.2.3.1) 01-10. Explicar el modelo de proceso y las característ icas de los procesos (SS 2.2.2, Fig. 2.5)
El tiempo de estudio mínimo recomendado para esta unidad es de 1 hora 30 minutos. ITILFND02
El ciclo de vida del servicio de ITIL El propósito de esta unidad es ayudar al candidato a que entienda el valor del ciclo de vida del Servicio de ITIL, cómo se integran los procesos entre sí a través del ciclo de vida y explicar los objetivos, alcance y el valor para el negocio
© Crown Copyright 2013. This is a Crown Copyright value added product reproduced under license from the Cabinet Office.
Version Live)5.5 (Status –
Document owner Page 3 of 11
– The Official ITIL Accreditor
Unidad
Contenido
de cada fase en el ciclo de vida. Específicamente los candidatos deben poder: 02-2. Describir la estr uctura del ciclo de vida del s ervicio de ITIL (SS1. Introducción hasta 1.1 SS 1.2, Fig. 1.1) 02-3. Explicar el propósito, objetivos y alcance de la estrategia del servicio (SS 1.1.1, 1.1.2) 02-4. Explicar brevement e el valor que provee al negocio la estrategia del servicio (SS 1.1.4) 02-5. Explicar el propósito, objetivos y alcance del diseño del servicio (SD 1.1.1, 1.1.2) 02-6. Explicar brevemente el valor que provee al negocio el diseño del servicio (SD 1.1.4) 02-7. Explicar el propósi to, objetivos y alcance de transición del servicio (ST 1.1.1, 1.1.2) 02-8. Explicar brevem ente el valor que provee al negocio la transición del servicio (ST 1.1.4) 02-9. Explicar el propósito, objetivos y alcance operació n del servicio (SO 1.1.1, 1.1.2) 02-10. Explicar brevemente el valor que provee al negocio la operación del servicio(SO 1.1.4) 02-11. Explicar el propósito, objetivos y alcance Mejora Continua del Servicio (CSI 1.1.1, 1.1.2) 02-12. Explicar brevemente el valor que provee al negocio la mejora continua del servicio (CSI 1.1.4) Se recomienda que esta unidad sea cubierta dentro de otras unidades.
El tiempo de estudio mínimo recomendado para esta unidad es de 1 hora. ITILFND03
Conceptos y definiciones genéricas El propósito de esta unidad es ayudar al candidato a definir algunos de los términos claves y explicar los conceptos claves sobre gestión de servicios. Específicamente, los candidatos deben poder definir y explicar conceptos clave: 03-1. 03-2. 03-3. 03-4. 03-5. 03-6. 03-7. 03-8.
los siguientes
Utilidad y garantía (SS 2.1.6) Activos, recursos y competencias (SS 2.2.1) Portafolio de servicios (SS 4.2.4.1, Fig. 4.14) Catálogo de servicios (ambos tipos; dos-vistas y tres-vistas (SD4.2.2.5, Fig. 4.4, Fig. 4.5) Gobierno (SS 2.3.1) Caso de negocio (SS 3.6.1.1) Gestión de riesgo (SS 5.6.5.1, 5.6.5.2) Proveedor de servicio (SS 2.1.4)
03-10. Proveedor (SS 2.1.5) 03-11. Acuerdo del nivel de servicio (SLA) (SD 4.3.4) 03-12. Acuerdo del nivel operativo (OLA) (SD 4.3.4) 03-13. Contrato de soporte (SD 4.8.4.2) 03-14. Paquete de diseño del servicio (SD Apéndice A) 03-15. Disponibilidad (SD 4.4.4.3) 03-16. Sistema de gestión del conocimiento del s ervicio (SKMS) (ST 4.7.4.3) 03-17. Elemento de configuración (CI) (ST 4.3.4.2) © Crown Copyright 2013. This is a Crown Copyright value added product reproduced under license from the Cabinet Office.
Version Live)5.5 (Status –
Document owner Page 4 of 11
– The Official ITIL Accreditor
Unidad
Contenido
03-18. Sistema de Gestión de la Configuración (ST 4.3.4.3) 03-19. Biblioteca definitiva de medios (DML) (ST 4.3.4.4) 03-20. Cambio (ST 4.2.4.4) 03-21. Tipos de cambio (normal, estándar y de emergencia) (ST 4.2.4.7, 4.2.5.11)
4.2.4.3,
03-24. Evento (SO 4.1, 1 er párrafo) 03-25. Alerta (Glosario) 03-26. Incidente (SO 4.2 1 er párrafo) 03-27. Impacto, urgencia y prioridad (SO 4.2.5.4) 03-28. Solicitud de servicio (SO 4.3 1 er párrafo) 03-29. Problema (SO 4.4 1 er párrafo) 03-30. Solución temporal (SO 4.4.5.6) 03-31. Error conocido (SO 4.4.5.7) 03-32. Base de datos de errores conocidos (KEDB) (SO 4.4.7.2) 03-33. El rol de la comunicación en la operación del servicio (SO 3.6) 03-35. Política de liberaciones (ST 4.1.4.2) 03-36. Tipos de servicios (SS 3.2.2.4, Tabla 3.5) 03-37. Propuesta de cambios (ST 4.2.2.6) 03-38. Registro CSI (CSI 3.4) 03-39. Resultados (SS 2.1.1) 03-40. Patrones de actividad del negocio (SS 4.4.5.2) 03-41. Clientes y usuarios (SS 2.1.5) 03-42. El ciclo de Deming (Planificar-Hacer- Verificar-Actuar ) (CSI 3.8, Fig. 2.8)
Se recomienda que esta unidad sea parte de la formación y sea cubierta dentro de otras unidades.
ITILFND04
Principios y modelos claves El objetivo de esta unidad es ayudar al candidato a que entienda y de cuenta de los principios y modelos claves de la gestión de servicios y a balancear algunas de las fuerzas opuestas dentro de la gestión de servicios. Específicamente, los candidatos deben:
Estrategia del servicio 04-2. Describir la creación de valor a través de los servicios (SS 3.2.3, 3.2.3.1, Fig. 3.6, Fig. 3.7, no la s ección sobre mentalidad de mercadeo ”) “
Diseño del servicio 04-3. Comprender la importancia de las personas, procesos, productos y asociados para la gestión de servicios (SD 3.1.5, Fig. 3.3) 04-4. Entender los cinco aspectos principales del diseño del servicio (SD 3.1.1): •
• • •
Soluciones de servicios para aquellos que son nuevos ó modificados Sistemas de información gerencial y herramientas Arquitecturas de tecnología y arquitecturas de gestión Procesos requeridos
© Crown Copyright 2013. This is a Crown Copyright value added product reproduced under license from the Cabinet Office.
Version Live)5.5 (Status –
Document owner Page 5 of 11
– The Official ITIL Accreditor
Unidad
Contenido •
Métodos de medición y métricas
Mejora continua del servicio 04-9. Explicar el enfoque de mejora continua del ser vicio (CSI 3.1, 3.1.1, Fig. 3.1) 04-10. Entender el rol de la medición en la mejora continua del servicio y explicar los siguientes elementos claves: •
• •
Relación entre los factores críticos de éxito (CSF) y los indicadores de desempeño (KPI) (CSI 5.5.1) Líneas baseclaves (CSI 3.9.1) Tipos de métricas (métricas de tecnología, métricas de proceso, métricas de servicio) (CSI 5.5)
El tiempo de estudio mínimo recomendado para esta unidad es de 1 hora y 30 minutos. ITILFND05
Procesos
El propósito de esta unidad es ayudar al candidato a que entienda como los procesos de gestión de servicios contribuyen al ciclo de vida del servicio ITIL, a explicar el propósito, los objetivos, el alcance, los conceptos básicos, las actividades e interfaces de los cuatro procesos centrales, y a expresar el propósito, los objetivos, y alcance de los dieciochos procesos restantes. La lista de actividades a ser incluida en cada proceso es el mínimo no debe ser interpretado como una lista exhaustiva.
requerido y
Específicamente, los candidatos deben poder:
Estrategia del servicio 05-2. Explicar el propósito, objetivos y alcance de: 05-21. Gestión del portafolio de servicios (SS 4.2.1, 4.2.2) •
El portafolio de servicios (SS 4.2.4.1, Fig. 4.14)
05-22. Gestión financiera para servicios de TI (SS 4.3.1, •
4.3.2)
Caso de negocio (SS 3.6.1.1)
05-23. Gestión de relaciones de negocio (SS 4.5.1, 4.5.2, Tabla 4.10)
Diseño del servicio 05-3. Explique el propósito, objetivos, alcance, conceptos básicos, actividades del proceso e interfaces de: 05-31. Gestión de niveles de servicio(SLM) (SD 4.3.1, 4.3.2, 4.3.6.4) Se debe cubrir la siguiente lista:
© Crown Copyright 2013. This is a Crown Copyright value added product reproduced under license from the Cabinet Office.
Version Live)5.5 (Status –
Document owner Page 6 of 11
– The Official ITIL Accreditor
Unidad
Contenido • • • •
SLA basado en servicio (SD 4.3.5.1) SLAs multi-nivel (SD 4.3.5.1, Fig.4.7) Requerimientos de niveles de servicio (SLR) (SD 4.3.5.2) Diagrama de monitoreo de SLA (SLAM) (SD 4.3.5.5, CSI Fig. 4.4)
• • •
Revisión del servicio (SD 4.3.5.6) Plan de mejora del servicio (SIP) (SD 4.3.6.3) La relación entre SLM y BRM (SD 4.3.2.1)
05-4. Explicar el propósito, los objetivos y alcance de: 05-41. Gestión del catálogo de servicios (SD 4.2.1, 4.2.2) 05-42. Gestión de la disponibilidad (SD 4.4.1, 4.4.2) • • • • • •
Disponibilidad del servicio (SD 4.4.4.2) Disponibilidad del componente (SD 4.4.4.2) Confiabilidad (SD 4.4.4.3) Capacidad de dar mantenimiento (SD 4.4.4.3) Capacidad de dar servicio (SD 4.4.4.3) Función vital del negocio (VBF) (SD 4.4.4.3)
05-43. Gestión de la seguridad de la información (ISM) (SD 4.7.1, 4.7.2) •
Política de la seguridad de la información (SD 4.7.4.1)
05-44. Gestión de proveedores (SD 4.8.1, 4.8.2) •
Categorías de proveedores (SD 4.8.5.3, Fig. 4.28)
05-45. Gestión de la capacidad (SD 4.5.1, 4.5.2) • • • •
Plan de la capacidad (SD 4.5.6.3) Gestión de la capacidad del negocio (SD 4.5.4.3) Gestión de la capacidad del servicio (SD 4.5.4.3) Gestión de la capacidad del componente (SD 4.5.4.3)
05-46. Gestión de la continuidad del servicio de TI (SD 4.6.1, • •
4.6.2)
Propósito del análisis de impacto al negocio (BI 4.6.5.2)A) (SD Evaluación del riesgo (SD 4.6.5.2)
05-47. Coordinación del diseño (SD 4.1.1, 4.1.2)
Transición del servicio 05-5. Explique el propósito, objetivos, alcance, conceptos básicos, actividades del proceso e interfaces de: 05-51. Gestión de cambios (ST 4.2.1, 4.2.2, 4.2.4.6, 4.2.6.4, 4.2.6.5) • • • •
Tipos de solicitudes de cambio (ST 4.2.4.3) Modelos de cambio(ST 4.2.4.5) Plan de rectificación (ST 4.2.4.8) Comité asesor de cambios / Comité asesor de
cambios de
© Crown Copyright 2013. This is a Crown Copyright value added product reproduced under license from the Cabinet Office.
Version Live)5.5 (Status –
Document owner Page 7 of 11
– The Official ITIL Accreditor
Unidad
Contenido •
emergencia (ST 4.2.5.10, 4.2.5.11) Ciclo de vida de un cambio normal (ST 4.2.5, Fig. 4.2)
05-6. Explicar el propósito, los objetivos y alcance de: 05-61. Gestión de liberación e implementación (ST 4.4.1, 4.4.2) Las cuatros fases de liberación e implementación (ST 4.4.5, Fig.
•
4.23)
05-62. Gestión del conocimiento (ST 4.7.1, 4.7.2) •
Datos-a-inform ación-a- conocimiento-a-sabi duría (DIKW) & SKMS (ST 4.7.4.2, 4.7.4.3, Fig. 4.36)
05-63. Gestión de activos de servicio y configuración (SACM)
(ST 4.3.1,
4.3.2)
05-64. Planificación de la transición y soporte (ST 4.1.1, 4.1.2)
Operación del servicio 05-7. Explique el propósito, objetivos, alcance, conceptos básicos, actividades del proceso e interfaces de: 05-71. Gestión de incidentes (SO 4.2.1, 4.2.2, 4.2.4.2, 4.2.5, 4.2.6.4) 05-72. Gestión de problemas (SO 4.4.1, 4.4.2, 4.4.4.2, 4.4.5, 4.4.6.4, sección sobre las técnicas de análisis de problemas)
no la
Especificar los objetivos y conceptos básicos de: 05-8. Explicar el propósito, los objetivos y alcance de: 05-81. Gestión de eventos (SO 4.1.1, 4.1.2) 05-82. Cumplimiento de solicitudes (SO 4.3.1, 4.3.2) 05-83. Gestión de acceso (SO 4.5.1, 4.5.2)
Mejora continua del servicios 05-9. Explicar el propósito, los objetivos y alcance de: 05-91. El proceso de mejora en 7 pasos (CSI 3.9.3.1, 4.1, 4.1.1, 4.1.1, 4.1.2, Fig. 3.4)
El tiempo de estudio mínimo recomendado para esta unidad es de 10 horas y 45 minutos ITILFND06
Funciones
El propósito de esta unidad es ayudar al candidato a que explique el rol, los objetivos y las estructuras organizacionales de la función del service desk y a © Crown Copyright 2013. This is a Crown Copyright value added product reproduced under license from the Cabinet Office.
Version Live)5.5 (Status –
Document owner Page 8 of 11
– The Official ITIL Accreditor
Unidad
Contenido
decir el rol, objetivos y el sol apamiento que hay en las o tras tres funciones. Específicamente, los candidatos deben poder: 06-1. Explicar el rol, los objetivos, y las estructuras organizacionales de: •
La función del service desk (SO 6.3, 6.3.1, 6.3.2, 6.3.3, 6.3, 6.4)
Figs. 6.2,
06-2. Explicar el rol, los objetivos de: •
•
•
La función de gestión técnica (SO 6.4.1, 6.4.2) La función de gestión de aplicaciones (SO 6.4.1, 6.6.2) con desarrollo de aplicaciones (SO 6.6.6.1, Tabla 6.2) La función de gestión de operaciones de TI (control de operaciones de TI y gestión de Instalaciones) (SO 6.5.1, 6.5.2)
El tiempo de estudio mínimo recomendado para esta unidad es de 1 hora.
ITILFND07
Roles
El propósito de esta unidad es ayudar al candidato a dar cuenta y concientizar las responsabilidades de algunos de los principales roles en la Gestión de Servicios Específicamente, los candidatos deben poder: 07-1. Explicar el rol y las responsabilidades del • • •
•
Dueño del proceso (SD 6.3.2) Gerente del proceso (SD 6.3.3) Especialista del proceso (SD 6.3.4) Dueño del servicio (CSI 6.3.1)
07-2. Reconocer el modelo RACI (responsable, responsable final, consultado e informado) y explicar su rol en la definición de la estructura organizacional. (SD 3.7.4.1, tabla 3.2, no RASI-VS ni RASCI)
El tiempo de estudio mínimo recomendado para esta unidad es de 45 minutos. ITILFND08
Tecnología y arquitectura El propósito de esta unidad es ayudar al candidato a 08-2. Entender como la automatización del servicio ayuda integración de los procesos de gestión de servicios (SS 7.1)
con
la
Se recomienda que esta unidad sea parte de la formación y sea cubierta dentro de otras unidades. ITILFND09
Competencias y formación
© Crown Copyright 2013. This is a Crown Copyright value added product reproduced under license from the Cabinet Office.
Version Live)5.5 (Status –
Document owner Page 9 of 11
– The Official ITIL Accreditor
Unidad
Contenido
09-1. Competencias y habilidades par a la gestión de servicios (SD 6.5.1) 09-2. Competencias y marco de habilidades (SD 6.5.2) 09-3. Formación (SD 6.5.3).
Esta unidad no se examina. El tiempo de estudio es de 15 minutos. ITILFND10
Examen de prueba El propósito de esta unidad es ayudar a que el candidato apruebe el Fundamentos de ITIL
examen de
Específicamente, los candidatos deben: 10-1. Como mínimo deben Fundamentos de ITIL
completar
un examen
de práctica
de
El período de estudio mínimo recomendado para esta unidad es de 2 horas, incluyendo el repaso.
© Crown Copyright 2013. This is a Crown Copyright value added product reproduced under license from the Cabinet Office.
Version Live)5.5 (Status –
Document owner Page 10 of 11
– The Official ITIL Accreditor
Formato del Examen Este programa de estudio está acompañado por un examen el cual el candidato debe conseguir una puntuación de aprobación para obtener el Certificado en Fundamentos de ITIL en la Gestión de Servicios de TI. Tipo:
Selección múltiple, 40 preguntas. Las preguntas se seleccionan de un banco de preguntas de Fundamentos de ITIL en la Gestión de Servicios de TI
Duración:
Máximo 60 minutos para todos los candidatos en sus propios idiomas.
Tiempo adicional previsto por razones de idioma
Candidatos que completen un examen: •
En un idioma que no sea su lengua materna
Tienen un máximo de 75 minutos para completar el examen y permite utilizar un diccionario
se les
Prerrequisitos:
Es altamente recomendable asistir a un curso formal de Fundamentos de ITIL que este acreditado, pero no es un prerrequisito.
Supervisado:
Sí
Libro Abierto:
No
Nota mínima para aprobar:
26 de 40 ó 65%
Entrega:
El examen está disponible en línea ó en papel.
© Crown Copyright 2013. This is a Crown Copyright value added product reproduced under license from the Cabinet Office.
Version Live)5.5 (Status –
Document owner Page 11 of 11
– The Official ITIL Accreditor
Examen d e F un dam entos de I TI L
®
Ejemplo A, versión 5.1 Selección Múltiple
Instrucciones
1. 2. 3. 4.
Debe intentar contestar todas las 40 preguntas. Marque sus respuestas en la hoja de respuestas entregada Usted tiene 60 minutos para contestar el examen Usted debe responder correctamente al menos 26 de las 40 preguntas (65%) para aprobar el examen.
Version 5.1 (Live)
© The Official ITIL Accreditor 2012 El Swirl Logo™ es una marca del Cabinet Office ITIL® es una marca registrada del Cabinet Office ITIL Foundation Sample A_v5.1_Spanish (Latin American) This document must not be reproduced without express permission from The Accreditor Owner – The Official ITIL Accreditor Page 1
1.
¿Qué tipos de cambios NO suelen incluirse en el alcance de la gestión del cambio? a)
Los cambios a la computadora central
b)
Cambios en la estrategia del negocio
c) Cambios al acuerdo de niveles de servicios (SLA) d) El retiro de un servicio
2.
¿Cuál de los siguientes enunciados NO es un propósito de operación del servicio? a) para Llevar a cabo pruebas para asegurar que los servicios están diseñados satisfacer las necesidades del negocio b) Entregar y gestionar servicios de TI c) Gestionar la tecnología utilizada para entregar servicios d) Monitorear el desempeño de la tecnología y los procesos
3.
¿A qué se refiriere el término control de operaciones de TI? a)
La gestión de la función de gestión técnica y de la función de gestión de aplicaciones
b) Supervisar la ejecución y monitoreo de las actividades operacionales y eventos c) Un conjunto de herramientas que se utilizan para monitorear y visualizar el estado de la infraestructura de TI y aplicaciones d) Un service desk monitoreando el estado de la infraestructura cuando los operadores no están disponibles 4.
¿Qué proceso es responsable de registrar las relaciones entre los componentes del servicio? a) Gestión de niveles del servicio b) Gestión de portafolio de servicios c) Gestión de activos de servicios y configuración (SACM) d) Gestión de incidentes
Version 5.1 (Live)
© The Official ITIL Accreditor 2012 This document must not be reproduced without express permission from The Accreditor ITIL Foundation Sample A_v5.1_Spanish (Latin American) Owner – The Official ITIL Accreditor Page 2
5.
¿Para qué se utiliza el modelo RACI? a) Documentar las funciones y responsabilidades de los interesados en un proceso o actividad b) Definir requerimientos para un nuevo servicio o proceso c) Analizar el impacto de un incidente en el negocio d) Crear un balanced scorecard que muestra el estado global de la gestión de servicios
6.
¿Cuál de las siguientes afirmaciones es la MEJOR descripción de un acuerdo de nivel operativo (OLA)? a) Un acuerdo entre un proveedor de servicios de TI y otra parte de la misma organización que colabora en la prestación de servicios b) Un acuerdo escrito entre el proveedor de servicios de TI y sus clientes el cual define las metas clave y responsabilidades de ambas partes c) Un acuerdo entre dos proveedores de servicios sobre los niveles de servicio requeridos por el cliente d) Un acuerdo entre un service desk externo y el cliente de TI acerca de los tiempos de respuesta y de reparación.
7.
¿Cuál es el propósito PRINCIPAL de la gestión de disponibilidad? a) Monitorear e informar la disponibilidad de los componentes b) Asegurar que se cumplen todas las metas del acuerdo de nivel de servicios (SLA) c) Garantizar los niveles de disponibilidad de los servicios y componentes d) Asegurar que la disponibilidad del servicio satisface las necesidades acordadas del negocio
8.
¿Cuáles de las siguientes acciones están incluidas en la guía que provee la transición del servicio? 1. Introducir nuevos servicios 2. Retirar servicios 3. Transferir servicios entre proveedores de servicios a) Sólo 1 y 2 b) Sólo 2 c) Todas las anteriores d) Sólo 1 y 3
Version 5.1 (Live)
© The Official ITIL Accreditor 2012 This document must not be reproduced without express permission from The Accreditor ITIL Foundation Sample A_v5.1_Spanish (Latin American) Owner – The Official ITIL Accreditor Page 3
9.
¿Cuál de los siguientes títulos NO es una etapa del ciclo de vida del servicio? a) Optimización del servicio b) Transición del servicio c) Diseño del Servicio d) Estrategia del servicio
10. ¿Cuál de las siguientes afirmaciones sobre un sistema de gestión de configuración (CMS) es la CORRECTA? a) El CMS no debe contener datos corporativos acerca de los clientes y usuarios b) Puede haber más de un CMS c) No debe haber más de una base de datos de gestión de la configuración (CMDB) d) Si una organización externaliza sus servicios de TI todavía hay una necesidad de un CMS
11. ¿Cuáles son los tres sub-procesos de gestión de la capacidad? a) Gestión de capacidad del negocio, gestión de capacidad del servicios y gestión de capacidad de los componentes b) Gestión de capacidad de los proveedores, gestión de capacidad del servicio y gestión de capacidad de los componentes c) Gestión de capacidad de los proveedores, gestión de capacidad del servicio y gestión de capacidad de la tecnología d) Gestión de capacidad del negocio, gestión de capacidad de la tecnología y gestión de capacidad de los componentes
12. ¿Cuáles de los siguientes elementos serían almacenados en la biblioteca definitiva de medios (DML)? 1. Copias de software comprado 2. Copias de software desarrollado internamente 3. Documentación relevante de la licencia 4. Calendario de cambios a) Todas las anteriores b) Sólo 1 y 2 c) Sólo 3 y 4 d) Sólo 1, 2 y 3
Version 5.1 (Live)
© The Official ITIL Accreditor 2012 This document must not be reproduced without express permission from The Accreditor ITIL Foundation Sample A_v5.1_Spanish (Latin American) Owner – The Official ITIL Accreditor Page 4
13. ¿Qué proceso es responsable de revisar los acuerdos de nivel operativo (OLA) de manera regular? a) Gestión de proveedores b) Gestión de niveles de servicio c) Gestión del portafolio de servicios d) Gestión de demanda
14. ¿Qué rol debe asegurar que la documentación del proceso esté vigente y disponible? a) El propietario del servicio b) El director de Informática (CIO) c) Gestión del conocimiento d) El propietario del proceso
15.
¿Cuál de las siguientes acciones son realizadas por la gestión de liberación e implementación? 1. Definir y acordar los planes de liberaciones e implementación 2. Asegurar que se pueda rastrear la liberación de paquetes 3. Autorizar cambios para apoyar el proceso a) Sólo 1 y 2 b) Todas las anteriores c) Sólo 2 y 3 d) Sólo 1 y 3
16.
¿Cuáles de los siguientes conceptos son características de todo proceso? 1. Es medible 2. Entrega un resultado especifico 3. Entrega sus resultados básicos a un cliente o interesados a) Sólo 1 y 3 b) Sólo 1 y 2 c) Sólo 2 y 3 d) Todos los anteriores
Version 5.1 (Live)
© The Official ITIL Accreditor 2012 This document must not be reproduced without express permission from The Accreditor ITIL Foundation Sample A_v5.1_Spanish (Latin American) Owner – The Official ITIL Accreditor Page 5
17. ¿Cuál de los siguientes conceptos son las características principales de ITIL que contribuyen a su éxito? 1. Es neutral al respecto de los proveedores 2. No es prescriptivo 3. Es una mejor práctica 4. Es un estándar a) Sólo 3 b) Sólo 1, 2 y 3 c) Todos los anteriores d) Sólo 2, 3 y 4 18. ¿Quién debe tener acceso a la política de seguridad de la información? a) Altos ejecutivos del negocio y el personal de TI b) Altos ejecutivos del negocio, los ejecutivos de TI y el gerente de seguridad de la información c) Todos los clientes, los usuarios y el personal de TI d) Sólo el personal de la gestión de seguridad de la información
19. ¿Cuál de los siguientes elementos son válidos en un paquete de diseño de servicios (SDP)? 1. 2. 3. 4.
Requerimientos de negocio acordados y documentados Un plan de transición para un servicio Requerimientos para un proceso nuevo ó modificado Métricas para medir el servicio
a) Sólo 1 b) Sólo 2 y 3 c) Sólo 1, 2 y 4 d) Todos los anteriores
20. ¿Cuáles son ejemplos de herramientas que podrían ayudar en la etapa de transición de servicios de ciclo de vida del servicio? 1. Una herramienta para almacenar versiones definitivas de software 2. Una herramienta de flujo de trabajo para gestión de cambios 3. Una herramienta de distribución automatizada de software 4. Herramientas de pruebas y validación a) Sólo 1, 3 y 4 b) Sólo 1, 2 y 3 c) Todos los anteriores
Version 5.1 (Live)
© The Official ITIL Accreditor 2012 This document must not be reproduced without express permission from The Accreditor ITIL Foundation Sample A_v5.1_Spanish (Latin American) Owner – The Official ITIL Accreditor Page 6
d) Sólo 2, 3 y 4 21. ¿Cuál de las siguientes afirmaciones sobre la gestión de problemas es / son CORRECTAS? 1. Asegura que todas las soluciones definitivas o soluciones temporales que requieren un cambio en un elemento de configuración (CI) son enviados a través de la gestión del cambio 2. Proporciona información de la gestión acerca del costo de resolver y prevenir problemas a)
Sólo 1
b)
Sólo 2
c) Ambos d)
Ninguno
22. ¿Cuál es el propósito del proceso de cumplimiento de solicitudes? a) Tramitar las solicitudes de servicio de los usuarios b) Asegurar que todas las solicitudes dentro de una organización de TI se cumplan c) Asegurar cumplimiento de una solicitud de cambio d) Asegurar que los acuerdos de nivel de servicio (SLA) son cumplidos
23. ¿Cuál de las siguientes declaraciones acerca de la creación de valor a través de los servicios es CORRECTA? a) La percepción que el cliente tiene acerca del servicio es un factor importante en la creación de valor b) El valor de un servicio únicamente puede medirse en términos financieros. c) Entregar los resultados de un proveedor de servicios es importante en el valor de un servicio d) Las preferencias del proveedor de servicios determinan la percepción del valor de un servicio
24. ¿Cuál de las siguientes afirmaciones acerca de los clientes internos y externos es la correcta? a) Los clientes externos deben recibir un mejor servicio al cliente, ya que pagan por sus servicios de TI b) Los clientes internos recibir un mejor servicio al cliente debido a que pagan salarios de losdeben empleados c) El mejor servicio al cliente se debe darse al cliente que paga más dinero d) Clientes internos y externos deben recibir el nivel de servicio al cliente que se ha acordado
Version 5.1 (Live)
© The Official ITIL Accreditor 2012 This document must not be reproduced without express permission from The Accreditor ITIL Foundation Sample A_v5.1_Spanish (Latin American) Owner – The Official ITIL Accreditor Page 7
25. ¿Cuál de los siguientes atributos debe entregar los servicios de TI a los clientes? a) Competencias (capabilities) b) Costo c) Riesgo d) Valor
26.
¿Cuál de las siguientes actividades es parte del proceso de gestión de niveles de servicio (SLM)? a) El diseño del sistema de gestión de la configuración desde una perspectiva de negocio b) La creación de métricas tecnológicas para alinearse con las necesidades del cliente c) Monitoreo del desempeño de servicios comparado con los acuerdos de niveles de servicio (SLAs) d) Formación personal del service desk en cómo lidiar con las quejas de los clientes sobre el servicio
27. ¿Cuál de las siguientes afirmaciones resume MEJOR el propósito de la gestión de eventos? a) La habilidad de detectar eventos, darles sentido y determinar las medidas de control apropiadas b) La habilidad de detectar eventos, restablecer el servicio a la normalidad tan pronto como sea posible y minimizar el impacto adverso en las operaciones del negocio c) La habilidad de monitorear y controlar las actividades del personal técnico d) La habilidad de informar sobre la entrega exitosa de los servicios al comprobar el tiempo de funcionamiento de los dispositivos de la infraestructura
28. ¿Cuál de los siguientes elementos debe aparecer en un catálogo de servicios? a) La información sobre las versiones de todo el software b) La estructura organizacional de la compañía c) Información de activos d) Detalles de todos los servicios en operación
Version 5.1 (Live)
© The Official ITIL Accreditor 2012 This document must not be reproduced without express permission from The Accreditor ITIL Foundation Sample A_v5.1_Spanish (Latin American) Owner – The Official ITIL Accreditor Page 8
29.
¿Qué significa “Garantía de un servicio”? a) El servicio es adecuado para el propósito b) No habrá fallas en las aplicaciones ni en la infraestructura asociada al servicio c) Todos los problemas relacionados con el servicio se solucionan gratuitamente durante un período determinado de tiempo d) A los clientes se les aseguran ciertos niveles de disponibilidad, capacidad, continuidad y seguridad
30. ¿Cuál es la primera actividad del enfoque de la mejora continua del servicio (CSI)? a) Entender la visión y objetivos del negocio b) Llevar a cabo una evaluación inicial para conocer la situación actual c) Acordar las prioridades para la mejora d) Crear y verificar un plan
31. ¿Cuál de las siguientes afirmaciones es una ventaja que se obtiene al utilizar un modelo de incidente? a) Hará que los problemas sean más fáciles de identificar y diagnosticar b) Significa que los tipos de incidentes conocidos no se repetirán c) Proporciona pasos predefinidos para manejar determinados tipos de incidentes d) Asegura que todos los incidentes son fáciles de resolver
32. ¿Cuál de los siguientes enunciados indica la secuencia CORRECTA de actividades para el manejo de un incidente? a) Identificación, registro, categorización, priorización, diagnóstico inicial, escalamiento, investigación y diagnóstico, resolución y recuperación, cierre b) Priorización, identificación, registro, categorización, diagnóstico inicial, escalamiento, investigación y diagnóstico, resolución y recuperación, cierre c) Identificación, registro, diagnóstico inicial, categorización, priorización, escalamiento, resolución y recuperación, investigación y diagnóstico, cierre d) Identificación, diagnóstico inicial, investigación, registro, categorización, escalamiento, priorización, resolución y recuperación, cierre
Version 5.1 (Live)
© The Official ITIL Accreditor 2012 This document must not be reproduced without express permission from The Accreditor ITIL Foundation Sample A_v5.1_Spanish (Latin American) Owner – The Official ITIL Accreditor Page 9
33. ¿Qué etapa del ciclo de vida del servicio asegura que los métodos de medición proporcionarán las métricas necesarias para los servicios nuevos o modificados? a) Diseño del servicio b) Operación del servicio c)
Estrategia del servicio
d) Entrega del servicio
34. ¿Cuál de los siguientes procesos tienen que ver con la gestión de riesgos de los servicios? 1. Gestión de continuidad del servicio de TI 2. Gestión de seguridad de la información 3. Gestión del catálogo de servicios a) Todos los anteriores b) Sólo 1 y 3 c) Sólo 2 y 3 d) Sólo 1 y 2
35. ¿Cuál de las siguientes alternativas NO es un tipo de métrica que se describe en la mejora continua del servicio (CSI)? a)
Métricas del proceso
b)
Métricas del servicio
c)
Métricas de personal
d) Métricas tecnológicas
36. ¿Qué afirmación sobre la relación entre el sistema de gestión de configuración (CMS) y el sistema de gestión del conocimiento de servicios (SKMS) es la CORRECTA? a) El SKMS es parte de la CMS b) El CMS es parte del SKMS c) El CMS y el SKMS son la misma cosa d) No existe una relación entre el CMS y el SKMS
Version 5.1 (Live)
© The Official ITIL Accreditor 2012 This document must not be reproduced without express permission from The Accreditor ITIL Foundation Sample A_v5.1_Spanish (Latin American) Owner – The Official ITIL Accreditor Page 10
37.
¿Cuál es el rol del comité asesor de cambios de emergencia (ECAB)? a) Para asegurarle al gerente de cambios que cambios no urgentes se realizarán durante periodos de negocio particularmente volátiles b) Para ayudar al gerente de cambios en la implementación de cambios de emergencia c) Para ayudar al gerente de cambios en la evaluación de los cambios de emergencia y decidir si deben ser autorizados d) Para ayudar al gerente de cambios en la aceleración del proceso de cambio de emergencia para que no se produzcan retrasos inaceptables
38.
¿Cuál de las siguientes afirmaciones sobre el service desk es / son CORRECTAS? 1. El service desk es una función que proporciona un medio de comunicación entre la TI y los usuarios sobre todas las cuestiones operativas 2. El service desk debe ser el propietario del proceso de gestión de problemas a)
Sólo 2
b)
Sólo 1
c) Ambos d) Ninguno
39. ¿Cuál de las siguientes alternativas es la lista correcta de las cuatro P del diseño del servicio? a) Planificación, productos, posición, procesos b) Planificación, perspectiva, posición, personas c) Perspectiva, socios (partners), problemas, personas d) Personas, socios (partners), productos, procesos
40.
¿Cuál de las siguientes alternativas representa la MEJOR acción a ejecutar cuando se consigue una solución temporal a un problema? a) Se cierra el registro del problema b) El registro de problemas permanece abierto y los detalles de la solución temporal son documentados en el registro c) El registro de problemas permanece abierto y los detalles de la solución temporal son documentados en todos los registros de los incidentes relacionados d) Se cierra el registro del problema y los detalles de la solución temporal son documentados en una solicitud de cambio(RFC)
Version 5.1 (Live)
© The Official ITIL Accreditor 2012 This document must not be reproduced without express permission from The Accreditor ITIL Foundation Sample A_v5.1_Spanish (Latin American) Owner – The Official ITIL Accreditor Page 11
Version 5.1 (Live)
© The Official ITIL Accreditor 2012 This document must not be reproduced without express permission from The Accreditor ITIL Foundation Sample A_v5.1_Spanish (Latin American) Owner – The Official ITIL Accreditor Page 12
Exa m en de Fund amentos de IT IL
®
Ejemplo A, versión 5.0
Opción múltiple
RESPUE STAS Y RA CIONALES
© Acreditador oficial ITIL 2011 El logo™ es marca registrada de la oficina de gobierno ITIL® es marca registrada de la oficina de gobierno Examen de Fundamentos de ITIL Ejemplo A Respuestas y Racionales v5.1 Este documento no debe ser reproducido sin permiso expreso el Acreditador
P
R
Referencia Libro
Racional
B
Referencia Plan de estudios 05-51
1
ST 4.2.4.3
2
A
02-09
SO 1.1.1
3
B
06-02
SO 6.5.1.1
4
C
05-63
ST 4.3.1
5
A
07-02
6
A
03-12
SD 3.7.4.1 SD 4.3.4
7
D
05-42
SD 4.4.1
8
C
02-07
ST 1.1.1
9 10
A D
02-02 03-18
SS 1.2 ST 4.3.4.3
11
A
05-45
12
D
03-19
SD 4.5.4.3 ST 4.3.4.4
13
B
05-31
SD 4.3.1
14
D
07-01
SD 6.3.2
Un requerimiento de cambio es una comunicación formal que busca la alteración a uno o más elementos de configuración (CI). Servicios, SLA y computadoras son ejemplos de CIs. Una estrategia de negocio no es un CI y debería estar fuera del alcance de la Gestión de Cambios Cada uno son propósitos de Operación de Servicio excepto la opción A, realizar pruebas para asegurar que los servicios son diseñados para cumplir con necesidades del negocio. La opción A es parte de Transición del Servicio Control de operaciones de TI supervisa la ejecución y monitoreo de actividades operativas y eventos en la infraestructura de TI Parte del propósito de Configuraciones es mantener la información precisa de los activos, incluyendo las relaciones entre estos RACI es un modelo de responsabilidad usado por ITIL para ayudar a definir roles y responsabilidades A es el OLA, B es la definición de un SLA, C no es definición de ITIL, D involucra proveedores externos y es un contrato A es un elemento de soporte de Gestión de la disponibilidad, no un propósito principal. B es parte de Gestión de Niveles de Servicio. Gestión de la Disponibilidad no ofrece garantías como esta definido en C. D es el propósito principal de Gestión de la Disponibilidad “asegurar que los niveles de disponibilidad entregados en todos los servicios de TI cumplen los requerimientos de disponibilidad del negocio” Los tres están en el alcance de Transición del Servicio así como los tres están involucrados en cambios mayores Optimización del servicio es la respuesta correcta A: un CMS pude contener datos corporativos de usuarios/ clientes como ubicación y departamento. B y C: puede haber más de una CMDB pero serán parte de un único CMS. D: es la correcta, un CMS ayuda a controlar y reportar sobre la infraestructura aun cuando los servicios de TI están en outsourcing Negocio, servicio y componentes son los 3 subprocesos de Gestión de la Capacidad La DML contiene copias maestras de todo el software controlado en una organización junto con documentos de licencias o información relevante. El calendario de cambio no debe estar incluido Gestión de niveles de servicio tiene la responsabilidad de negociar y acordar los OLAs Un dueño de proceso debe asegurar que la
© Acreditador oficial ITIL 2011 El logo™ es marca registrada de la oficina de gobierno ITIL® es marca registrada de la oficina de gobierno Examen de Fundamentos de ITIL Ejemplo A Respuestas y Racionales v5.1 Este documento no debe ser reproducido sin permiso expreso el Acreditador
15
A
05-61
ST 4.4.1
16
D
01-10
SS 2.2.2
17
B
01-02
SD 1.4
18
C
05-43
SD 4.7.4.1
19
D
03-14
SD App A
20
C
08-02
SS 7.1
21
C
05-72
22
A
05-82
SO 4.4.2 and 4.4.6.4 SO 4.3.1
23
A
04-02
SS 3.2.3
24
D
01-04
25
D
01-03
SS 3.2.1.2 SS 2.1.1
26
C
05-31
SD 4.3.5.6
documentación del proceso esté actualizada y disponible Las 2 respuestas correctas (1 y 2) están incluidas en los objetivos de liberación e implementación. La opción 3 es de gestión de cambios Medible, resultados específicos y entrega de resultados a un cliente o grupo de interés son todas características de un proceso La opción 4 es correcta, ITIL no es un estándar: ISO/IEC 20000 es un ejemplo de estándar. ITIL es neutral de proveedores y provee un marco de trabajo de buenas prácticas En la disponibles mayoría de alostodos casos políticas deberíany ser estar loslas clientes y usuarios referenciadas en los SLA, OLA y UCs Todos los elementos identificados están incluidos en el paquete de diseño del servicio y será entregado a la transición del servicio 1 debería ser usado para soportar una DML. 2 ayuda a la gestión de cambios. 3 es una herramienta de liberación e implementación. 4 puede ayudar con las pruebas y validación. Todas soportan la transición del servicio Ambos son roles validos para la gestión de problemas Cumplimiento de solicitudes es responsable de manejar las solicitudes de servicio de los usuarios. (B) “Todas” las solicitudes es un alcance muy amplio para el proceso. (C) Gestión de cambios verifica después del requerimiento de cambio. Gestión de niveles de servicio es responsable de D D es incorrecta; las preferencias de los clientes impulsan la percepción de valor. C es incorrecta; entregar los resultados que el cliente espera es vital. B es incorrecta; el valor de un servicio puede ser financiero pero otros factores también son relevantes. A es la correcta; la percepción del cliente es un elemento vital para entender lo que el cliente percibe como valor D es la correcta. Ambos clientes internos y externos deberían ser provistos con el mismo nivel de servicio. Un servicio es un medio para entregar valor a los clientes. TI necesita capacidades para entregar el servicio. Los costos y riesgos es lo que TI ayuda a gestionar C es correcta: monitorear el SLA y el desempeño es parte vital de gestión de niveles de servicio. A – diseñar un CMS es una actividad de gestión de activos de servicio y configuraciones. B – las métricas de tecnología son creadas por gestión de la capacidad u otros procesos de diseño. D – Capacitar al personal del Service Desk puede ser
© Acreditador oficial ITIL 2011 El logo™ es marca registrada de la oficina de gobierno ITIL® es marca registrada de la oficina de gobierno Examen de Fundamentos de ITIL Ejemplo A Respuestas y Racionales v5.1 Este documento no debe ser reproducido sin permiso expreso el Acreditador
27
A
05-81
SO 4.1.1
28
D
05-41
SD 4.2.1
29
D
03-01
SS 2.1.6
30
A
04-09
CSI 3.1
31
C
05-71
SO 4.2.4.2
32
A
05-71
SO 4.2.5
33
A
04-04
SD 3.1.1
34
D
05-43 05-46
SD 4.7.2 SD 4.6.5.2
35 36
C B
04-10 03-16
CSI 5.5 ST 4.7.4.3
37
C
05-51
ST 4.2.5.11
38
B
06-01
SO 6.3
39
D
04-03
SD 3.1.5
40
B
05-72
SO 4.4.5.6
responsabilidad del propio Service Desk A - La habilidad de detectar eventos, entenderlos y determinar la acción de control adecuada es provista por la gestión de eventos. B – incluye responsabilidades de gestión de incidentes. C – es una tarea de gestión técnica. D es probablemente compartida entre gestión de la disponibilidad y gestión de niveles de servicio El catálogo de servicio debería contener detalle de todos los servicios operacionales A es parte de la definición de utilidad. B es no realista. C puede ser factible como un enunciado de garantía de otrapor industria nobuen es definición usada ITIL. Dpero es un conceptodedegarantía garantía definida por ITIL El enfoque de mejora empieza con la visión de entender los objetivos de alto nivel del negocio El modelo de incidentes es diseñado para proveer pasos reusables que pueden ser utilizados para restaurar los servicios después de incidentes conocidos El orden correcto esta dado en el diagrama del proceso de incidentes en la sección 4.2.5 Las mediciones y métricas deberían ser incluidas en el diseño de un servicio nuevo o modificado La gestión de continuidad de los servicios de TI realiza evaluaciones de riesgos como parte de la definición de requerimientos y estrategia. Seguridad de la información también necesita analizar riesgos de seguridad antes de tomar acciones para mitigarlos. Catálogo de servicio no realiza estas evaluaciones Métricas descritas de personal es una de los 3 tipos de métricas en no mejora continua A es incorrecta. C es incorrecta ya que el SKMS contiene más información que el CMS. D es incorrecta ya que el CMS es parte del SKMS El comité asesor de cambios de emergencia (ECAB) provee ayuda en la autorización de cambios de emergencia El Service Desk debe ser el punto único de contacto para los usuarios de TI en el día a día. El gerente del Service Desk también puede ser el dueño del proceso de incidentes pero no debería de ser el dueño del proceso de problemas Personas, procesos, productos (servicio, tecnología y herramientas) y proveedores A - es incorrecta; el registro del problema debe permanecer abierto ya que no ha sido resuelto. B - Es correcto documentar las soluciones temporales en el registro del problema. C - No en cada registro de incidentes. D - Tampoco registrarla en una RFC
© Acreditador oficial ITIL 2011 El logo™ es marca registrada de la oficina de gobierno ITIL® es marca registrada de la oficina de gobierno Examen de Fundamentos de ITIL Ejemplo A Respuestas y Racionales v5.1 Este documento no debe ser reproducido sin permiso expreso el Acreditador
Examen d e F un dam entos de I TIL
®
Ejemplo B, versión 5.1 Selección Múltiple
Instrucciones
1. 2. 3. 4.
Debe intentar contestar todas las 40 preguntas. Marque sus respuestas en la hoja de respuestas entregada Usted tiene 60 minutos para contestar el examen Usted debe responder correctamente al menos 26 de las 40 preguntas (65%) para aprobar el examen.
Version 5.1 (Live)
© The Official ITIL Accreditor 2012 El Swirl Logo™ es una marca del Cabinet Office ITIL® es una marca registrada del Cabinet Office 07 ITIL Foundation Sample B_v5.1_Spanish (Latin American)_C97F6F.docx This document must not be reproduced without express permission from The Accreditor Owner – The Official ITIL Accreditor Page 1
1.
2.
¿Entradas de cuáles procesos podrían ser considerados por la gestión de niveles de servicios cuando negocia los acuerdos de niveles de servicio (SLA)? a) De todos los demás procesos de ITIL b)
Sólo de la gestión de disponibilidad y gestión de capacidad
c)
Sólo de la gestión de incidentes y gestión de problemas
d)
Sólo de la gestión de cambios y gestión de liberaciones e implementación
¿Cuál de las siguientes afirmaciones acerca de un cambio estándar es INCORRECTA?
3.
4.
a) b)
Está pre autorizados por la gestión de cambios Sigue un procedimiento o instrucción de trabajo
c)
Es de riesgo bajo
d)
Debe ser implementado los antes posible
¿Cuáles de las siguientes afirmaciones acerca del service desk son CORRECTAS? 1. Provee un punto único de contacto entre el proveedor de servicios y los usuarios 2. Gestiona los incidentes y las solicitudes de servicio 3. Es un proceso de gestión de servicios 4. El personal del services desk trata de restablecer el servicio lo más rápido posible a) b)
Todas las anteriores Sólo 1, 2 y 4
c)
Sólo 2 y 4
d)
Sólo 2 y 3
¿Cuáles de las siguientes afirmaciones acerca de las funciones son CORRECTAS? 1. Pueden incluir herramientas 2. Son grupos que utilizan recursos para llevar a cabo una ó más actividades 3. Una persona ó un grupo pueden desempeñar múltiples funciones 4. Son más costosas de implementar en comparación a los procesos a)
Sólo 1, 2 y 3
b) c)
Sólo 1, 2 y 4 Todas las anteriores
d)
Ninguna de las anteriores
Version 5.1 (Live)
© The ITIL Official Accreditor 2012 This document must not be reproduced without express permission from The Accreditor 07 ITIL Foundation Sample B_v5.1_Spanish (Latin American)_C97F6F.docx Owner – The Official ITIL Accreditor Page 2
5.
6.
7.
8.
¿Cuál de las siguientes afirmaciones es la que MEJOR describe las actividades realizadas por la gestión de instalaciones? a)
La gestión de servicios de TI considerados como "utilitarios” (utilities), por ejemplo impresoras ó acceso a la red
b)
Aconsejar y orientar a operaciones de TI acerca de herramientas y metodologías para la gestión de los servicios de TI
c)
Gestionar el ambiente físico de TI, como por ejemplo el centro de datos ó la sala de cómputos
d)
La adquisición y mantenimiento de las herramientas que el personal de operaciones de TI utiliza para mantener la infraestructura
¿Cuál proceso ayudaría identificación resolución cualquier incidente y los problemas asociados conenelladesempeño de ylos servicios de ó de los componentes? a)
Gestión de capacidad
b)
Gestión de proveedores
c)
Gestión de tecnología
d)
Gestión de cambios
¿Cuál de las siguientes afirmaciones acerca de la base de datos de errores conocidos (KEDB) es MEJOR? a)
La KEDB es la misma base de datos que la del sistema de gestión del conocimiento del servicio (SKMS)
b)
La KEDB debe usarse durante la fase de diagnóstico de incidentes para
c)
intentar acelerar el proceso de resolución Se debe tener cuidado para evitar la duplicación de registros en la KEDB. Esto se puede hacer dando acceso a tantos técnicos como sea posible para crear nuevos registros
d)
El acceso a la KEDB debe limitarse al service desk
¿Cuáles de las siguientes afirmaciones acerca de los indicadores clave de desempeño (KPI) y las métricas son CORRECTAS? 1. Las métricas del servicio miden el servicio de extremo a extremo 2. Cada KPI debe relacionarse a un factor crítico de éxito 3. Las métricas pueden utilizarse para identificar oportunidades de mejora 4. Los KPIs pueden ser cualitativos y cuantitativos a)
Sólo 1
b) c)
Sólo 2 y 3 Sólo 1, 2 y 4
d)
Todas las anteriores
Version 5.1 (Live)
© The ITIL Official Accreditor 2012 This document must not be reproduced without express permission from The Accreditor 07 ITIL Foundation Sample B_v5.1_Spanish (Latin American)_C97F6F.docx Owner – The Official ITIL Accreditor Page 3
9.
¿Cuál de los siguientes elementos mantiene las relaciones entre todos los componentes del servicio? a) El plan de capacidad b)
La biblioteca definitiva de medios
c)
El sistema de gestión de la configuración.
d)
Un acuerdo de nivel de servicios
10. ¿Se debe cumplir SIEMPRE con una solicitud de un cliente para un nuevo servicio? a) Sí - si es un cliente externo, ya que está pagando por el servicio b)
No - si es un cliente interno, ya que no siempre está pagando por el servicio
c)
No - es la responsabilidad del proveedor de servicios llevar a cabo las averiguaciones preliminares antes de que las solicitudes sean cumplidas Sí - el proveedor del servicio debe asegurar que se cumplan todas las solicitudes de nuevos servicios
d)
11. ¿Cuáles de las siguientes afirmaciones es/son CORRECTAS? 1. La gestión de problemas puede apoyar al service desk aportando errores conocidos para acelerar la resolución de incidencias 2. La gestión de problemas es la única fuente que provee a la gestión de niveles de servicio información respecto al impacto de los cambios a)
Sólo 1
b)
Sólo 2
c)
Ambas
d)
Ninguna de las anteriores
12. Ha ocurrido una falla en un sistema y es detectada por una herramienta de monitoreo. Este sistema da soporte a un servicio de TI en producción. ¿Cuándo debe levantarse un incidente? a)
Sólo cuando el usuario note la falla
b) c)
No se debe levantar un incidente si los técnicos han visto esto antes y tienen una solución temporal Sólo si la falla genera el incumplimiento de un nivel de servicio
d)
Inmediatamente, para limitar ó prevenir el impacto en los usuarios
Version 5.1 (Live)
© The ITIL Official Accreditor 2012 This document must not be reproduced without express permission from The Accreditor 07 ITIL Foundation Sample B_v5.1_Spanish (Latin American)_C97F6F.docx Owner – The Official ITIL Accreditor Page 4
13. ¿Cuáles de los siguientes sujetos podrían ser considerados como los interesados en un proyecto de gestión de servicios? 1. Usuarios 2. Clientes 3. Proveedores 4. Funciones a)
Sólo 1 y 2
b)
Sólo 3 y 4
c)
Sólo 2 y 4
d)
Todos los anteriores
14. ¿La gestión de activos de servicio y configuración asegura que se realizan cuáles de las siguientes actividades? 1. La identificación de los elementos de configuración (CIs) 2. El establecimiento de las líneas base de los CIs 3. El control de los cambios a los CIs a)
Todas las anteriores
b)
Solo 1 y 2
c)
Sólo 1 y 3
d)
Sólo 2 y 3
15. ¿Cuáles de los siguientes aspectos del diseño de servicios deben ser considerados cuando se diseña una solución de servicio? 1. Métodos de medición y métricas 2. Sistemas de información de gestión y herramientas 3. Arquitecturas tecnológicas 4. Los procesos requeridos a)
Sólo 1 y 2
b)
Sólo 2 y 3
c)
Sólo 2, 3 y 4
d)
Todos los anteriores
Version 5.1 (Live)
© The ITIL Official Accreditor 2012 This document must not be reproduced without express permission from The Accreditor 07 ITIL Foundation Sample B_v5.1_Spanish (Latin American)_C97F6F.docx Owner – The Official ITIL Accreditor Page 5
16. ¿Cuál de las siguientes afirmaciones es CORRECTA para TODOS los procesos? a)
Definen las funciones como parte de su diseño
b)
Entregan los resultados a un cliente ó a un interesado (stakeholder)
c)
Son ejecutados por proveedores externos de servicios para dar soporte a un cliente
d)
Son unidades organizacionales responsables de resultados específicos
17. ¿Qué proceso es el principal responsable del empaquetamiento, construcción, pruebas e implementación de servicios? a)
Planificación de la transición y soporte
b)
Gestión de liberaciones e implementación
c)
Gestión de activos de servicio y configuración
d)
Gestión del catálogo de servicios
18. ¿Cuál es el MEJOR ejemplo de una solución temporal (workaround)? a)
Un técnico instala un script para desviar temporalmente las impresiones a una impresora alternativa hasta que se aplique una solución permanente
b)
Un técnico intenta resolver un incidente de varias vías. Una funciona pero no se sabe cuál.
c)
Después de notificar al service desk, el usuario se dedica a otras tareas
d)
mientras se identifica y resuelve el problema Un dispositivo funciona intermitentemente, permitiéndole al usuario trabajar con menor rendimiento mientras el técnico diagnostica el incidente.
19. ¿Cuáles de las siguientes áreas pueden ser ayudadas por la tecnología? 1. Gestión de solicitudes 2. Gestión del catálogo de servicios 3. Detección y monitoreo 4. Diseño y modelado a)
Sólo 1, 2 y 3
b)
Sólo 1, 3 y 4
c)
Sólo 2, 3 y 4
d)
Todas las anteriores
Version 5.1 (Live)
© The ITIL Official Accreditor 2012 This document must not be reproduced without express permission from The Accreditor 07 ITIL Foundation Sample B_v5.1_Spanish (Latin American)_C97F6F.docx Owner – The Official ITIL Accreditor Page 6
20. ¿Cuál de las siguientes alternativas es la lista CORRECTA de las fases del ciclo de Deming? a)
Planificar, Medir, Monitorear, Informar
b)
Planificar, Verificar, Reaccionar, Implementar
c)
Planificar, Hacer, Actuar, Auditar
d)
Planificar, Hacer, Verificar, Actuar
21. ¿Cuáles dos procesos estarán MAS involucrados en la negociación y en acordar los contratos que proporcionaran las capacidades de recuperación para apoyar los planes de continuidad? a) Gestión de niveles de servicio y gestión de capacidad b)
Gestión de proveedores y gestión de niveles de servicios
c)
Gestión de continuidad de servicios de TI y gestión de niveles de servicios
d)
Gestión de continuidad de servicios de TI y gestión de proveedores
22. ¿Cuál de las siguientes opciones es la MEJOR definición de un modelo de incidentes? a)
La plantilla que define el documento de registro de incidentes que se usa para emitir informes sobre los incidentes
b)
Un tipo de incidente que involucra un tipo estándar (ó modelo) de elemento de configuración (CI)
c)
Un conjunto de pasos predefinidos que ha de seguirse cuando se trata con un tipo conocido de incidente
d)
Un incidente que es fácil resolver
23. ¿Qué roles están definidos en el modelo RACI? a)
Responsable, responsable final, consultado, Informado
b)
Responsable, factible, consultado, informado
c)
Realista, responsable final, consultado, informado
d)
Responsable, responsable final, corregido, informado
Version 5.1 (Live)
© The ITIL Official Accreditor 2012 This document must not be reproduced without express permission from The Accreditor 07 ITIL Foundation Sample B_v5.1_Spanish (Latin American)_C97F6F.docx Owner – The Official ITIL Accreditor Page 7
24. ¿Qué etapa del ciclo de vida del servicio decide qué servicios deben ofrecerse y a quién se les ofrecerán? a)
Mejora continua del servicio
b)
Operación del servicio
c)
Diseño del servicio
d)
Estrategia del servicio
25. ¿Sobre cuáles materias la mejora continua del servicio (CSI) brinda asesoría? 1. Como mejorar la eficiencia y efectividad del proceso 2. Como mejorar los servicios 3. Mejoras en todas las fases del ciclo de vida del servicio a)
Sólo 1 y 2
b)
Sólo 1 y 3
c)
Sólo 2 y 3
d)
Todos los anteriores
26. ¿Cuál de las siguientes alternativas corresponde a un tipo de acuerdo de nivel de servicio (SLA) descrito en la publicación de ITIL sobre diseño del servicio? a)
SLA basado en la prioridad
b)
SLA basado en la tecnología
c)
SLA basado en la ubicación
d)
SLA basado en el cliente
27. ¿Cuál de las siguientes alternativas es la MEJOR definición de un evento? a)
Una situación que traspasa un umbral de desempeño e impacta a un nivel de servicio acordado
b)
Un cambio de estado que tiene importancia para la gestión de un servicio de TI
c)
Un defecto conocido del sistema que genera múltiples informes de incidentes
d)
Una reunión planificada entre los clientes y el personal de TI para anunciar un nuevo servicio ó un programa de mejoras
Version 5.1 (Live)
© The ITIL Official Accreditor 2012 This document must not be reproduced without express permission from The Accreditor 07 ITIL Foundation Sample B_v5.1_Spanish (Latin American)_C97F6F.docx Owner – The Official ITIL Accreditor Page 8
28. ¿Cuál de los siguientes sujetos es el MÁS apropiado para definir el valor de un servicio? a)
Clientes
b)
Dirección de TI
c)
Gestión financiera de servicios de TI
d)
Proveedores
29. ¿Cuál de las siguientes situaciones debe ser atendida como un incidente? 1. Un usuario no puede acceder a un servicio durante las horas de servicio 2. Un miembro autorizado del personal de TI no puede acceder a un servicio durante las horas de servicio 3. Un componente de la red falla, pero el usuario no tiene conocimiento de ninguna interrupción del servicio 4. Un usuario contacta al service desk debido al lento desempeño de una aplicación a)
Todos los anteriores
b)
Sólo 1 y 4
c)
Sólo 2 y 3
d)
Ninguno de los anteriores
30. ¿Cuál de las siguientes afirmaciones acerca de un modelo de cambios es CORRECTA? a)
Un modelo de cambios NO debe usarse para cambios de emergencia
b)
Un modelo de cambios debe construirse cuando se requiere un cambio significativo
c)
Un modelo de cambios define los pasos que deben seguirse para manejar un tipo de cambio particular
d)
Los procedimientos de escalamiento están fuera del alcance de un modelo de cambios
31. El enfoque de CSI utiliza una serie de técnicas. ¿Cuál de las siguientes técnicas sería la que MEJOR ayuda a las empresas a entender "dónde estamos ahora ”? a) Revisión de factores críticos de éxito b)
Entender la visión del negocio
c)
Realizar una evaluación inicial
d)
Verificación del registro de CSI
Version 5.1 (Live)
© The ITIL Official Accreditor 2012 This document must not be reproduced without express permission from The Accreditor 07 ITIL Foundation Sample B_v5.1_Spanish (Latin American)_C97F6F.docx Owner – The Official ITIL Accreditor Page 9
32. ¿Cuáles procesos de operación de servicio no están en la siguiente lista? 1. Gestión de incidentes 2. Gestión de problemas 3. Gestión de acceso 4. ? 5. ? a) Gestión de eventos y cumplimiento de solicitudes b)
Gestión de eventos y service desk
c)
Gestión de instalaciones y gestión de eventos
d)
Gestión de cambios y gestión de niveles de servicio
33. ¿Cuál etapa del ciclo de vida del servicio proporciona un marco para evaluar las capacidades de servicio y los perfiles de riesgo antes de que los servicios nuevos ó modificados se implementen? a) Estrategia del servicio b)
Mejora continua del servicios
c)
Transición del servicio
d)
Operación del servicio
34. ¿Cuál de las siguientes actividades debe llevar a cabo el dueño de un servicio? 1. Representar un servicio específico en toda la organización 2. Actualizar el sistema de gestión de la configuración (CMS) después de un cambio 3. Ayudar a identificar mejoras en el servicio 4. Representar un servicio específico en las reuniones del comité asesor de cambios (CAB) a)
Sólo 2, 3 y 4
b)
Todas las anteriores
c)
Sólo 1, 2 y 3
d)
Sólo 1, 3 y 4
Version 5.1 (Live)
© The ITIL Official Accreditor 2012 This document must not be reproduced without express permission from The Accreditor 07 ITIL Foundation Sample B_v5.1_Spanish (Latin American)_C97F6F.docx Owner – The Official ITIL Accreditor Page 10
35. ¿Cuál de los siguientes enunciados NO es un propósito u objetivo de la gestión de la disponibilidad? a)
Monitorear e informar sobre la disponibilidad de componentes
b)
Asegurar que la disponibilidad del servicio coincida con las necesidades acordadas del negocio
c)
Evaluar el impacto de los cambios en el plan de disponibilidad
d)
Asegurar que los planes de continuidad del negocio estén alineados con los objetivos del negocio
36. ¿Cuál de las siguientes afirmaciones es la descripción CORRECTA de las “cuatro Ps” del diseño del servicio? a) Un proceso de cuatro pasos para el diseño de una gestión efectiva del servicio b)
Una definición del personal y productos requeridos para un diseño exitoso
c)
Un conjunto de preguntas que deben hacerse cuando se revisan las especificaciones de diseño
d)
Las cuatro áreas principales que deben ser consideradas durante el diseño del servicio
37. ¿Cuál de las siguientes opciones describe MEJOR una revisión a un problema mayor? a)
Facilitada por el gerente de problemas, una revisión a un problema mayor está diseñada para repartir la culpa después que se ha resuelto el problema.
b)
El gerente de cambios lleva a cabo una revisión a un problema mayor como parte comité que asesor de cambios (CAB) por el gerente de cambios. Se realizadel después ha sido aceptada la solicitud de cambio (RFC) para resolver el problema
c)
Una revisión a un problema mayor es facilitada por el gerente del service desk de forma que se puedan aprender lecciones después que se ha resuelto un problema mayor
d)
Facilitada por el gestor de problemas, la revisión se lleva a cabo de forma que se puedan aprender lecciones del problema mayor, y para proporcionar formación y sensibilización al personal de soporte
38. ¿Cuál de los siguientes enunciados acerca de la gestión de proveedores es INCORRECTO? a)
La gestión de proveedores negocia acuerdos de nivel operacional (OLA)
b)
La gestión de proveedores asegura que los proveedores cumplan con las
c)
expectativas del negocio La gestión de proveedores mantiene información en un sistema de información de la gestión de proveedores y contratistas
d)
La gestión de proveedores negocia acuerdos externos para dar soporte en la entrega de servicios
Version 5.1 (Live)
© The ITIL Official Accreditor 2012 This document must not be reproduced without express permission from The Accreditor 07 ITIL Foundation Sample B_v5.1_Spanish (Latin American)_C97F6F.docx Owner – The Official ITIL Accreditor Page 11
39. ¿Cuál de los siguientes enunciados es un objetivo principal de la gestión de relaciones con el negocio? a)
Llevar a cabo actividades operativas para dar soporte a los servicios
b)
Asegurar que se cumplen todos los objetivos dentro de los acuerdos de nivel de servicio
c)
Maximizar el valor del contrato y la eficiencia operativa de los servicios que se entregan
d)
Entender las necesidades del cliente y asegurar que se cumplan
40. ¿Cuál de las siguientes afirmaciones es un objetivo del proceso de coordinación del diseño? a) Asegurar que se cumplan los objetivos de disponibilidad del servicio b)
Definir, documentar, acordar, monitorear, medir y revisar los niveles de servicio
c)
Proveer y mantener una única fuente de información consistente sobre todos los servicios en operación
d)
Monitorear y mejorar el desempeño de la etapa del ciclo de vida del diseño del servicio
Version 5.1 (Live)
© The ITIL Official Accreditor 2012 This document must not be reproduced without express permission from The Accreditor 07 ITIL Foundation Sample B_v5.1_Spanish (Latin American)_C97F6F.docx Owner – The Official ITIL Accreditor Page 12
Exa m en de Fund amentos de IT IL
®
Ejemplo B, versión 5.0 Opción múltiple
RESPUE STAS Y RA CIONALES
© Acreditador oficial ITIL 2011 El logo™ es marca registrada de la oficina de gobierno ITIL® es marca registrada de la oficina de gobierno Examen de Fundamentos de ITIL Ejemplo B Respuestas y Racionales v5.0 Este documento no debe ser reproducido sin permiso expreso el Acreditador
P
R
Referencia Libro
Racional
A
Referencia Plan de estudios 05-31
1
SD 4.3.5.2
2
D
05-51
ST 4.2.4.3
3
B
06-01
SO 6.3.2
Representantes de todos los otros procesos necesitan ser consultados sobre su opinión de qué objetivos realistas pueden ser alcanzados Un cambio estándar no necesariamente debe ser implementado tan pronto como sea posible y los cambios de emergencia si El Service Desk es una función, no un proceso
4
A
01-09
SS 2.2.3.1
5
C
06-02
SO 6.5.1
6
A
05-45
SD 4.5.2
7
B
03-32
SO 4.4.7.2
8
D
04-10
9
C
03-18
CSI 4.1.12 5.5 ST 4.3.4.3
10
C
01-04
SS 3.2.1.2
Las funciones no yestán como más costosas que los procesos esto descritas dependerá del proceso o función que sea considerado Gestión de instalaciones se refiere a la gestión del ambiente físico de TI, típicamente un centro de datos o centro de cómputo Las situaciones de desempeño son responsabilidad de la gestión de la capacidad A – la KEDB es parte del SKMS, no es la misma cosa. B es correcta. C – la duplicación debe ser evitada pero restringiendo el acceso. D – Si, el Service Desk usarlo pero no son los únicos Cada enunciado es un resumen del contenido del manual El sistema de gestión de configuraciones (CMS) es responsable vía sus varias fuentes de datos (CMDB, etc.) de mantener esas relaciones El proveedor del servicio debe asegurar que se
11
A
05-72
SO 4.4.6.4
12
D
05-71
SO 4.2.5
13
D
01-08
SS 2.1.5
14
A
05-36
ST 4.3.2 A
realice la debida diligencia contra los requerimientos del cliente, sin importar si son clientes internos o externos Gestión de problemas es la fuente de errores conocidos pero cambios y activos de servicio y configuraciones pueden ser otras fuentes de información sobre el impacto de los cambios A – no necesitan ser impactados los usuarios para poder generar un incidente. B – Aún cuando una solución temporal esté disponible, necesita ser registrada para medir cualquier impacto del incidente. C – todos los incidentes deben ser registrados. D – Correcta, para prevenir la pérdida del servicio o restaurar el servicio tan pronto como sea posible D es la correcta. Los grupos de interés pueden ser internos o externos. Un ejemplo de una función como grupo de interés puede ser el Service Desk, la gestión técnica o la gestión de aplicaciones Todas las actividades son parte del alcance de la
15 16
D B
04-04 01-10
SD 3.1.1 SS 2.2.2
gestión activos deaspectos servicio ydel configuraciones Todo losdepuntos son diseño del servicio A – el diseño de procesos debería involucrar la
© Acreditador oficial ITIL 2011 El logo™ es marca registrada de la oficina de gobierno ITIL® es marca registrada de la oficina de gobierno Examen de Fundamentos de ITIL Ejemplo B Respuestas y Racionales v5.0 Este documento no debe ser reproducido sin permiso expreso el Acreditador
17
B
05-61
ST 4.4.2
18
A
03-30
SO 4.4.5.6
19
D
08-02
SS 7.1
20
D
03-42
CSI 3.8
21
D
05-46
SD 4.6.1
22
C
05-71
23
A
07-02
24
D
02-03
SO 4.2.4.2 SD 3.7.4.1 SS 1.1.1
25
D
02-11
CSI 1.1.1
26
D
05-31
SD 4.3.5.1
27
B
03-24
SO 4.1
28
A
04-02
SS 3.2.3
29
A
03-26
SO 4.2
30
C
05-51
ST 4.2.4.5
asignación de actividades a las funciones pero no la definición del proceso. B – Correcta. Los procesos entregan resultados o no tendrían valor. C – No todos los procesos son realizados por proveedores externos. D – Es una descripción de una función Todas son actividades realizadas por gestión de liberaciones e implementación A es un buen ejemplo de una solución temporal que no es permanente pero que soluciona el incidente srcinal. B es una resolución “con suerte” del incidente e improbable que se repita. C no permite al usuario continuar con su tarea srcinal. D es un incidente bajo investigación Las cuatro áreas pueden ser apoyadas por la tecnología Las cuatro etapas clave del ciclo son planear, hacer, verificar y actuar Continuidad de los servicios de TI provee experiencia y la gestión de proveedores provee el proceso de negociación y selección del contrato. Niveles de Servicio también tiene un rol en los contratos de apuntalamiento pero no es tan significativo como los primeros dos procesos C se ajusta a la descripción de modelo de incidentes Los roles son Responsable, Responsable final, Consultado, Informado Decidir que servicios deberían ser ofertados y a quien es parte integral de la estrategia del servicio 1 CSI busca formas de mejorar la efectividad y eficiencia de los procesos así como su efectividad en costos 2 CSI identifica e implementa mejoras a los servicios de TI 3 CSI mejora cada etapa del ciclo de vida: estrategia, diseño, transición, operación y la mejora continua Los SLAs basado en prioridad, basado en tecnología, basado en ubicación no son discutidos en el diseño del servicio A y C pueden causar que se genere un evento. D es una reunión. B se apega a la definición de un evento en la operación del servicio El valor es el nivel de cumplimiento de las expectativas del cliente y así los clientes pueden tomar la última decisión sobre si el servicio otorga el valor Un incidente es “la interrupción no planeado de un servicio de TI o la reducción en la calidad de un servicio de TI, o una falla en un CI que aun impacta el servicio” El no poder acceder a un servicio de TI, es acordada como una interrupción no planeada desde la perspectiva del usuario A – Un modelo de cambio puede ser usado por cambio de emergencia. B – Los modelos de cambios
© Acreditador oficial ITIL 2011 El logo™ es marca registrada de la oficina de gobierno ITIL® es marca registrada de la oficina de gobierno Examen de Fundamentos de ITIL Ejemplo B Respuestas y Racionales v5.0 Este documento no debe ser reproducido sin permiso expreso el Acreditador
31
C
04-09
32
A
05-81 05-82
CSI 3.1.1 SO 4.1.1 4.3.1
33
C
02-07
ST 1.1.1
34
D
07-01
SD 6.3.1
35
D
05-42
36
D
04-03
SD 4.4.1 4.4.2 SD 3.1.5
37
D
05-72
SO 4.4.5.10
38
A
05-44
SD 4.8.1
39
D
05-23
SS 4.5.1
40
D
05-47
SD 4.1.1
no deberían ser creados rutinariamente cuando se hacen cambios significativos. C es correcta. D – los procedimientos de escalamiento pueden ser incluidos en el modelo de cambios “¿dónde estamos ahora?” requiere que el negocio cuente con una línea base La respuesta correcta es A, B - Son un proceso y una función respectivamente, C – Son una función y un proceso respectivamente. D - Son procesos de la transición y diseño del servicio respectivamente. Transición del servicio es responsable de estos como parte de la liberación de nuevos servicios 1, 3 y 4 son responsabilidades del rol de del dueño del servicio. La opción 2 es responsabilidad bibliotecario/gestor de configuraciones D es responsabilidad de la continuidad de los servicios de TI A – las “4 Ps” nos son un proceso. B – Tiene mérito pero solo se enfoca en 2 de 4 áreas. C – Las 4 Ps no son un check list o un conjunto de preguntas D es la respuesta del libro. A es el rol correcto pero no se trata de encontrar culpables. B es la correcta. C es plausible pero es facilitada por el rol equivocado Todos son objetivos de proceso de gestión de proveedores, excepto A el cual es realizado por gestión de niveles de servicio Identificar necesidades de los clientes y asegurar que el proveedor del servicio es capaz de cumplir esas necesidades es el objetivo de la gestión de relaciones con el negocio. D es la correcta. C es el propósito de gestión de catálogodedeservicio. servicios. B es objetivo gestión niveles A es un un objetivo de de gestión de de la disponibilidad
© Acreditador oficial ITIL 2011 El logo™ es marca registrada de la oficina de gobierno ITIL® es marca registrada de la oficina de gobierno Examen de Fundamentos de ITIL Ejemplo B Respuestas y Racionales v5.0 Este documento no debe ser reproducido sin permiso expreso el Acreditador
