Manual 2017-I 04 Gestioìn de Servicios de TI - Cibertec

Gestión de Servicios de TI

2

GESTIÓN DE SERVICIOS DE TI

3

ÍNDICE Presentación

5

Red de contenidos

6

Unidad de aprendizaje 1: Fundamentos de la Gestión de Servicios de TI TEMA 1 TEMA 2

: Introducción a la Gestión de Servicios de TI : Gestión de Procesos

7 21

TEMA 3

: Introducción a ITIL

27

Unidad de aprendizaje 2: Gestión de la Configuración, Incidentes, Problemas y Cambios. TEMA 4 : Centro de Servicios

39

TEMA 5

: Gestión de la Configuración

47

TEMA 6

: Gestión de Incidentes

57

TEMA 7

: Gestión de Problemas

67

TEMA 8

: Gestión de Cambios

77

TEMA 9

: Gestión de Versiones

87

Unidad de aprendizaje 3: La Transición y Operación de Servicios de TEMA 10 : Gestión de la Capacidad

95

TEMA 11

: Gestión de la Disponibilidad

105

TEMA 12

: Gestión de la Continuidad

113

Unidad de aprendizaje 4: Racionalización y Mejora Continua de los Servicios de TI. TEMA 13

: Gestión de Nivel de Servicio

122

TEMA 14

: Gestión de la Demanda

131

TEMA 15

: Gestión del Conocimiento

137

TEMA 16

: Gestión de Mejora Continua de Servicios de TI

144

CIBERTEC CARRERAS PROFESIONALES

4


5

PRESENTACIÓN

G estión de S ervicios de TI es un curso que pertenece a la línea de Gestión de Sistemas y se dicta en la carrera de Administración de Sistemas. Brinda los fundamentos de gestión que hacen eficiente la entrega y soporte de

servicios de TI, basándose en el enfoque de procesos de ITIL (Information Technology Infraestructure Library). El manual para el curso ha sido diseñado bajo la modalidad de unidades de aprendizaje, las que se desarrollan durante semanas determinadas. En cada una de ellas, hallará los logros, que deben alcanzarse al final de la unidad; el tema tratado, el cual será ampliamente desarrollado; y los contenidos, que deben desarrollarse, es decir, los subtemas. Por último, encontrará las actividades que deberán desarrollarse en cada sesión, que le permitirán reforzar lo aprendido en la clase. El curso presenta en primer lugar los conceptos básicos referidos a la gestión de TI, tales como servicios, calidad, organización, políticas y procesos, así como la estructura y los objetivos de ITIL. Luego se describen el centro de servicios y los procesos que conforman el soporte del servicio. Finalmente se desarrollan los procesos referidos a la entrega o provisión del servicio.

CIBERTEC CARRERAS PROFESIONALES 6

RED DE CONTENIDOS

CARRERAS PROFESIONALES CIBERTEC


7

UNIDAD DE APRENDIZAJE

1 TEMA

1

INTRODUCCIÓN A LA GESTIÓN DE SERVICIOS DE TI LOGRO DE LA UNIDAD DE APRENDIZAJE Al término de la unidad, el alumno describirá los conceptos básicos de la gestión de servicios de TI, y la estructura y los objetivos de ITIL, identificando con precisión sus características, componentes y ventajas.

TEMARIO Servicios y Calidad Organización y Políticas

ACTIVIDADES PROPUESTAS Los alumnos seleccionarán una empresa y la describirán en base a los conceptos tratados en el capítulo.

CIBERTEC

CARRERAS PROFESIONALES

8

1. SERVICIOS Y CALIDAD Las organizaciones a menudo son muy dependientes de sus servicios TI y no sólo esperan que dichos servicios TI proporcionen soporte a la organización, sino que también aporten nuevas opciones para conseguir los objetivos de la organización. Asimismo, las elevadas expectativas de los clientes de servicios TI tienden a cambiar significativamente con el tiempo. Los proveedores de servicios TI ya no pueden permitirse el lujo de centrarse en la tecnología y en su organización interna, sino que ahora deben considerar la calidad de los servicios que ofrecen y concentrarse en la relación con sus clientes. La provisión de servicios TI implica la gestión total -mantenimiento y operación- de la infraestructura TI. Antes de comprar un producto, generalmente evaluamos su calidad, tanto como su apariencia, su utilidad y sus prestaciones. En general, el cliente tiene pocas oportunidades para influir sobre la calidad del producto. Esto se debe a que ese producto ha sido desarrollado en una fábrica mediante un proceso sobre el que el cliente no tiene control. Gestionando efectivamente la planta de producción, el fabricante tratará por su parte de entregar un producto de calidad constante. En este ejemplo, la fabricación, las ventas y el consumo del producto son procesos independientes. Sin embargo, los servicios se proporcionan en relación con el cliente. Los servicios no pueden evaluarse por adelantado, sino sólo una vez prestados. La calidad de un servicio depende en cierta forma de la manera en la que proveedor de servicio y su cliente interactúan. A diferencia del proceso de fabricación, el cliente y el proveedor pueden realizar cambios cuando se está desarrollando y utilizando el servicio. La forma en que el cliente percibe el servicio y lo que el proveedor piensa que ofrece, dependen ampliamente de sus experiencias personales y de sus expectativas. El proceso de proveer un servicio es la combinación de producción y uso, en la que participan simultáneamente el proveedor y el cliente. La percepción del cliente es esencial para la provisión de los servicios. Los clientes generalmente se harán las siguientes preguntas para evaluar la calidad del servicio: ¿El servicio cumple con mis expectativas? ¿Puedo esperar un servicio similar la próxima vez? ¿Es razonable el coste del servicio? Si el servicio cumple o no con las expectativas depende, ante todo, de cuan eficazmente se acordaron los entregables con el cliente, más que de la propia forma en la que se provee el servicio. Un diálogo continuo con el cliente es esencial para refinar los servicios y asegurarse de que tanto el cliente como el abastecedor sepan lo que se espera del servicio. En un restaurante, el camarero primero explicará el menú, y luego, al servir el plato, preguntará si es de su gusto. El camarero coordina activamente la oferta y la demanda durante la comida. Y es esta experiencia con el cliente lo que se utiliza para mejorar el contacto futuro con él. La calidad de un servicio es la capacidad que tiene éste para satisfacer las necesidades y las expectativas del cliente. Para poder proporcionar calidad, el abastecedor deberá evaluar continuamente la forma en la que se experimenta el servicio y lo que el cliente espera en el futuro. Lo que un cliente considera normal puede resultar algo especial para otro, y sin embargo con el tiempo el cliente se


CIBERTEC


9

acostumbrará a lo que consideraba especial al principio. Los resultados de la evaluación del servicio pueden utilizarse para determinar si éste debe ser modificado, si el cliente debe recibir más información, o si es necesario cambiar el precio del servicio. La calidad es el conjunto de características de un producto o servicio que influyen en la satisfacción de las necesidades explícitas e implícitas (ISO-8402). Los costes razonables pueden considerarse un requisito derivado. Una vez que se acordó lo que se espera del servicio, se debe convenir su coste. En este momento el proveedor del servicio debe ser consciente de los costes en los que incurrirá, y los valores actuales de mercado para servicios similares. El proveedor de servicio que a veces exceda las expectativas y otras no las cumpla hará de quelos el aspectos cliente nomás se sienta satisfecho. Proporcionar unadecalidad constante es uno importantes, si no el que más, la industria de los servicios. Por ejemplo, un restaurante tendrá que comprar siempre ingredientes frescos, los chefs deberán trabajar juntos para proporcionar resultados constantes, y con suerte no existirán mayores diferencias de estilo entre el personal de servicio. Un restaurante sólo recibirá la categoría tres estrellas cuando consiga la misma calidad a lo largo del tiempo. Éste no siempre es el caso: hay cambios entre el personal de servicio, una oferta exitosa puede terminarse pronto, y los chefs pueden irse para abrir sus propios restaurantes. Ofrecer alta calidad constantemente también significa que el componente de las actividades debe estar coordinado: cuanto mejor y más eficaz sea la cocina, más rápido se puede servir a los clientes. Así, cuando se presta un servicio, la calidad total es resultado del conjunto de procesos que forman integrados el servicio. Estos procesos forman una cadena, y los eslabones se afectan unos a otros y a la calidad del servicio. La coordinación eficaz de losproceso, procesossino no también sólo requiere proporcionar una calidad adecuada al llevar a cabo cada una calidad consistente.

1.1 Aseguramiento de la calidad Suministrar productos o servicios requiere actividades. La calidad de un producto o servicio depende mucho de la manera en la que se organizan estas actividades. El círculo de calidad de Deming (Figura 1.1) muestra un modelo simple y eficaz para controlar la calidad. El modelo asume que para dar una calidad apropiada, se deben seguir los siguientes pasos: Planificar (Plan) - ¿Qué se debe hacer, cuándo, quién debe hacerlo, cómo, y utilizando qué? Hacer (Do) – se llevan a cabo las actividades programadas. Verificar (Act) – determinar si las actividades dan los resultados esperados. Actuar (Check) – ajustar los planes basándose en la información recogida al comprobar. Una intervención eficaz y a tiempo significa que las actividades están divididas en procesos con sus propios planes y oportunidades para analizar. Debe estar claro quién es responsable en la organización y qué autoridad tiene para cambiar planes y procedimientos, incluyendo actividades y procesos.

CIBERTEC


10

Figura 1.1 Círculo de Calidad de Deming La Gestión de Calidad es responsabilidad de todos los que trabajan en la organización proveedora de servicios. Cada empleado debe saber cómo su contribución a la organización afecta a la calidad de trabajo provista por sus colegas, y eventualmente al servicio que proporciona la organización. La gestión de calidad también significa estar a la búsqueda de nuevas oportunidades todo el tiempo e implementar mejoras en las actividades relacionadas con la calidad. Aseguramiento de la calidad es un aspecto político dentro de la organización. Se refiere al conjunto de medidas y procedimientos que utiliza la organización para asegurar que los servicios proporcionados continúan cumpliendo las expectativas del cliente y los acuerdos establecidos. El compromiso de calidad garantiza que las mejoras srcinadas en la gestión de calidad se mantengan. Un sistema de calidad es la estructura orgánica relacionada con responsabilidades, procedimientos y recursos para implementar la gestión de calidad. La serie de estándares ISO 9000 es la que se usa generalmente para desarrollar, evaluar y mejorar los sistemas de calidad.

1.2 Madurez de organización La experiencia en la mejora de calidad de los servicios TI ha demostrado que no es suficiente estructurar y definir las prácticas actuales. El srcen de las diferencias entre el servicio provisto y los requisitos del cliente se relaciona generalmente con la forma en la que se gestiona la organización TI. Una mejora permanente de calidad demanda una cierta madurez de la organización. El modelo de la Fundación Europea para la Gestión de Calidad (European Foundation for Quality Management - EFQM) (Figura 1.2) puede resultar útil para determinar la madurez de una organización. Este modelo identifica las áreas más importantes a considerar cuando se gestiona una organización. El círculo depolíticas) Calidad de Demingbasándose está incorporado en el modelo Las medidas (estrategia, se toman en los resultados de EFQM. las diferentes áreas. Estas medidas sirven para apoyar a la planificación (por ej. la estructura de los procesos) que debería conducir a los resultados deseados. El modelo EFQM identifica nueve áreas.


CIBERTEC


11

Figura 1.2 Modelo EFQM Como herramienta adicional, la organización holandesa de calidad, INK, dividió el modelo en etapas que indican hasta qué punto una empresa ha implementado la Gestión de Calidad Total, tanto en un área en particular, como en general. Existen cinco etapas: Orientada al producto - también conocida como ad hoc, orientada a la producción; todo el mundo en la organización trabaja mucho (pero sus esfuerzos no están dirigidos). Orientada al proceso - también conocida como “sabemos de qué se trata nuestro negocio”, el desempeño de la organización está planific ado y es repetible. Orientada al sistema - o “cooperación entre departamentos”. Orientada a la cadena - también “sociedad externa”; la organización pone énfasis en el valor que agrega a la cadena abastecedor-cliente de la que forma parte.

Orientada a la calidad total - o “el cielo en la tierra”; la organización ha llegado al nivel en que el ejercicio de una mejora continua y equilibrada ha adquirido el carácter de instintivo. En el sector de las TI, el proceso de mejora de la madurez más conocido, es el Modelo de Madurez de Capacidad (Capability Maturity Model - CMM). Este método de mejora de proceso fue desarrollado por el Instituto de Ingeniería de Software de la Universidad de Carnegie Mellon. CMM tiene como objetivo mejorar la madurez del proceso de creación de software. CMM incluye los siguientes niveles: Inicial - el proceso ocurre ad hoc. Repetible - los procesos han sido diseñados de manera tal que el servicio de calidad pueda repetirse. Definido - los procesos han sido documentados, estandarizados e integrados. Gestionado - la organización mide los resultados y utiliza esas medidas conscientemente para mejorar la calidad de sus servicios. Óptimo - la organización optimiza conscientemente el diseño de sus procesos para mejorar la calidad de sus servicios o para desarrollar nuevas tecnologías o servicios. Los modelos de madurez basados en los niveles de CMM también han sido creados para la Gestión de Servicios TI.

CIBERTEC


12

Desarrollar y mantener un sistema de calidad que cumpla con los requisitos de la norma ISO 9000 (ISO-9000-2000) puede ser considerado por la organización como la herramienta para alcanzar y mantener el nivel de madurez orientado al sistema (o “gestionado” en el CMM de Servicio TI). Esos estándares ISO hacen hincapié en la definición, descripción y diseño de los procesos. Cuando se evalúa la madurez de una organización no podemos restringirnos al proveedor del servicio. El nivel de madurez del cliente (Figura 1.3) también es importante. Si existen grandes diferencias entre el abastecedor y el cliente, entonces éstas deberán ser consideradas para evitar un error en el planteamiento, los métodos y las expectativas mutuas. En concreto, esto afecta a la comunicación entre el cliente y el abastecedor. Es aconsejable que ambas organizaciones tengan el mismo nivel de desarrollo nivel más bajo.para operar a ese nivel, o para ajustar la comunicación en línea con el

Figura 1.3 Niveles de C omunicación y Madurez: Cliente y Proveedor

2. ORGANIZACIÓN Y POLÍTICAS 2.1 Visión, objetivos y políticas Una organización es una forma de cooperación entre personas. Cualquier organización, desde un club hasta una empresa multinacional, depende del concepto de por qué vale la pena cooperar con la organización. Estavisión puede ser poder ganar dinero vendiendo PCs. Sin embargo, para resultar atractivo para los stakeholders (p. ej. clientes, inversionistas, personal) su organización tendrá que comunicar por qué deberían hacer negocios con usted, por ejemplo porque usted es el mejor, el más barato o el más gracioso. De esta manera, usted querrá elaborar una imagen acorde. Para comunicar su visión, se puede definir a la organización a través de la Declaración de Misión (Figura 1.4). La declaración de misión es una descripción breve y clara de los objetivos de la organización y los valores en los que cree. Los objetivos de la organización describen en detalle lo que desea conseguir. Los buenos objetivos tienen cinco elementos fundamentales: deben serSingulares, Medibles, Adecuados, Realistas, y ligados al Tiempo (SMART). La política de la organización es la combinación de todas las decisiones y medidas tomadas para definir y conseguir los objetivos. En tales políticas, la organización priorizará los objetivos y decidirá cómo se conseguirán los mismos. Por supuesto, las prioridades pueden cambiar con el tiempo, según las circunstancias. Cuánto más claras sean las políticas de la organización para todos losstakeholders, menor


CIBERTEC


13

necesidad de definir de qué manera el personal debe hacer su trabajo. En vez de utilizar procedimientos detallados, el personal puede guiarse con las políticas de manera independiente. Las políticas que se formulan con claridad contribuyen a crear una organización flexible, ya que todos los niveles de la organización pueden responder con mayor rapidez a las circunstancias cambiantes.

Figura 1.4 Visión, objetivos y políticas La planificación es necesaria para implementar las políticas en forma de actividades específicas. Los planes están a menudo divididos en etapas para fijar hitos que sirvan para monitorizar su progreso. Por ejemplo, se pueden usar las políticas para diseñar un plan anual, que se utilizará luego para desarrollar los presupuestos. Un plan anual puede hacerse más detallado para un departamento, un proyecto, o un trimestre. Cada uno de estos planes contiene un número de elementos: un programa de actividad, los recursos necesarios, y acuerdos sobre la calidad y cantidad de los productos o servicios a suministrar. Para realizar las actividades planeadas es precisa laacción. Las acciones son asignadas al personal comotareas, o cedidas a organizaciones externas. Cuando se traduce la misión de la organización en objetivos, políticas, planificación y tareas, existe el riesgo de que después de un tiempo la misión, los objetivos o las políticas se olviden. Por tal razón es importante que a cada paso semida si la organización todavía se está moviendo en la dirección correcta, y se tomen acciones correctivas si fuera necesario. Así, debemos evaluar si la organización y los procesos cumplen con los objetivos, y para ello existen varios métodos. Uno de los métodos del negocio más comunes es el Cuadro de Mando Integral (Balanced Score Card - BSC). En este método, los objetivos de la organización o los procesos se utilizan para definir Factores Críticos

CIBERTEC


14

de Éxito (Critical Success Factors - CSF). Los CSFs están definidos según áreas de interés o perspectivas: clientes/mercado, procesos del negocio, personal/innovación y finanzas. Los parámetros determinados para medir si los CFSs cumplen con los estándares se conocen comoIndicadores Clave de Rendimiento (Key Performance Indicators - KPI). Si es necesario se pueden subdividir en Indicadores de Rendimiento (PI). El resultado de las mediciones y las circunstancias cambiantes pueden llevar a la modificación de los procesos, tareas, planes, y políticas, y hasta a un cambio en los objetivos, la misión y la visión de la organización. Cuanto más madura es una organización, más fácil le resultará hacer frente a tales cambios. Si el departamento TI soporta los intereses del negocio, los objetivos del departamento TI derivarán de los objetivos del negocio. El departamento TI, por ejemplo, puede tener este objetivo: “Contribuir a la fuerza competitiva del negocio”.

Los objetivos específicos del departamento TI se desarrollarán así en base a este objetivo general. Según la naturaleza del negocio, los objetivos del departamento TI serán definidos tomando en cuenta aspectos de seguridad, accesibilidad, tiempo de respuesta, sofisticación técnica, y otras consideraciones.

2.2 Horizonte de planificación Cuando se consideran las políticas y la planificación del departamento TI, debemos ser conscientes de los lazos entre la planificación global del negocio, los sistemas de aplicación y la infraestructura técnica. Cuando planeamos la red y las aplicaciones del negocio, el departamento de TI deberá estar más allá de una planificación a corto plazo para garantizar que el negocio tenga una infraestructura TI en la que desarrollarse en el momento actual y en el futuro. La Figura 1.5 muestra un ejemplo de las relaciones entre los diferentes planes.

Figura 1.5 Horizonte de planeamiento La infraestructura técnica tiene un amplio horizonte de planificación y su papel de soporte contiene menos vínculos claros con las actividades esenciales del negocio. Lleva tiempo desarrollar la infraestructura técnica, y el hecho de que los sistemas de información y los negocios dependan de la infraestructura técnica limita la velocidad con la que se pueden implementarse los cambios. Además, la creación de una


CIBERTEC


15

infraestructura tecnológica demanda una inversión considerable y se debe tener en cuenta el tiempo de depreciación. El horizonte de planificación es más corto para lasaplicaciones ya que son diseñadas con intenciones claramente de negocio. Para poner en práctica la planificación del ciclo de vida de las aplicaciones lo primero que debe considerarse son las funciones del negocio que proveerá el sistema, tras lo cual se encuentra la tecnología fundamental. Los planes del negocio, basados en la estrategia de la organización, cubren por lo general un año natural o financiero. Durante este período se elaboran el presupuesto, los informes de planificación y de progreso. En algunos sectores se ha acortado el tiempo del de planificación, porque los ciclos de desarrollo de los productos también se ciclo han reducido. La planificación debe consignar cuatro elementos: Tiempo - es el factor más fácil de determinar. Lo define la fecha de comienzo y de finalización, y se divide a menudo en etapas. Cantidad - los objetivos deben ser medibles para monitorizar el progreso. Términos tales como ‘mejor’ y ‘más rápido’ resultan insuficientes para los fines de

la planificación. Calidad - la calidad de los entregables (resultados) deben ser los apropiados para el objetivo. Costes e ingresos - los resultados deben coincidir con los costes, esfuerzos e ingresos esperados.

2.3 Cultura Las organizaciones que desean cambiar, por ejemplo mejorando la calidad de sus servicios, se enfrentarán a la larga con la cultura de la organización. La cultura de la organización, o cultura corporativa, se refiere a la forma en la que las personas se relacionan unas con otras dentro de la organización; la manera en la que se toman y se llevan a cabo las decisiones; y la actitud de los empleados para con su trabajo, los clientes, abastecedores, superiores y colegas. La cultura, que depende de los estándares y valores del personal de la organización no puede controlarse, pero sí influenciarse. Influenciar la cultura de una organización supone liderazgo en forma de una política clara y consistente y de una política de personal que le dé soporte. La cultura corporativa puede tener gran influencia en la provisión de servicios TI. Los negocios valoran la innovación de diferentes formas. En una organización estable, donde la cultura dé poco valor a la innovación, puede resultar difícil ajustar sus servicios TI a los cambios en la organización del cliente. Si el departamento TI es inestable, una cultura que valora el cambio puede plantear una seria amenaza a la calidad de sus servicios. En tal caso, se puede producir la liberación completa, donde muchos cambios sin control producen gran cantidad de fallos.

CIBERTEC


16

2.4 Gestión de Recursos Humanos La política de personal tiene un papel importante y fundamental en la consecución de objetivos a largo plazo de una organización (ver también el modelo EFQM). También se puede utilizar para cambiar la política corporativa. El objetivo de la gestión de recursos humanos es optimizar el rendimiento de todo el personal de la organización, para lo cual se usan todos los instrumentos disponibles -incorporación y selección, capacitación y desarrollo profesional, motivación y gratificación. La Gestión de Recursos Humanos es la cumbre de la gestión de personal moderna. La Gestión de Recursos Humanos está basada en dos premisas: • La gestión de personal debe contribuir a los objetivos de la organización. Si las organizaciones tienen que responder mejor y con mayor rapidez en un ambiente que cambia cada vez más rápido, esto afectará al despliegue, la calidad y el volumen de personal. • Ofrecer a los empleados la posibilidad de desarrollar y utilizar sus habilidades beneficiará a la organización. La calidad de servicio que brinda una organización se beneficiará de un mejor uso del potencial de sus empleados. Esto facilita el progreso constante. Los instrumentos para la gestión de calidad en la política de personal incluyen: El despliegue de la política - comunicar a cada empleado cómo y hasta qué punto su tarea contribuye a hacer realidad los objetivos de la organización. Autorización - dar a los empleados la oportunidad de organizar e implementar sus tareas de acuerdo con la organización. Responsabilidad - como resultado de la política de despliegue y autorización. Si se explicó a un empleado lo que se espera de él, y si se le brindó la oportunidad de preparar y llevar a cabo la tarea como lo deseaba, entonces debe hacerse responsable de ello. Gestión de competencias - esto incluye el uso eficaz de las competencias disponible en la organización, y una forma sistemática de desarrollar las competencias que necesita la misma.

2.5 Gestión de Relaciones con el Cliente TI La calidad de los servicios TI depende ampliamente de la buena relación con los clientes de la organización TI. Estas relaciones sientan la base para establecer y actualizar los acuerdos. La Gestión de Relaciones con el Cliente TI es la encargada de mantener la relación con los clientes y de coordinar a nivel estratégico, táctico y operativo con las organizaciones de clientes. La Figura 1.6, un diagrama de las relaciones con el cliente, ilustra la comunicación horizontal que se da entre los clientes y la organización TI, con respecto al soporte y a la coordinación. La comunicación vertical tiene relación con las políticas, el control y la generación de informes.


CIBERTEC


17

Figura 1.6 Gestión de Relaciones con el Cliente En la Gestión de Relaciones con el Cliente TI, el mayor desafío es asegurar que existan relaciones buenas y eficaces a todo nivel entre la organización TI y la del cliente. Sin embargo, la magnitud de la Gestión de Relaciones con el Cliente TI será diferente según los niveles. Uno de los elementos en las relaciones con el cliente es el Centro de Servicios, y el control de los Niveles de Servicio se puede basar en la Gestión de Niveles de Servicio. En estas áreas, la Gestión de Relaciones con el Cliente TI representará, principalmente, un papel de soporte organizando, por ejemplo, encuestas entre los clientes y los usuarios, proporcionando información, etc. La Gestión de Relaciones con el Cliente TI representa un papel muy importante en el desarrollo del Alineamiento Estratégico entre la organización TI y la organización que compra de servicios TI. En la práctica, esto consiste principalmente en mantenerse en contacto con la organización de clientes, y explorar las opciones para aunar los objetivos estratégicos de ambas organizaciones. Esta puede ser la base de una relación a largo plazo, en la que la organización TI se centra en el cliente y propone soluciones que le ayuden a lograr sus objetivos del negocio. Dada la naturaleza dinámica de la organización de clientes y de la organización TI, también debe coordinarse las consecuencias de los cambios en ambas organizaciones. Los acuerdos con los clientes sobre los servicios provistos son especificados mediante propuestas de servicios en la Gestión de Niveles de Servicio. Por ejemplo, si el cliente desea introducir una Intranet, entonces se debe acordar la disponibilidad, el soporte a los usuarios, la implementación de peticiones de cambio y el coste. Tales acuerdos se formalizan en los Acuerdos de Nivel de Servicio (Service Level Agreement - SLA). Si la organización de clientes desea cambiar (expandir o modificar) servicios TI que se enmarcan dentro de los acuerdos establecidos en el SLA, se deberá generar una Petición de Cambio (Request For Change - RFC). La Gestión de Cambios procesa después esa petición. Los cambios que estén más allá de los acuerdos actuales se incluyen en el proceso de la Gestión de Niveles de Servicio. En la mayoría losconsultar casos, los usuarios pueden contactary alpara Centro de Servicios (Service Desk) de para tales peticiones y preguntas, informar sobre los problemas que aparecen.

CIBERTEC


18

La Figura 1.6 muestra información sobre la comunicación vertical y horizontal y sobre los horizontes de planificación de los procesos. La coordinación a nivel estratégico tiene un horizonte de planificación de varios años. La Gestión de Niveles de Servicio se relaciona con los acuerdos a nivel táctico, con un horizonte de planificación de por lo menos un año. La Gestión de Cambios, Centro de Servicios y la Gestión de Incidentes se ocupan del nivel de operaciones, con un horizonte de planificación de meses, semanas, días o hasta horas.


CIBERTEC


19

Resumen



La provisión de servicios TI implica la gestión total -mantenimiento y operaciónde la infraestructura TI.



El proceso de proveer un servicio es la combinación de producción y uso, en la que participan simultáneamente el proveedor y el cliente.



La calidad es el conjunto de características de un producto o servicio que influyen en la satisfacción de las necesidades explícitas e implícitas.



Los Indicadores Clave de Rendimiento, o KPIs, son parámetros para medir el progreso relativo con relación a los objetivos principales o Factores Críticos de Éxito (CSF) en la organización.



El usuario es la mano sobre el teclado, el cliente es aquél que pagala cuenta, obviamente el cliente también puede ser el usuario.

CIBERTEC


20


CIBERTEC


21


1 TEMA

2

GESTIÓN DE PROCESOS LOGRO DE LA UNIDAD DE APRENDIZAJE Al término de la unidad, el alumno describirá los conceptos básicos de la gestión de servicios de TI, y la estructura y los objetivos de ITIL, identificando con precisión sus características, componentes y ventajas.

TEMARIO Introducción Procesos Procesos y Departamentos Gestión de Servicios TI


CIBERTEC


22

1. INTRODUCCIÓN Todas las organizaciones se orientan a hacer realidad su visión, misión, objetivos y políticas, y para ello se deben realizar las actividades correctas. Volvamos al ejemplo del restaurante, las actividades adecuadas incluyen comprar alimentos, llevar la contabilidad, pedir material de publicidad, recibir a los invitados, limpiar las mesas, pelar las patatas, y hacer café. Con una lista tan desordenada, algo se va a escapar y nos confundiremos fácilmente. Por tal motivo es una buena idea estructurar las actividades. Sería preferible disponer de una lista de manera tal que podamos ver cómo cada grupo de actividades contribuye a los objetivos del negocio, y cómo se relacionan. Tales grupos de actividades se conocen como procesos. Si la estructura de procesos de una organización está claramente descrita, mostrará:    

Qué debe hacerse. Qué resultado se espera. Cómo medimos si los procesos dan los resultados esperados. Cómo los resultados de un proceso afectan a los de otros procesos.

Las preguntas de la Figura 2.1 surgen continuamente durante el típico planteamiento basado en el proceso de la Gestión de Servicios TI. Las herramientas para responder a estas preguntas se encuentran a la derecha.

Figura 2.1 Modelo de mejora del proceso

2. PROCESOS Cuando se organizan las actividades en procesos, no utilizamos la asignación existente de tareas, ni las divisiones departamentales existentes. Es una elección consciente. por una estructura procesos, podemos demostraroque actividades Al de optar la organización no estándecoordinadas, están duplicadas queciertas están descuidadas o son innecesarias. Un proceso es una serie de actividades relacionadas lógicamente que conducen a definir un objetivo.


CIBERTEC


23

En todo caso miramos al objetivo de los procesos y las relaciones con los otros procesos. Un proceso es una serie de actividades que se desarrollan para convertir una entrada en una salida (Figura 2.2). Podemos asociar el consumo y la producción de cada proceso con los estándares y las características de calidad para proveer información sobre los resultados que deben obtenerse con los procesos. Esto produce una cadena de procesos que muestra qué pasa dentro de la organización y cuáles son los resultados, y también los puntos de monitorización de la cadena para controlar la calidad de los productos y los servicios brindados por la organización.

Figura 2.2 Diagrama de proceso Los estándares de producción de cada proceso deben definirse para que la cadena completa de procesos cumpla con los objetivos de la corporación, si cada proceso se desempeña de acuerdo con los estándares definidos para ese proceso. El proceso será eficaz si el resultado del proceso se ajusta a los estándares definidos. En caso de que las actividades del proceso también se desarrollen con el mínimo esfuerzo y costes necesarios, el proceso seráeficiente. El propósito de la gestión de procesos es utilizar la planificación y el control para garantizar que los procesos sean eficaces y eficientes. Es posible estudiar cada proceso por separado para optimizar su calidad. El propietario del proceso es responsable de los resultados del mismo. Elgestor del proceso es responsable de realizar y estructurar los procesos, y de informar sobre ellos al propietario del proceso. Losoperadores del proceso son responsables de actividades específicas, y el gestor de procesos recibe información sobre estas actividades. La combinación lógica de las actividades da como resultado la clara transferencia de puntos en donde se puede controlar la calidad de los procesos. En el ejemplo del restaurante, podemos separar la responsabilidad de comprar y cocinar, para que los cocineros no tengan que comprar nada y no gasten demasiado en ingredientes frescos que no agregan valor. La dirección de la organización puede controlar teniendo en cuenta la calidad de los procesos según los datos de los resultados de cada proceso. En muchos casos, se deberán acordar los indicadores de rendimiento relevantes y los estándares. El control diariodeldeproceso los procesos puede dejado a considerando cargo del gestor procesos. El propietario evaluará losser resultados el de informe de los indicadores de rendimiento y observando si cumplen con los estándares acordados. Si los indicadores no son claros, el propietario del proceso tendrá dificultades para

CIBERTEC


24

determinar si los procesos están bajo control, y si se están implementando las mejoras proyectadas. Los procesos son descritos utilizando procedimientos e instrucciones de trabajo. Un procedimiento es una descripción de actividades lógicamente relacionadas, y de la persona que se encarga de realizarlas. Un procedimiento puede incluir etapas de distintos procesos. Un procedimiento define quién hace qué cosa, y varía dependiendo de la organización. Un grupo de instrucciones de trabajo delimita cómo se deben llevar a cabo una o más actividades en un procedimiento.

La Figura 2.3 muestra el modelo de proceso basado en la metodología ITIL que es la base del proceso de Gestión de Servicios TI que describe este manual.

Figura 2.3 Modelo de proceso genérico ITIL

3. PROCESOS Y DEPARTAMENTOS La mayoría de los negocios se encuentran organizados jerárquicamente. Tienen departamentos que son responsables de un grupo de empleados. Hay diferentes formas de estructurar los departamentos, por ejemplo por cliente, producto, región o disciplina. Los servicios TI dependen por lo general de varios departamentos, clientes o disciplinas. Por ejemplo, si hay que proporcionar un servicio TI a usuarios con


CIBERTEC


25

acceso a un programa contable a través de un servidor central, tendremos que hacer uso de varias disciplinas. El departamento de sistemas debe hacer que el programa y la base de datos estén accesibles, el departamento de comunicaciones debe hacer accesible los sistemas, y el departamento de soporte de PCs debe proveer a los usuarios con una interfaz para que puedan acceder a la aplicación. Los procesos que abarcan muchos departamentos pueden controlar la calidad del servicio evaluando ciertos aspectos como calidad, disponibilidad, capacidad, coste y estabilidad. Una organización de servicios tratará de alcanzar estos aspectos de calidad para cumplir con las peticiones de los clientes. La estructura de tales procesos debe garantizar que haya buena información sobre la provisión de servicios, para poder mejorar los servicios de planificación y control. La Figura 2.4 muestra un ejemplo básico de las combinaciones de actividades en un proceso (se indica con líneas punteadas).

Figura 2.4 Procesos y departamentos (ejemplo)

4. GESTIÓN DE SERVICIOS TI La Gestión de Servicios TI es lo que se conoce en principio como el planteamiento orientado al proceso y al servicio de lo que fue una vez la Gestión de TI. Los procesos siempre deben tener un objetivo definido. El objetivo de los procesos de Gestión de Servicios TI es contribuir a la calidad de los servicios TI. La gestión de calidad y el control de procesos forman parte de la organización y sus políticas. En un planteamiento orientado al proceso también debemos considerar la situación que se vive dentro de la organización (políticas, cultura, tamaño, etc.). ITIL, la mejor orientación conocida para la Gestión de Servicios TI, no dicta el tipo de organización, sino que describe las relaciones entre las actividades en los procesos, que son relevantes a cualquier organización. Esto proporciona un marco para intercambiar experiencias entre las organizaciones. Este planteamiento también ofrece un marco para aprender de la experiencia de organizaciones dinámicas.

CIBERTEC


26

Resumen



proceso es una serie de actividades relacionadas lógicamente que conducen aUndefinir un objetivo.



Un procedimiento es una descripción de actividades lógicamente relacionadas, y de la persona que se encarga de realizarlas. Un procedimiento puede incluir etapas de distintos procesos. Un procedimiento define quién hace qué cosa, y varía dependiendo de la organización.



Un grupo de instrucciones de trabajo delimita cómo sedeben llevar a cabo una o más actividades en un procedimiento.


CIBERTEC


27


1 TEMA

3

INTRODUCCIÓN A ITIL LOGRO DE LA UNIDAD DE APRENDIZAJE Al término de la unidad, el alumno describirá los conceptos básicos de la gestión de servicios de TI, y la estructura y los objetivos de ITIL, identificando con precisión sus características, componentes y ventajas.

TEMARIO Fundamentos Los Libros de ITIL


CIBERTEC


28

1. FUNDAMENTOS ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez más de las TI para alcanzar sus objetivos corporativos. Esta dependencia en aumento ha dado como resultado una necesidad creciente de servicios TI de calidad que se correspondan con los objetivos del negocio, y que satisfaga los requisitos y las expectativas del cliente. A través de los años, el énfasis pasó de estar sobre el desarrollo de las aplicaciones TI a la gestión de servicios TI. La aplicación TI (a veces nombrada como un sistema de información) sólo contribuye a realizar los objetivos corporativos si el sistema está a disposición de los usuarios y, en caso de fallos o modificaciones necesarias, es soportado por mantenimiento y operaciones. A lo70-80% largo dedel todo el ciclo de los yproductos alcanza cercadel del total del tiempo del coste,TI,y la el fase restodeseoperaciones invierte en el desarrollo producto (u obtención). De esta manera, los procesos eficaces y eficientes de la Gestión de Servicios TI se convierten en esenciales para el éxito de TI. Esto se aplica a cualquier tipo de organización, grande o pequeña, pública o privada, con servicios TI centralizados o descentralizados, con servicios TI internos o provistos por terceros. En todos los casos, el servicio debe ser fiable, consistente, de alta calidad, y de coste aceptable. La Gestión de Servicios TI dirige la provisión y el soporte de los servicios TI adaptados a las necesidades de la organización. ITIL fue creada para comunicar las mejores prácticas en la Gestión de Servicios TI sistemática y coherentemente. Su planteamiento se basa en la calidad de servicio y en el desarrollo eficaz y eficiente de los procesos. ITIL ofrece un marco común para todas las actividades del departamento TI, como parte de la provisión de servicios, basado en la infraestructura TI. Estas actividades se dividen en procesos, que proporcionan un marco eficaz para lograr una Gestión de Servicios TI más madura. Cada uno de estos procesos cubre una o más tareas del departamento TI, tal como desarrollo de servicio, gestión de infraestructura, y provisión y soporte de los servicios. Este planteamiento del proceso permite describir las mejores prácticas de la Gestión de Servicios TI independientemente de la estructura de organización real de la entidad. Muchas de estas prácticas son claramente identificables y son de hecho utilizadas hasta cierto punto en varias organizaciones TI. ITIL presenta estas mejoras prácticas de manera coherente. Los libros de ITIL describen cómo estos procesos, una vez identificados, pueden ser optimizados, y cómo la coordinación entre ellos puede ser mejorada. Los libros de ITIL también explican cómo los procesos se pueden formalizar dentro de una organización. Los libros de ITIL ofrecen un marco de referencia para unificar la terminología relevante dentro de la organización, y ayuda a definir los objetivos y a determinar el esfuerzo necesario para su cumplimiento. Utilizando el planteamiento basado en los procesos, ITIL describe primero lo que debe incluirse en la Gestión de Servicios TI para dotar los servicios TI de la calidad demandada. La estructura y la asignación de tareas y responsabilidades entre las funciones y los departamentos dependen del tipo de organización y estas estructuras varían mucho entre los departamentos TI y cambian con bastante frecuencia. La descripción de la estructura de proceso ofrece un punto de referencia común que no cambia con tanta frecuencia, ayudar a mantener calidad de losy servicios TI durante y después ydeque las puede reorganizaciones y entre loslaabastecedores los socios cuando cambian.


CIBERTEC


29

La lista incluida a continuación identifica algunas ventajas y desventajas de ITIL. Esta lista no pretende ser definitiva o exhaustiva, pero se ofrece como base para considerar las ventajas o las desventajas de ITIL y las distintas formas en que las organizaciones utilizan esta metodología. Ventajas de ITIL para e l cliente/usuario: 



 

La entrega de servicios TI se orienta más al cliente y los acuerdos sobre la calidad del servicio mejoran la relación entre el departamento TI y el cliente. Se describen mejor los servicios, en un lenguaje más cómodo para el cliente, y con mayores detalles. Se manejan mejor la calidad y el coste del servicio. Mejora la comunicación con la organización TI al acordar los puntos de contacto.

Ventajas de ITIL para la organización: 

 





La organización TI desarrolla una estructura más clara, se vuelve más eficaz, y se centra más en los objetivos corporativos. La dirección tiene más control y los cambios resultan más fáciles de manejar. Una estructura de proceso eficaz brinda un marco para concretar de manera más adecuada la externalización de algunos de los elementos de los servicios TI. Seguir las mejores prácticas de ITIL alienta el cambio cultural hacia la provisión de servicios, y sustenta la introducción de un sistema de gestión de calidad basado en las series ISO 9000. ITIL establece un marco de referencia para la comunicación interna y la comunicación con los abastecedores, así como la estandarización y la identificación de los procedimientos.

Problemas potenciales de ITIL: 

Su introducción puede llevar tiempo y bastante esfuerzo, y supone un cambio de cultura en la organización. introducción demasiado ambiciosa puede llevar a la frustración porque nuncaUna se alcanzan los objetivos.





 



Si la estructura de procesos se convierte en un objetivo en sí misma, la calidad del servicio se puede ver afectada de forma adversa. En ese caso, los procedimientos se transforman en obstáculos burocráticos que tratan de evitarse en lo posible.

Puede no haber progreso si existe falta de comprensión sobre lo que deben proporcionar los procesos, cuáles son los indicadores de rendimiento, y cómo se controlan los procesos. No se ven las reducciones de coste y la mejora en la entrega de los servicios. Una implementación con éxito implica el compromiso del personal de todos los niveles de la organización. Dejar el desarrollo de las estructuras de proceso a un departamento de especialistas puede aislar al departamento de la organización y puede fijar una dirección no aceptada por los otros departamentos. Si hay poca inversión en las herramientas de soporte, los procesos pueden no funcionar adecuadamente y el servicio no mejorará. Se pueden necesitar más recursos y más personal si la organización se encuentra sobrecargada con las actividades de rutina de la Gestión de Servicios TI.

Estos problemas potenciales supuesto quedeseestas pueden superar. ITIL fue desarrollada en vista de las ventajas que por aporta. Muchas sugerencias de mejores prácticas buscan prevenir tales problemas, o ayudar a solucionarlos en caso que aparezcan.

CIBERTEC


30

2. LOS LIBROS DE ITIL Cada uno de los libros de ITIL trata una parte del marco de trabajo y da una descripción general de lo que es necesario para organizar la Gestión de Servicios TI. ITIL define los objetivos y las actividades, y las entradas y salidas de los procesos de la organización TI. Sin embargo, ITIL no brinda una descripción específica de la forma en la que se deben implementar estas actividades, ya que esto puede variar de organización a organización. Se pone más énfasis en el planteamiento que ha sido probado; pero eso, según las circunstancias, puede ser implementado de diferentes formas. ITIL no es un método, sino que ofrece un marco de trabajo para planificar los procesos, los roles y las actividades más comunes, indicando los nexos entre ellos y los flujos de comunicación necesarios. ITIL se basa en la necesidad de proporcionar servicios de alta calidad, con énfasis en la relación con el cliente. La organización TI deberá cumplir los acuerdos con el cliente lo que implica mantener una buena relación con ellos, con los socios y con los abastecedores. Parte de la filosofía TI tiene su base en los sistemas de calidad, como la serie ISO 9000, y los marcos de trabajo de Calidad Total, como el EFQM. ITIL sustenta tales sistemas de calidad y ofrece una clara descripción de los procesos y las mejores prácticas en la Gestión de Servicios TI. Esto puede llevar a una reducción significativa del tiempo necesario para conseguir la certificación ISO. En principio, ITIL consistía en un gran número de libros, cada uno de los cuales describía un área específica de mantenimiento y operación de la infraestructura TI. Los diez libros que describían Soporte de Servicio y Entrega de Servicio eran considerados el eje de ITIL. Existían aproximadamente 40 libros más sobre temas suplementarios relacionados con la Gestión de Servicios TI, desde cableado hasta manejo de las relaciones con el cliente. Sin embargo, la serie de libros srcinales de la Infrastructure Library abordaba la Gestión de Servicios TI desde la perspectiva TI. El Conjunto de Perspectivas del Negocio se introdujo para acortar la distancia entre el negocio y la organización TI y ayudar a alinear sus objetivos. Y hay que tener en cuenta que con el tiempo ciertos aspectos de ITIL tenían un planteamiento algo anticuado. Los libros centrales de ITIL han sido revisados y se han publicado dos libros, uno sobre Soporte del Servicio, y otro sobre Provisión del Servicio. Esto ha eliminado muchas repeticiones y contradicciones ocasionales de las primeras colecciones y ha mejorado la cohesión interna. Ilustra también la visión de la Gestión de Servicios TI con más claridad. La estructura básica de ITIL se ilustra en la Figura 3.1, que utiliza un conjunto de piezas de rompecabezas como analogía, muestra los siete elementos principales de los libros ITIL. Cada uno de estos elementos se conecta con los otros seis, y hasta cierto punto se superpone. Los siete elementos son:      

Soporte del Servicio Provisión del Servicio Gestión de la Seguridad Gestión de Infraestructuras TI Gestión de Aplicaciones Planificación para Implementar la Gestión de Servicios Perspectiva del Negocio


CIBERTEC


31

Figura 3.1 ITIL puzzle

2.1 Soporte del Servicio El libro ITIL sobre Soporte del Servicio describe cómo el cliente puede tener acceso a los servicios adecuados para contribuir a su negocio. Este libro cubre los siguientes temas:    

Centro de Servicios (Service Desk) Gestión de Incidentes Gestión de Problemas Gestión de Configuraciones Gestión de Cambios Gestión de Versiones (Release Management)

2.1.1 Centro de Servicios (Service Desk) El Centro Previamente, de Servicios es punto ITIL de contacto inicial con lacomo organización TI para los usuarios. losellibros se referían a ésta Centro de Soporte (Help Desk). La tarea más importante del Centro de Soporte era registrar, resolver y controlar los problemas. El Centro de Servicios puede tener un papel más amplio (por ejemplo recibir Peticiones de Cambio) y puede encargarse de actividades relacionadas con muchos procesos. Es el punto de contacto inicial con el proveedor de servicios TI. 2.1.2 Gestión de Incidentes Entre las contribuciones realizadas por la ITIL al campo de la Gestión de Servicios TI la diferencia entre incidentes y problemas es posiblemente una de las más conocidas, pero no siempre la más popular. Aunque esta distinción puede a veces resultar confusa, su mayor ventaja yace en que la diferencia se hace entre la rápida restitución del servicio (tarea de la Gestión de Incidentes), y la identificación y el remedio de la causa del incidente (tarea de la Gestión de Problemas). El proceso de la Gestión de Incidentes tiene como objetivo resolver el incidente y restaurar la provisión del servicio rápidamente. Los incidentes son registrados, y la calidad del registro de incidentes determina la eficacia de cierto número de procesos a los que este registro aporta información.

CIBERTEC


32

2.1.3 Gestión de Problemas Si se sospecha que existe un problema dentro de la infraestructura TI, la Gestión de Problemas trata de identificar la causa raíz del mismo. Se puede sospechar que hay un problema porque se registran incidentes repetitivamente, pero está claro que el objetivo es la prevención de dichos incidentes cuando sea posible. Una vez que se identificaron las causas (errores conocidos), se decide si es necesario realizar mejoras permanentes en la infraestructura para prevenir nuevos incidentes. Esta mejora se hace emitiendo una Petición de Cambio. 2.1.4 Gestión de Configuraciones La Gestión de Configuraciones se encarga de realizar los cambios de infraestructura (estandarización y verificación del estado), de identificar los elementos de configuración (inventario, vínculos respectivos, verificación y registro), de reunir y gestionar la documentación de la infraestructura TI y de proporcionar información de la Infraestructura TI a todos los otros procesos. 2.1.5 Gestión de Cambios La Gestión de Cambios asume la tarea de implementar los cambios en la infraestructura TI de manera controlada. El objetivo del proceso es determinar los cambios necesarios, y cómo deben implementarse para que produzcan el menor efecto adverso sobre los servicios TI, y al mismo tiempo garantizar la correcta identificación de los cambios, a través de una eficaz coordinación en toda la organización. Los cambios se realizan a partir del estado de las actividades monitorizadas por la Gestión de Configuraciones, a petición de la organización del cliente, la Gestión de Problemas y muchos otros procesos. Los cambios se implementan siguiendo unos pasos específicos de definición, planificación, construcción y pruebas, aceptación, implementación y evaluación. 2.1.6 Gestión de Versiones (Release Management) Una versión es un grupo de elementos de configuración (CIs) que son probados e introducidos juntos en el entorno en uso. EL principal objetivo de la Gestión de Versiones es garantizar un correcto despliegue de versiones, incluyendo la integración, el análisis y el almacenamiento de las mismas. La Gestión de Versiones garantiza que se suministren sólo aquellas que son correctas y que se hayan analizado. Este proceso se relaciona de cerca con las actividades de la Gestión de Configuraciones y de Cambios. A través de las actividades de la Gestión de Versiones se implementan de manera real los cambios.

2.2 Provisión del Servicio Como se indicó anteriormente, el Soporte del Servicio y la Provisión del Servicio son considerados parte central del marco de trabajo ITIL para la Gestión de Servicios TI. El libro ITIL sobre Provisión del Servicio describe los servicios que necesita el cliente, y lo esencial para proporcionarlos.


CIBERTEC


33

Los siguientes temas se encuentran en la colección de Provisión del Servicio:    

Gestión de Niveles de Servicio Gestión Financiera de los Servicios TI Gestión de la Capacidad Gestión de la Disponibilidad Gestión de Continuidad de los Servicios TI

La compleja interrelación entre los procesos descritos en los libros sobre Soporte del Servicio y Provisión del Servicio es casi imposible de mostrar en este diagrama. El diagrama simplificado de la Figura 3.2 ilustra las principales generalidades.

Figura 3.2 Soporte del Servicio y Provisión del Servicio 2.2.1 Gestión de Niveles de Servicio El objetivo de la Gestión de Niveles de Servicio es establecer acuerdos claros con el cliente sobre los servicios TI, e implementar estos acuerdos. En consecuencia, la Gestión de Niveles de Servicio precisa información sobre las necesidades del cliente, los recursos proporcionados por la organización TI, y los recursos financieros disponibles. En base a esta información se determinan los KPI y se verifica la calidad de los servicios. La Gestión de Niveles de Servicio maneja el servicio prestado al cliente (Foco en el Cliente). Al crear servicios basados en las necesidades del cliente (atracción por demanda) y no sólo según lo que le resulta técnicamente factible en la actualidad (impulsada por el suministro), la organización TI puede mejorar la satisfacción del cliente. El capítulo sobre Gestión de Niveles de Servicio en el libro de Provisión del Servicio describe:

CIBERTEC


34

La claridad con la que se deben definir los acuerdos en el Acuerdo de Nivel de Servicio puede optimizar los servicios TI al justificar el coste para el cliente. Cómo se puede evaluar y discutir el servicio. Cómo se puede reforzar el servicio al soportar los Contratos con los abastecedores de la propia organización TI.  

2.2.2 Gestión Financiera de los Servicios TI La Gestión Financiera de los Servicios TI maneja todo lo relativo con la entrega prudente de los servicios TI. Por ejemplo, la Gestión Financiera proporciona información sobre los costes en los que incurre la organización al suministrar los servicios TI. Esto permite una consideración adecuada de los costes y beneficios (precio y rendimiento) al decidir qué cambios sobre realizarGestión en la infraestructura en los como se en el capítulo Financiera del olibro de servicios Provisión TI. delTal Servicio, la discute identificación, asignación, proyección y evaluación de los costes se denominan bajo el término “contabilidad de costes”, que en la versión actual de ITIL aparece como Elaboración de

Presupuesto y Contabilidad. Estas actividades ayudan a entender los costes (¿en qué costes se incurre y dónde?) y también se puede utilizar en la elaboración del presupuesto. Con respecto a la corriente de ingresos de la organización TI, la Gestión Financiera de los servicios TI describe varios métodos de imputación, que incluye la definición de objetivos y la determinación del precio, además de elaborar los diferentes aspectos del presupuesto.

2.2.3 Gestión de la Capacidad La Gestión de la Capacidad es el proceso de optimización de costes, tiempo de adquisición, y despliegue de los recursos TI para sustentar los acuerdos establecidos con el cliente. La Gestión de la Capacidad tiene a su cargo la gestión de recursos, de rendimiento, de demanda, modelado, capacidad de planificación, la gestión de carga y el ajuste del tamaño. La Gestión de la Capacidad hace énfasis sobre la planificación para garantizar que los Niveles de Servicio acordados también se puedan cumplir en el futuro. 2.2.4 Gestión de la Disponibilidad La Gestión de la Disponibilidad es el proceso de garantizar el correcto despliegue de los recursos, métodos y técnicas, para sustentar la disponibilidad de los servicios TI acordados con el cliente. La Gestión de la Disponibilidad se encarga de temas tales como optimizar el mantenimiento, o diseñar medidas para minimizar el número de incidentes. 2.2.5 Gestión de Continuidad de los Servicios TI Este proceso indica la preparación y la planificación de medidas de recuperación ante desastres en los servicios TI en el caso de que se produzca una interrupción del negocio. Conocida como Planificación de Contingencias en la revisión anterior de ITIL, pone énfasis en los vínculos entre todas las medidas necesarias para salvaguardar la continuidad de la organización de clientes ante la posibilidad de un desastre (Gestión de la Continuidad del Negocio) y las medidas para prevenir tal desastre. La Gestión de Continuidad de gestión Servicios es el que proceso de planificación y coordinación técnica, financiera y de de TI recursos se necesita para garantizar la continuidad del servicio tras el desastre, según lo convenido con el cliente.


CIBERTEC


35

2.3 Gestión de la Seguridad El objetivo de la Gestión de la Seguridad es proteger la infraestructura TI del uso sin autorización (como el acceso sin autorización a la información). Esto se basa en los requisitos establecidos en los Acuerdos de Nivel de Servicio, en los requisitos contractuales, la legislación y la política, y un nivel básico de seguridad.

2.4 Gestión de Infraestructuras TI Los procesos de gestión de operaciones TI se desarrollan en el libro ITIL sobre Gestión de Infraestructuras TI. Este libro cubre: 

  

Gestión del Servicio de Redes Gestión de Operaciones Gestión de Centros distribuidos Instalación y Aceptación de Ordenadores Gestión de Sistemas Gestión del Entorno

2.5 Gestión de Aplicaciones El libro ITIL sobre Gestión de Aplicaciones trata la relación entre la gestión y el ciclo de vida del software. Incluye temas tales como Soporte del Ciclo de Vida del Software y Análisis de un Servicio TI para Uso Operativo. Un tema muy importante en Gestión de Aplicaciones es como se responde eficazmente a los cambios en el negocio. En este punto, resulta de suma importancia definir los requisitos e implementar una solución que satisfaga al cliente.

2.6 Planificación para Implementar la Gestión de Servicios En esencia, el concepto de planificación e implementación de cambios en la Gestión de Servicios TI se describe en el modelo de mejora de los procesos (capítulo 2). En la práctica, situación que se ilustrasus en decisiones, este modeloque no se manifiesta la formapor en la que las laorganizaciones toman puede verse en afectada aspectos históricos o políticos. Por tal razón es imprescindible que los directivos se comprometan con el programa de mejoras (Gestión de Compromisos), y que entiendan la cultura de la organización. Se debe ser consciente que ya puede haber procesos que logren las necesidades de la organización, al menos en parte. Si se ignora esto, se puede generar resistencia en las personas necesarias para alinear mejor estos procesos con las necesidades del negocio y la experiencia adquirida con la Gestión de Servicios TI. Hará falta una comisión temporal para analizar las necesidades de la organización e implementar las soluciones necesarias. En un plan de mejora esto puede ser considerado un proyecto en sí mismo, o una serie de proyectos. Una de las ventajas es que la organización se topará con puntos decisivos y podrá decidir si terminar, continuar, o modificar el proyecto. Cada proyecto debe basarse en el análisis de la situación actual, la situación deseada, y el camino entre ambas. En muchos casos, las alternativas se compararán según:  



Conveniencia para la organización. Riesgos, obstáculos y problemas potenciales. Costes de transición y costes a largo plazo.

CIBERTEC


36





Costes por continuar con el planteamiento actual. Identificar las alternativas potenciales puede resultar un proyecto en sí mismo.

La experiencia nos demuestra que ITIL no es una fórmula mágica. No se deben esperar milagros. Se debe prestar particular atención a los llamados proyectos de implementación ITIL que esconden una agenda particular -reorganización o fusión. ITIL describe la mejor práctica para perfeccionar la Gestión de Servicios TI, no es un libro de cocina para organizaciones. En principio ITIL brinda un marco de referencia para estructuras de proceso en la organización TI y, en un nivel más bajo, una guía para la estructura de esa organización. Si un proyecto tiene como objetivo mejorar la organización como tal, es aconsejable contratar expertos en el campo. Una medición de base o un análisis de salud puede ser un buen comienzo para el proceso de mejora. Una evaluación así de la Gestión de Servicios TI puede ayudar a identificar las fortalezas y las debilidades de la organización, y a definir con claridad los objetivos del proyecto de mejora. La medición se puede repetir después de un tiempo para ver el progreso del proyecto o programa.

2.7 Perspectiva del Negocio Los libros ITIL de la Colección Perspectiva del Negocio describen muchos temas relacionados con la comprensión y la apreciación de los servicios TI como un aspecto integrado a la gestión del negocio. La colección de Perspectiva del Negocio, y el libro de Perspectiva del Negocio, que eventualmente reemplazará la colección, incluye:   





Gestión de la continuidad del negocio Asociaciones y externalización (outsourcing) Cambios para la supervivencia

Adaptación del negocio a los cambios radicales Gestión de recursos físicos Gestión de relaciones con abastecedores


CIBERTEC


37

Resumen

ITIL fue creada para comunicar las mejores prácticas en la Gestión de Servicios



TI sistemática y coherentemente. Su planteamiento se basa en la calidad de servicio y en el desarrollo eficaz y eficiente de los procesos. 

Los siete libros de ITIL son: -



El libro Soporte del Servicio cubre los siguientes temas: -



Centro de Servicios (Service Desk) Gestión de Incidentes Gestión de Problemas Gestión de Configuraciones Gestión de Cambios Gestión de Versiones (Release Management)

El libro Provisión del Servicio cubre los siguientes temas: -



Soporte del Servicio Provisión del Servicio Gestión de la Seguridad Gestión de Infraestructuras TI Gestión de Aplicaciones Planificación para Implementar la Gestión de Servicios Perspectiva del Negocio

Gestión de Niveles de Servicio Gestión Financiera de los Servicios TI Gestión de la Capacidad Gestión de la Disponibilidad Gestión de Continuidad de los Servicios TI

Si desea saber más acerca deestos temas, puede consultar la siguiente página: 

http://itil.osiatis.es/Curso_ITIL/ Aquí hallará más información sobre el presente capítulo.

CIBERTEC


38


CIBERTEC


39


2 TEMA

4

CENTRO DE SERVICIOS LOGRO DE LA UNIDAD DE APRENDIZAJE Al término de la unidad, el alumno explicará las funciones del centro de servicios o service desk y los procesos que conforman el soporte del servicio de TI, identificando con precisión sus características, componentes, ventajas, recomendaciones de implementación y medición, así como la interrelación de dichos procesos.

TEMARIO Introducción Objetivos Actividades Estructura


Analizar el caso propuesto por el profesor en clase.

CIBERTEC


40

1. INTRODUCCIÓN El Centro de Servicios (Service Desk) proporciona un punto de contacto a diario vital entre los clientes, usuarios, servicios TI y organizaciones de soporte externas. La Gestión de Nivel de Servicio es un habilitador de negocio primordial para esta función. Un Service Desk proporciona valor a una organización ya que: 



 



Actúa como una función estratégica para identificar y reducir el coste de propiedad de soportar la infraestructura de soporte e informática Soporta la integración y la gestión de cambio a través de los límites del negocio distribuido, la tecnología y los procesos Reduce costos con el uso eficiente de recursos y tecnología Soporta la optimización de inversiones y la gestión de servicios de soporte del negocio Ayuda a asegurar la satisfacción del cliente y su retención a largo plazo Asiste en la identificación de oportunidades de negocio

Estratégicamente, para los clientes el Service Desk es probablemente la función más importante de una organización. Para muchos, el Service Desk, es la única ventana en el nivel de servicio y profesionalismo ofrecida por toda la organización o un departamento, lo cual constituye el componente más importante de servicio de Satisfacción “ y Percepción del Cliente”. Dentro de las funciones TI, el Service Desk representa los intereses del cliente para el equipo de servicio. Cuando un servicio se ha interrumpido, el objetivo de algunos procesos es restaurar el servicio. El Service Desk es la organización que facilita dichos procesos. Esto significa que el Service Desk es responsable de un evento de servicio de principio a fin. Mientras que otras funciones, como el soporte de segunda y tercera línea, asistirán en la resolución, el Service Desk retiene el control “administrativo” de la incidencia.

El Service Desk no está programado con la tarea de encontrar la causa srcinal de una interrupción de servicio, esta responsabilidad corresponde a la Gestión de Problemas.

2. OBJETIVOS  

Proveer un Único Punto de Contacto (SPOC) con los Clientes Facilitar la restauración de un servicio normal de operaciones, con un mínimo impacto en los negocios del cliente, dentro de los niveles de servicio acordados y las prioridades del negocio

3. ACTIVIDADES 

 

 

Recibir llamadas, primer enlace con el cliente Grabar y seguir los incidentes y las quejas Mantener a los clientes informados sobre el requerimiento y su evolución Hacer una valoración inicial de los requerimientos, intentando resolverlos o remitirlos a otra persona que puede atenderlos, basado en un nivel de servicio acordado Monitorear y escalar de acuerdo al SLA Administrar el ciclo de vida del requerimiento, incluyendo el cierre y la verificación




CIBERTEC

Comunicar a los clientes los cambios planificados y de corto plazo de los niveles de servicio


41

Coordinar con los grupos de soporte de segunda línea y externos Generar informes de gestión y recomendaciones para el mejoramiento del servicio Identificar problemas Destacar las necesidades de educación y entrenamiento del cliente Cerrar los incidentes y confirmación con el cliente Contribuir a la identificación del problema

3.1 Interacción con el cliente La interacción del cliente ya no se limita tan solo al contacto telefónico y personal. El servicio puede mejorar enormemente y ser extendido al cliente, usuarios y personal de soporte expandiendo los métodos de registrar, actualizar y consultar las solicitudes. Esto puede realizarse utilizando el e-mail y el lnternet/lntranet para oficinas remotas, aunque el fax también puede ser una herramienta valiosa. Estos métodos son mejor explotados para actividades que no son críticas para el negocio, que incluye el registro de incidentes o requerimientos no urgentes, tales como: Adquisición de productos Consultas de aplicación

Requerimientos para traslados, instalaciones, mejoras y actualizaciones de equipamiento Requerimiento de consumibles Para el equipo de soporte, los beneficios incluyen: Se libera al personal de soporte de interrupciones telefónicas innecesarias Las cargas de trabajo se manejan mejor El uso de formularios aumenta equipo la integridad de los datos y ayudan con la asignación del especialista, o departamento desuministrados soporte más adecuado. La herramienta del Service Desk debería automáticamente proporcionar al cliente o al usuario un número de referencia único de recepción, que también permita la consulta en línea del progreso del requerimiento. Proporcionar a los clientes y usuarios la confirmación que su requerimiento ha sido aceptado y de su progreso, es uno de los roles más importantes del Service Desk. Aún muy pocas organizaciones tienen los recursos de personal para centrarse y mantener esta actividad. Como se indicó anteriormente, el uso de tecnologías, como el e-mail, ayudarán con dicha actividad. Sin embargo, el reto real es crear un vínculo personalizado con los clientes, aunque sea mediante la comunicación electrónica.

4. ESTRUCTURA 4.1 Tipos de Mesas (Desks) 4.1.1 Centro Telefónico (Call Centre) El énfasis de un Call Centre está en manejar grandes volúmenes de transacciones srcinadas por teléfono. Normalmente, un Call Centre no reaccionará a esas transacciones sino que sólo las registrará y las referirá a otras partes de la organización.

CIBERTEC


42

4.1.2 Servicio al Cliente (Help Desk) El principal propósito es gestionar, coordinar y resolver Incidentes lo antes posible y asegurarse de que ningún requerimiento se pierda, olvide o ignore. Los vínculos con la Gestión de Configuración y las herramientas de conocimiento se utilizan generalmente como tecnologías de soporte. 4.1.3 Centro de Servicios (Service Desk) El Service Desk extiende el campo de servicios permitiendo que se integren procesos de negocio en la infraestructura de Gestión de Servicio. No sólo maneja Incidentes, Problemas y consultas, también proporciona un nexo común para otras actividades como requerimientos de Cambio de los clientes, contratos de mantenimiento, licencias de software, Gestión de Nivel de Servicio, Gestión de Configuración, Gestión de Disponibilidad, Gestión Financiera de los Servicios TI y Gestión de Continuidad de Servicio TI. Muchos Call Centres y Help Desks naturalmente evolucionan hasta convertirse en Service Desks para mejorar y extender su servicio global a los Clientes y el negocio. Las tres funciones comparten características comunes: 

 

Representan el proveedor de servicio al Cliente y al Usuario (interno o externo). Operan con el principio de que la satisfacción y percepción del cliente son

críticos. Dependen de armonizar personas, procesos y tecnología para entregar un servicio del negocio.

4.2 Estructuras de Service Desk 4.2.1 Service Desk Local Tradicionalmente, las organizaciones han creado desks de soporte locales (ver Figura 4.1) para cumplir las necesidades locales del negocio. Esto es práctico hasta que múltiples localidades requieran servicios de soporte. Duplicar habilidades y recursos será muy costoso. Si su organización está manteniendo varios desks de soporte local, es importante introducir estándares operacionales. Consideraciones para implementar una estructura de Service Desk Local incluyen: 



 





Establecer procesos comunes para todas las localidades y, cuando sea posible, procedimientos comunes. Hacer que las habilidades locales se conozcan y estén disponibles a otros Service Desks. Asegurar compatibilidad de hardware, software e infraestructura de red. Usar los mismos procesos de escalamiento, y los mismos códigos de impacto, severidad, prioridad y estatus en todas las localidades. Usar métricas de reportes de gestión comunes. Usar una base de datos compartida común.

Si es posible, pasar o escalar requerimientos entre Service Desks, preferiblemente de forma automática.


CIBERTEC


43

Figura 4.1 Service Desk Local 4.2.2 Service Desk Centralizado En esta opción, todos los requerimientos de servicio están registrados en una localización física central (ver Figura 4.2). Si su organización tiene múltiples localidades, tener un servicio de soporte central tiene mayores ventajas para el negocio, tales como:  



Reducción de costos operacionales Visión global y consolidada de la gestión Mejor uso de los recursos disponibles

Figura 4.2 Service Desk Centralizado

CIBERTEC


44

4.2.3 Service Desk Virtual En gran medida la ubicación física del Service Desk y los servicios asociados no son materiales, debido a los avances en el rendimiento de la red y las telecomunicaciones. El”Service Desk Virtual” (ver Figura 4.3)puede ubicarse y ser accedido desde cualquier lugar del mundo. Si su organización tiene múltiples localidades, tener un servicio de soporte global único tiene mayores ventajas para el negocio, tales como:  



Reducción de costos operacionales El alcance para una visión global y consolidada de la gestión Mejor uso de los recursos disponibles

Sin embargo, la restricción operacional primordial del Desk Virtual es la necesidad de la presencia física de un especialista o un ingeniero de reemplazo.

Figura 4.3 Service Desk Virtual Consideraciones para montar un Service Desk Virtual incluyen los siguientes puntos: 







Todas las personas que acceden al Service Desk Virtual deberían usar procesos, procedimientos y terminología comunes. Un lenguaje común, acordado debería ser utilizado para la introducción de datos. Clientes y Usuarios todavía necesitan interactuar con un solo punto de contacto. Considere números de teléfonos globales, números locales que enrrutan al Desk Virtual y la tecnología de Distribución de Llamada Automática (ACD). Habrá necesidad de la presencia física in situ de un especialista o ingeniero de mantenimiento de vez en cuando.

El rendimiento de la red debería “adecuarse a su propósito”. Esto debe ser

revisado en términos de previsiones de carga de trabajo. Por ejemplo, si el


CIBERTEC


45

Service Desk de Holanda sólo se encarga de diez requerimientos al día, entonces el volumen de red puede que no sea de mayor consideración. Sin embargo, un ancho de banda reducido no es práctico si se procesan varios centenares de requerimientos al día. Para el Desk Virtual, las herramientas de soporte establecidas deberían permitir la “partición del trabajo” y las vistas autorizadas . (Por ejemplo, si yo soy la persona encargada del soporte local en Amsterdam, sólo quiero ver los requerimientos de esa localidad). Esto debería incluir otros procesos asociados y datos relacionados, tales como Cambios programados, bienes y datos de configuración. Propiedad consistente y procesos de gestión para Incidentes deberían ser utilizados en el Service Desk Virtual, con transferencias automatizadas de Incidentes y vistas de Incidentes entre desks locales.

4.3 Consideraciones para la implementación de un Service Desk 







 



  



Primero establecer que la necesidad del negocio está claramente identificada y entendida. Asegurarse que el compromiso de la dirección, el presupuesto y los recursos están disponibles. Asegurarse que la solución propuesta se alinea con la visión y la estrategia del Soporte de Servicio. Identificar, alcanzar y comunicar triunfos rápidos (ej. mantener a los clientes informados, mejora en los tiempos de instalación). Definir objetivos y entregables claros. Empezar de modo sencillo; no intente hacer todo de golpe; adopte un enfoque en fases. Involucrar/ consultar a sus Clientes y Usuarios finales, especialmente a los más importantes; no use jerga. Venda los beneficios al personal de soporte. Capacite al personal de TI para ser personal de servicio. Eduque/ capacite a los Clientes y Usuarios en el uso del nuevo servicio y sus beneficios. Anuncie y “venda” su servicio.

4.3.1 Consideraciones para el ambiente del Service Desk 





 





CIBERTEC

Si es posible, proveer un cuarto/ local alejado del área de soporte principal con: Un área agradable y confortable para Clientes y personal del Service Desk Un ambiente de bajo nivel de ruido Privacidad Instalar una biblioteca de todos sus productos, documentación de hardware y software y material de referencia que utilizan los Clientes. Asegurar que un Catálogo de Servicio actualizado esté disponible en todo momento. Instalar facilidades telefónicas de conferencia y unidades de manos libres. Proveer espacio de mesas y asientos para discusiones de mesa redonda- esto ayuda a calmar la situación de “ellos y nosotros”. Proveer facilidades de refrescos para ofrecer a Clientes, o al menos acceso fácil a ellos. Publicar a la base de Clientes la ubicación de la unidad y sus tiempos de operación. CARRERAS PROFESIONALES

46

Resumen



El Centro de Servicios (Service Desk) provee un Único Punto de Contacto (SPOC) con los Clientes.



Tipos de Mesas (Desks): -



Estructuras de Service Desk -



Centro Telefónico (Call Centre) Servicio al Cliente (Help Desk) Centro de Servicios (Service Desk)

Service Desk Local Service Desk Centralizado Service Desk Virtual




CIBERTEC


47


2 TEMA

5

GESTIÓN DE LA CONFIGURACIÓN LOGRO DE LA UNIDAD DE APRENDIZAJE Al término de la unidad, el alumno explicará las funciones del centro de servicios o service desk y los procesos que conforman el soporte del servicio de TI, identificando con precisión sus características, componentes, ventajas, recomendaciones de implementación y medición, así como la interrelación de dichos procesos.

TEMARIO Objetivos Actividades Descripción del Proceso Roles y Responsabilidades



CIBERTEC


48

1. OBJETIVOS 

 





 



Proporcionar a todas las personas que trabajan en Gestión y Soporte de Servicios información correcta y exacta de las configuraciones actuales con sus especificaciones físicas y funcionales. Definir y documentar los procedimientos y prácticas del trabajo a seguir. Identificar, etiquetar y registrar los nombr es y versiones de los Cl’s (Configuration Item o Elemento de Configuración) que constituyen los servicios TI, infraestructura y sus relaciones. Controlar y almacenar copias definitivas, autorizadas y fiables de especificaciones, documentación y software. Informar del estatus actual e historial de todos los elementos en la infraestructura TI. Asegurar que todos los Cambios a CI’s se registran inmediatamente.

Localizar y reconciliar el estado actual de la infraestructura TI con los historiales de configuración autorizados y los datos. Educar y formar a la organización en procesos de control. Informar de métricas en CI’s, Cambios y Versiones.











Auditar e informar de excepciones a los estándares de infraestructura y los procedimientos de Gestión de Configuración. Proporcionar informaciónexacta de configuraciones y su documentación para soportar todos los demás procesos de Gestión de Servicio. Proporcionar una base sólida para Gestión de Incidentes, Gestión de Problemas, Gestión de Cambios y Gestión de Versiones. Contabilizar todos los bienes y configuraciones de IT dentro de la organización y sus servicios. Verificar los historiales de configuración con la infraestructura y corregir las excepciones si las hubiera.

2. ACTIVIDADES La Gestión de Configuración cubre la identificación, registro, y reportes de los componentes TI, incluyendo sus versiones, componentes constituyentes y relaciones. Los elementos que deben estar bajo el control del la Gestión de Configuración comprenden hardware, software y documentación asociada. La Gestión de Configuración no es sinónimo con la Gestión de Activos, aunque las dos disciplinas estén relacionadas. La Gestión de Activos es un proceso reconocido de contabilidad que incluye la depreciación contable. Los sistemas de Gestión de Activos mantienen detalles sobre un cierto valor, sus unidades de negocio y sus localizaciones. La Gestión de Configuración también mantiene relaciones entre activos, lo cual la Gestión de Activos usualmente no hace. Algunas organizaciones empiezan con la Gestión de Activos y luego pasan a la Gestión de Configuración. Las actividades básicas de la Gestión de Configuración son las siguientes: 



Planificación. Planificar y definir el propósito, alcance, objetivos, políticas y procedimientos, y el contexto de organización y técnico para la Gestión de Configuración. Identificación. Seleccionar e identificar las estructuras de configuración para todos los CI´s de la infraestructura, incluyendo sus “propietarios”, sus

interrelaciones y la documentación de configuración. Esto incluye asignar


CIBERTEC






49

identificadores y los números de versión para CI´s, etiquetar cada elemento e introducirlo en la Base de Datos de Gestión de Configuración (CMDB). Control. Asegurar que solo CI´s autorizados e identificados son aceptados y registrados desde la recepción hasta la eliminación. Esto garantiza que ningún CI es añadido, modificado, reemplazado o eliminado sin la documentación de control apropiada, por ejemplo una solicitud de Cambio aprobada, y una especificación actualizada. Registro de estado. Informar de todos los datos históricos y actuales que conciernen a cada CI a lo largo de su ciclo de vida. Esto permite hacer un seguimiento de los Cambios a CI´s y de sus registros, por ejemplo rastrear el estado de un CI y sus cambios de un estado a otro tales como “en desarrollo”, “en prueba”, “en producción” o “retirado”.



Verificaciónfísica y auditoría. Unay serie revisiones yque auditorías verifican la existencia de CI´s que de comprueban están que correctamente registrados en el sistema de Gestión de Configuración.

La Gestión de Configuración se comunica directamente con desarrollo de sistemas, pruebas, Gestión de Cambios y Gestión de Versiones para incorporar productos actualizados y nuevos. El “pase a producción” debe ser en el tiempo planificado con

los registros precisos de configuración.

3. DESCRIPCIÓN DEL PROCESO 3.1 Conceptos Básicos 3.1.1 Bien Componente de un proceso tal como personas, instalación, sistemas informáticos, expedientes de papel, máquinas de fax, etc. 3.1.2 Elemento de Configuración (CI) Componente de una infraestructura, o un elemento, tal como una Solicitud de Cambio, asociado con una infraestructura, y servicios, que estén (o han de estar) bajo el control de Gestión de Configuración. Cl’s pueden variar mucho en

complejidad, tamaño y tipo, desde un sistema entero a un componente de hardware menor. Ejemplos son: hardware, software, documentación, procedimientos, funciones, instalaciones, servicios, servidores, entornos, equipamiento, componentes de red, escritorios, unidades móviles, aplicaciones, licencias, telecomunicación. 3.1.3 Base de Datos de Gestión de Configuración (CMDB) Muchas organizaciones ya utilizan algunos elementos de Gestión de Configuración, a menudo usando hojas de cálculo, bases de datos locales o sistemas basados en papel. En las infraestructuras de hoy en día, grandes y complejas, la Gestión de Configuración requiere el uso de herramientas de soporte, que incluye la Base de Datos de Gestión de Configuración (CMDB). Son necesarios archivos electrónicos y físicos junto al CMDB para almacenar copias definitivas de software y documentación. Es probable que la CMDB se base en tecnología de base de datos que proporciona facilidades de consultas y poderosas. La CMDB debe contener todas las relaciones entre losflexibles componentes del sistema, incluidos Incidentes, Problemas, Errores Conocidos (KE), Cambios y Versiones. La CMDB también contiene información sobre Incidentes, Errores Conocidos (KE) y Problemas y datos corporativos de empleados, proveedores, localidades y unidades de negocio.

CIBERTEC


50

La CMDB también se puede utilizar para almacenar y controlar los detalles de los Usuarios de TI, empleados de TI y unidades de negocio, aunque las implicaciones legales de almacenar información sobre personas en la CMDB se deben considerar. Almacenar tal información en la CMDB permitiría que Cambios de Personal se relacionaran con la propiedad de Cambios de CI.

3.2 Alcance y Detalle de la CMDB 3.2.1 Alcance o extensión de la CMDB Cuando se establece una CMDB y cuando se actualiza el modelo de datos, se debe decidir qué parte la infraestructura TI debe controlary lamáquinas Gestión de Por ejemplo, se de deberían incluir PDAs, copiadoras deConfiguración. fax en red, teclados y personal TI, o están fuera del alcance. El alcance de la CMDB afecta el alcance de los diagnósticos de la Gestión de Problemas, el análisis de impacto de la Gestión de Cambios, la comprobación de los SLAs, el análisis y planeamiento de la Gestión de la Disponibilidad, etc. También se pueden analizar los servicios TI y su contribución o impacto en las actividades comerciales del cliente. El alcance se puede dividir en áreas con sus propios requisitos y planteamientos (ver Figura 5.1). Ejemplos de estas áreas son estaciones de trabajo, comunicación de datos, archivos, servicios de impresión y aplicación, procesamiento central, base de datos y sistemas TI, y servicios de telefonía. El alcance de la CMDB también puede incluir documentación, como SLAs, procedimientos, manuales, especificaciones técnicas, etc. 3.2.2 Nivel de detalle o profundidad de la CMDB Cuando se define el nivel del sistema, se crea una jerarquía de componentes y elementos. Se seleccionan los Cl’s principales o “padres” y se define el número de

niveles utilizados el detalle. El más nivelbajo másesalto estámás conformado por se la infraestructura TI enpara sí misma. El nivel el nivel detallado que debe controlar. Incorporar un CI a la CMDB solo resulta útil si su control y la información relacionada tienen algún beneficio para los procesos ITIL. Las siguientes consideraciones generales se aplican a la definición de la CMDB: 



A mayor cantidad de niveles, se debe manejar más cantidad de información. Esto incrementa la carga de trabajo y da como resultado una CMDB más grande, más compleja y más difícil de mantener. Cuánto menos niveles haya, menor control e información se tendrá sobre la infraestructura TI.

Si la CMDB no tiene muchos detalles, no se pueden monitorear los cambios de los componentes principales. En ese caso, ante cualquier cambio a los componentes de un CI padre se creará una variante del mismo. Por ejemplo, una PC disponible con dos tipos de disco duro aparecerá como una Variante A y una Variante B. Si hay demasiados cambios en los componentes hijos, será difícil y complejo mantener el número de variantes.


CIBERTEC


51

Figura 5.1 Alcance y Detalle de la CMDB

3.3 Identificación y atributos de CI´s 3.3.1 Identificación de CI´s El nombre de un CI debe ser único. Cada CI en la infraestructura controlada debe ser identificado y sólo podemos hacer esto, dando a cada CI un número único. Como su automóvil. Este automóvil es único en el mundo por una combinación de números en su matrícula y el estado/ país donde vive. El nombre debe ser lógico y sencillo. Sencillo porque ¿qué necesidad hay de hacerlo difícil? Personal TI y Clientes deben tener idea de cómo leer la identificación de un CI. Así que intente encontrar una identificación lo más lógica y sencilla como le sea posible: como A1234567 en vez de PC_BUILDA_LOKI.4_ 1234. A lo largo del ciclo vital de un CI, la primera identificación dada debe permanecer. Claro que la excepción confirma la regla. Así que esta es otra razón por la que no se debe implementar números como PC _BUILDA_LOKI.4_ 1234 debido a que se relaciona con el edificio donde se instaló. 3.3.2 Atributos de CI´s Los siguientes atributos (ver Tabla 5.1) son ejemplos que se pueden utilizar en la CMDB. Note que los tipos de CI de hardware tendrán distintos atributos de los tipos de CI de software.

CIBERTEC


52

Atributo Nombre de CI Número de Copia o de Serie

Descripción El único nombre por el que se conocerá este tipo de CI El número que identifica de forma única las instancias particulares de este CI, por ejemplo, el número de copia de software, para hardware el número de serie

Categoría

Clasificación de un CI (p.ej. hardware, software, documentación, etc.) Descripción del tipo de CI, ampliando la información de

Tipo

“categoría” (p.ej. configuración de hardware, paquete de

software, aparato de hardware o módulo de programa). Modelo de CI (correspondiente por ejemplo al número de modelo de proveedor (hardware) p.ej. Dell model xxx, PC/aa model yyy). Fecha de vencimiento de Fecha en la que vence la garantía del proveedor Garantía Número de modelo

Número de Versión Localidad

Propietario Responsable Fecha de Responsabilidad Fuente / Proveedor

El número de versión del CI. La localidad del CI, p.ej. la biblioteca o medio donde reside el software del CI, el sitio/cuarto donde se encuentra un servicio. El nombre y/o designación del propietario responsable del CI Fecha en la que el propietario arriba mencionado se hizo responsable del CI La fuente del CI, p.ej. desarrollado en la misma casa, importada de la empresa xxxx etc.

Licencia

Número de licencia o referencia al acuerdo de licencia

Fecha de Provisión Fecha de Aceptación/Instalación Estatus (Actual)

Fecha cuando el CI fue dado a la organización. Fecha en la que el CI fue aceptado por la organización como probado de modo satisfactorio.

Estatus (programado)

El próximo estatus programado del CI (con la fecha o indicación del evento que provocará el cambio de estatus). Un campo de comentario a ser utilizado para narrativa textual; por ejemplo, para proporcionar una descripción de cómo esta versión del CI es distinta de la versión anterior.

Comentario

El estatus actual del CI; p.ej. bajo “prueba”, “producción”, “archivado”.

Tabla 5.1 Atributos de CI´s


CIBERTEC


53

3.4 Relaciones en la CMDB Las relaciones entre CI´s son útiles para diagnosticar errores y predecir la disponibilidad de los servicios. Se pueden registrar muchas relaciones lógicas y físicas diferentes. 3.4.1 Relaciones físicas 

Forma parte de, esta la relación padre/hijo del CI, por ejemplo un disco duro

forma parte de una PC y un módulo de software forma parte de un programa.  

Está conectado a, por ejemplo una PC está conectada a un segmento LAN Es necesario para, por ejemplo el hardware es necesario para realizar una

aplicación 3.4.2 Relaciones lógicas  

Es copia de, copia de un modelo estándar, línea de referencia o programa. Se relaciona, un procedimiento, manuales y documentación, un SLA, o área

de cliente 

Es usado por, por ejemplo un CI necesario para brindar un servicio, o un

módulo de software que comparten cierto número de programas

3.5 Estados

de los CI’s

El ciclo de vida de un componente se puede dividir en muchas etapas, y se le puede asignar un código de estado a cada etapa. Esto depende de las características de la infraestructura TI que la organización quiera registrar. Llevar un registro de la fecha de cada cambio de estado puede ser una fuente de información muy útil sobre el ciclo de vida de un producto: fecha de orden, de instalación, y las necesidades de mantenimiento y soporte. El estado de un componente también puede determinar lo que se puede hacer con él. Por ejemplo, si se rastrea el estado de partes no operacionales, este hardware no puede cambiar de lugar sin previa consulta (podría ser parte de un plan de recuperación ante desastres). Un cambio en el estado de un CI puede ser producto de un cambio autorizado o sin autorización o de un Incidente. Se puede utilizar la siguiente clasificación de estado: 3.5.1 Nuevos CI´s   

En desarrollo/pedido valuado Aceptado

3.5.2 CI’s Existentes   



Recibido Solicitud de Cambio (RFC) abierta para la CI, nueva versión pedida El cambio ha sido aprobado y se ha considerado en el plan, se proveerá un nuevo CI y documentación (que también es un CI) Mantenimiento en progreso Fuera de servicio

CIBERTEC


54

3.5.3 CI´s Archivados    

 

Obsolet Borrado Eliminado Robado

Vendido o alquiler vencido En almacenamiento de archivo a la espera de donación, venta o destrucción Destruido

3.5.4 Todos los CI’s      

En stock El pedido ha sido recibido o la versión cambiada está disponible. A prueba Liberado para instalar Activo, el CI está en uso Provisión

3.6 Línea Base (Baseline) Una línea base de configuración es la configuración de un producto o sistema establecido en un momento concreto en el tiempo, que capta tanto la estructura como los detalles de una configuración. Es una referencia para más actividades. Una aplicación o línea de base de software proporciona la habilidad de cambiar o reconstruir una versión concreta en una fecha más adelante. Las líneas base de configuración se deben establecer mediante un acuerdo formal en momentos concretos del tiempo y se deben utilizar como puntos de referencia para el control formal de una configuración. Las líneas base de configuración y sus cambios aprobados constituyen la configuración actualmente aprobada. Ejemplo de línea base: un CI estándar particular que se necesita cuando se compran muchos artículos del mismo tipo (p.ej. PC de escritorio) a lo largo de un periodo pactado. Si unos servidores deben incluir teclados de circuito impreso adicionales, esto podría corresponder a una “línea base plus”. Si todas las PCs de escrit orios en el futuro tendrán estos teclados, se forma una nueva línea base. Varias líneas base correspondientes a distintas etapas en la vida de un “artículo de línea base” pueden existir en un momento dado, por ejemplo la línea base para una versión de software que ya está en “producción”, la versión que estuvo en “producción” anteriormente y que ahora se encuentra archivada, la próxima versión

que se instalará (salvo cambios bajo control de Gestión de Configuración) y una o más versiones bajo prueba. Además, si por ejemplo una nueva versión de software se está introduciendo gradualmente a nivel regional, más de una versión de línea base podría estar “en producción” a la vez.

3.7 Informes de gestión e indicadores de rendimiento  



Información sobre la calidad de los procesos. Cantidad de diferencias observadas entre los informes y la situación encontrada durante una auditoría (deltas). Cantidad de ocasiones en las que una configuración no tenía autorización.


CIBERTEC




  









55

Cantidad de ocasiones en las que no se pudo encontrar una configuración registrada. Diferencias a nivel de atributo descubiertas durante la auditoría. Tiempo necesario para procesar un pedido para registrar información. Lista de CI´s donde se registraron más de un cierto número de Incidentes o Cambios. Información estadísticasobre la estructura y composición de la infraestructura TI. Datos de crecimiento y otra información sobre los desarrollos en la infraestructura TI. Resúmenes, registros y propuestas para mejorar, como recomendaciones para cambios en el alcance y detalle de los CI´s rastreados por la Gestión de Configuraciones, debido a cambios del negocio, técnicos, de precio de mercado y otros. Lista de costos de personal cuando se implementa el proceso.

3.8 Factores críticos de éxito 









Recibir la información necesaria paramantener la base de datos al día. Esto significa que los vínculos con la Gestión de Cambios deben ser fuertes. Al introducir el proceso es esencial que la implementación se divida en etapas. Generalmente se producen fallos porque no se puede instaurar de una sola vez la disciplina requerida en la Gestión de Configuración. Los registros que se mantienen antes de introducir el proceso deben ser eliminados para evitar la duplicación. Cuando se introduce el proceso es importante promover algunas ventajas claras para la Gestión de Configuración (ganancias rápidas). Es importante que los elementos registrados del proceso sean entregados al personal que tenga las habilidades necesarias y la actitud correcta.

4. ROLES Y RESPONSABILIDADES 4.1 Gestor de Configuración  

 

  

Propuestas de cambio al alcance y nivel de detalle de la CMDB. Asegurar que los procesos de la Gestión de Configuración sean comunicados a toda la organización. Proveer personal y capacitación para los procesos. Desarrollar el sistema de identificación y la convención de nomenclatura. Evaluar los sistemas existentes e implementar nuevos. Definir, planificar e implementar la CMDB. Crear informes. Organizar auditorías de configuración.

CIBERTEC


56

Resumen



La componentes Gestión de Configuración la identificación, registro,constituyentes y reportes de los TI, incluyendocubre sus versiones, componentes y relaciones. Los elementos que deben estar bajo el control de la Gestión de Configuración comprenden hardware, software y documentación asociada.



Un Elemento de Configuración (CI) es unelemento de la infraestructura necesario para brindar un servicio: hardware, software, documentación, personal, etc.



La Base de Datos de Gestión de Configuración (CMDB) es un repositorio donde se almacenan todos los CIs junto con sus datos, trazabilidad y relaciones.






CIBERTEC


57


2 TEMA

6

GESTIÓN DE INCIDENTES LOGRO DE LA UNIDAD DE APRENDIZAJE Al término de la unidad, el alumno explicará las funciones del centro de servicios o service desk y los procesos que conforman el soporte del servicio de TI, identificando con precisión sus características, componentes, ventajas, recomendaciones de implementación y medición, así como la interrelación de dichos procesos.

TEMARIO    

Objetivos Actividades Descripción del Proceso Roles y Responsabilidades



CIBERTEC


58

1. OBJETIVOS 

 

Restablecer la operación normal del servicio tan pronto como sea posible. Minimizar el impacto adverso en las operaciones del negocio. Asegurar que los niveles de calidad y disponibilidad de los servicios se mantengan en lo establecido.

2. ACTIVIDADES 

Detección y registro del incidente. Clasificación y soporte inicial.

  

Investigación y diagnóstico. Resolución y recuperación. Cierre del incidente. Propiedad, monitoreo, seguimiento y comunicación.

3. DESCRIPCIÓN DEL PROCESO 3.1 Terminología 3.1.1 Incidente Un Incidente es cualquier evento que no es parte de la operación estándar de un servicio y que causa, o puede causar, una interrupción o una reducción de la calidad del servicio. 3.1.2 Workaround Un Workaround es un método de evitar un Incidente o un Problema, orientado a restablecer el servicio. Es una solución temporal que habitualmente reducirá el servicio. Redirigir trabajospuede de impresión otraimpresos impresora en el mismo edificio es un Workaround, el usuario obteneralos pero tendrá que caminar una distancia para obtenerlos. 3.1.3 Solicitud de Servicio Una Solicitud de Servicio (RFC) es cada evento que no es un fallo en la infraestructura TI, podría ser una solicitud de información o una solicitud de cambio relacionado con uno de los servicios que entrega la organización.

3.2 Entradas y Salidas 3.2.1 Entradas 







Detalles de Incidentes provenientesdel Service Desk, redes u operaciones de computadores. Detalles de configuración de la Base de Datos de Gestión de la Configuración (CMDB). Respuesta de emparejar Incidentes con Problemas y Errores Conocidos (KE). Detalles de resolución. Respuesta de RFC para resolución de Incidentes.


CIBERTEC


59

3.2.2 Salidas 

RFC para resolución de Incidentes; registro de Incidentes actualizado (incluyendo resolución o Workaround).



Incidentes resueltos y cerrados. Comunicación a los Clientes.



Información de gestión (reportes).



3.3 El Ciclo de Vida de un Incidente La Figura 5.1 ilustra las actividades durante el ciclo de vida de un Incidente.

Figura 6.1 Ciclo de V ida de un Incidente 3.3.1 Detección y Registro del Incidente El registro de datos de acuerdo a la interrupción o reducción del servicio es muy importante para:  

 

Localizar el Incidente a lo largo de la totalidad de su ciclo de vida. Añadir información útil que puedan ayudar, informar y asistir a los grupos de soporte para que puedan encontrar una solución o un Workaround. Recoger información histórica para uso futuro. Coleccionar información (p.ej. para reportes) sobre número de Incidentes, eficiencia, disponibilidad y análisis de tendencias y otros procesos de gestión.

CIBERTEC


60

3.3.2 Clasificación y Soporte Inicial El Service Desk determina la prioridad de los Incidentes a medida que los recibe. Consultando con el Cliente y de acuerdo a las disposiciones del SLA, el Service Desk determinará la prioridad a partir del impacto y la urgencia de los Incidentes. Consultar la CMDB es necesario para obtener información sobre el servicio que se interrumpe, los datos de los Acuerdos de Niveles de Servicio (SLA), los Elementos de Configuración (CI) relacionados a este servicio y los relacionados con Incidentes pasados y Errores Conocidos (KE). 3.3.3 Investigación y Diagnóstico Otros grupos de soporte empezarán a analizar el Incidente con el propósito de encontrar una solución permanente o un Workaround. 3.3.4 Resolución y Recuperación Después de haber completado el análisis y de haber resuelto el Incidente satisfactoriamente, se registra la solución en el sistema. Para algunas soluciones, se tendrá que emitir una Solicitud de Cambio (RFC) a la Gestión de Cambios. En el peor de los casos, si no se encuentra la solución, el Incidente permanece abierto. 3.3.5 Cierre del Incidente Una vez que se implementó una solución satisfactoria para el Usuario, el grupo de soporte direcciona el Incidente otra vez al Service Desk. Se contacta a la persona que informó sobre el Incidente para verificar que todo está resuelto. Si se confirma que el Incidente fue resuelto de manera correcta, se da por cerrado; pero si no es así se vuelve a comenzar desde el lugar adecuado. 3.3.6 Propiedad, Monitoreo, Seguimiento y Comunicación En muchos casos, el Service Desk, como dueño de todos los Incidentes, es responsable del monitoreo del progreso y debe informar al Usuario sobre el estado del Incidente. Durante el seguimiento y monitoreo pueden haber escalamientos.

3.4 Impacto, urgencia y prioridad 3.4.1 Impacto del Incidente Grado de desviación sobre las operaciones normales, en términos de números de Usuarios o de procesos del negocio afectados. 3.4.2 Urgencia La demora aceptable para el Usuario o el proceso del negocio. La prioridad se determina sobre la base de la urgencia y el impacto. Para Incidentes con la misma prioridad, el esfuerzo (personas, recursos, tiempo) que se deba poner en cada uno determinará el orden. El impacto y la urgencia se pueden combinar en una matriz como la de la Figura 5.2.


CIBERTEC


61

Figura 6.2 Ejemplo de un sistema de codificación de una prioridad

3.5 Primera, segunda y subsiguientes líneas de soporte Con frecuencia, los departamentos y grupos de soporte (especialistas), que no sea el Service Desk, son referidos como grupos de soporte de segunda o tercera línea, que tienen más habilidades especialistas, tiempo u otros recursos para resolver Incidentes. En este sentido, el Service Desk sería el soporte de primera línea. Se tiene el siguiente procedimiento tradicional para el escalamiento del Incidente en las diferentes líneas de soporte (ver Figura 5.3): 







1. Intento de resolución Incidente parte delo Service Desk. Llevar aPaso cabo la evaluación inicial del y buscar unaporsolución Workaround. Si se encuentra una solución, cerrar el Incidente. Si no, referirlo al siguiente nivel. Paso 2. Asignar el Incidente al soporte de segunda línea. Si no se puede encontrar ninguna solución en el Service Desk, referirlo al soporte de segunda línea. Si el soporte de segunda línea puede encontrar una solución, referir de nuevo al Service Desk que cerrará el Incidente. Si no, referirlo al siguiente nivel. Paso 3. Asignar el Incidente al soporte de tercera línea. Si no se puede encontrar ninguna solución en el soporte de segunda línea, referirlo al soporte de tercera línea. Si el soporte de tercera línea puede encontrar una solución, referir de nuevo al Service Desk que cerrará el Incidente. Si no, referirlo al siguiente nivel. Paso 4. Asignar el Incidente al especialista. Si no se puede encontrar ninguna solución en el soporte de tercera línea, referir a un especialista. Si el especialista puede encontrar una solución, referir de nuevo al Service Desk que cerrará el Incidente.

Si no está claro qué grupo de soporte debería investigar o resolver un Incidente relacionado con un Usuario, el Service Desk, como dueño de todos los Incidentes, debería coordinar el proceso de Gestión de Incidentes o referirlo al equipo de Gestión de Problemas.

CIBERTEC


62

Notar que el soporte de tercera o n-línea puede eventualmente incluir proveedores externos que pueden tener acceso directo a la herramienta de registro del Incidente (dependiendo de las normas de seguridad y aspectos técnicos).

Figura 6.3 Escalamiento del Incidente en líneas de soporte

3.6 Escalamiento 3.6.1 Escalamiento funcional (horizontal) Significa involucrar más personal especializado o privilegios de acceso (autoridad técnica) para solucionar el Incidente, pudiéndose exceder los límites del departamento.

3.6.2 Escalamiento jerárquico (vertical) Significa que se realiza un movimiento vertical (a niveles más altos) en la organización porque la autoridad (autoridad de la organización, poderes) o recursos necesarios para resolver el Incidente son insuficientes.

3.7 Informes de gestión El control del proceso se basa en los informes de los diferentes grupos designados. El Gestor de Incidentes es responsable de estos informes, de la elaboración de la lista de distribución y del calendario de informes. Los informes deben ser muy detallados y adaptados a las necesidades de los siguientes gestores:


CIBERTEC


63

3.7.1 Gestor de Incidentes   



Partes faltantes en el proceso Conflictos con los acuerdos Desarrollo de los procesos

Tendencias

3.7.2 Gestor del grupo de soporte 



Control dentro de cada departamento Progreso de resolución del proceso Ciclo horario del Incidente en los distintos grupos de

soporte 3.7.3 Gestor de los Niveles de Servicio  



Calidad de los servicios brindados Todos los informes necesarios para que Nivel de Servicios los informe a los Clientes Innformación para los Clientes que especifique si se han cumplido los acuerdos con respecto a Niveles de servicio dentro del proceso de Gestión de Incidentes

3.7.4 Gestores de otros procesos de Gestión de Servicios  





Número de Incidentes informados y registrados Número de Incidentes resueltos, subdivididos por la resolución de tiempo Estado de Incidentes sin resolver y el número de Incidentes sin solución

Incidentes por periodo, grupo de Cliente, grupo de soporte y resolución de acuerdo con el SLA Incidentes por categoría y prioridad, por grupo de soporte.

3.8 Factores críticos de éxito 







Una CMDB actualizada que ayude a estimar el impacto y la urgencia de los Incidentes. De manera alternativa, esta información se puede obtener de los Usuarios, pero la información no será tan completa, puede ser muy subjetiva y llevará más tiempo. Una Base de Conocimiento, por ejemplo una base de datos actual de Problemas y Errores Conocidos que describa cómo reconocer los Incidentes, y soluciones y Workarounds disponibles. Aquí también deben incluirse la base de datos de los proveedores. Un sistema bien automatizado para registrar, seguir y monitorear los Incidentes. Fuertes vínculos con la Gestión de Niveles de Servicio para garantizar adecuadas prioridades y apropiados tiempos de resolución.

3.9 Indicadores de rendimiento La evaluación de procesos de rendimiento necesita de parámetros claramente definidos y objetivos mensurables, a menudo llamados Indicadores de Rendimiento (PKI). Estos se informan con regularidad, por ejemplo todas las semanas, para elaborar datos para el historial que puedan utilizarse para identificar las tendencias. Ejemplos de tales parámetros incluyen:

CIBERTEC


64

    

 



Número total de Incidentes Tiempo de resolución promedio Tiempo de resolución promedio por prioridad Promedios resueltos dentro de los parámetros del SLA Porcentaje de Incidentes resueltos por la primera línea de soporte (sin direccionar) Coste de soporte promedio por Incidente Incidentes resueltos por estación de trabajo o por agente de Service Desk Incidentes resueltos sin visitar al Usuario Número de Incidentes (o porcentaje) con clasificación inicial incorrecta Número de Incidentes (o porcentaje) mal direccionados

4. ROLES Y RESPONSABILIDADES Los procesos abarcan la jerarquía de la organización. Por consiguiente es importante definir las responsabilidades asociadas con las actividades que tienen que realizarse en el proceso. Para ser flexibles, es aconsejable usar el concepto de roles; en muchas organizaciones los roles pueden ser combinados debido al tamaño pequeño de la organización o por razones de costos. Por ejemplo, muchas organizaciones combinan los roles de Gestión del Cambio y de Gestión de la Configuración. Una rol abarca un conjunto de responsabilidades, tareas y niveles de autorización.

4.1 Gestor de Incidentes En muchas organizaciones, el rol de Gestor de Incidentes es asignado al Supervisor del Service Desk. 





Conducir la eficiencia y la efectividad del proceso de la Gestión de Incidentes Producir información de gestión Gestionar el trabajo del personal de soporte de Incidentes (primera y segunda línea) Monitorear la efectividad de la Gestión de Incidentes y recomendar mejoras Desarrollar y mantener los sistemas de Gestión de Incidentes.

4.2 Personal de soporte para el manejo de Incidentes 4.2.1 Soporte de primera línea (Service Desk)  

  



Registro de Incidentes Encaminamiento de los requerimientos de servicio a grupos de soporte cuando los Incidentes no están cerrados Soporte inicial y clasificación Propiedad, monitoreo, seguimiento y comunicación Resolución y restablecimiento de los Incidentes no asignados al soporte de segunda línea Cierre de los Incidentes

4.2.2 Soporte de segunda línea Grupos de especialistas que pueden ser parte del Service Desk. 

Manejo de los requerimientos de servicio


CIBERTEC










CIBERTEC

65

Monitoreo de los detalles de los Incidentes, incluyendo los Elementos de Configuración (CI) Investigación de Incidentes y diagnóstico (incluyendo la resolución si es posible) Detección de posibles Problemas y el encargo a ellos de la gestión del problema, con tal de aumentar los registros de problemas La resolución y restablecimiento de los incidentes asignados


66

Resumen



La Gestión Incidentes pronto comode sea posible. busca restablecer la operación normal del servicio tan



Un Incidente es cualquier evento queno es parte de la operación estándar de un servicio y que causa, o puede causar, una interrupción o una reducción de la calidad del servicio.



Un Workaround es un método de evitar un Incidente o unProblema, orientado a restablecer el servicio. Es una solución temporal que habitualmente reducirá el servicio.






CIBERTEC


67


2 TEMA

7

GESTIÓN DE PROBLEMAS LOGRO DE LA UNIDAD DE APRENDIZAJE Al término de la unidad, el alumno explicará las funciones del centro de servicios o service desk y los procesos que conforman el soporte del servicio de TI, identificando con precisión sus características, componentes, ventajas, recomendaciones de implementación y medición, así como la interrelación de dichos procesos.

TEMARIO o

o

Objetivos Actividades



Descripción del Proceso



Roles y Responsabilidades



CIBERTEC


68

1. OBJETIVOS 

 

Minimizar el impacto adverso de Incidentes y Problemas en el negocio causados por errores en la infraestructura TI. Prevenir la recurrencia de Incidentes relacionados con estos errores. Encontrar la causa raíz de los Incidentes e iniciar las acciones para mejorar o corregir la situación.

2. ACTIVIDADES 2.1 Control de Problemas Esta función realizará análisis de tendencias, registrará problemas y realizará análisis de causas de raíz a fin de encontrar una solución permanente.

2.2 Control de Errores Conocidos Controla los Errores Conocidos (Known Errors-KE) y genera RFCs a Gestión de Cambios para eliminar los Errores Conocidos de la infraestructura. Mantiene las bases de datos de conocimiento de Errores Conocidos y Workarounds. Publica los Errores Conocidos para que Gestión de Incidentes pueda resolverlos si vuelven a ocurrir. Investiga si Problemas o Errores Conocidos están presentes en otras partes de la infraestructura controlada.

2.3 Prevención Proactiva Previene la introducción de nuevos Incidentes y Problemas.

2.4 Identificar Tendencias Esta función monitorea activamente los Incidentes y con el uso de métodos estadísticos intenta identificar tendencias para que se puedan reconocer Problemas. Las tendencias por sí solas habitualmente no son suficientes para identificar un Problema, es necesaria la destreza humana para determinar si la tendencia lleva a un Problema.

2.5 Información de Gestión Crea informes sobre la efectividad y el rendimiento de la Gestión de Problemas y proporciona esta información a la Dirección y otros procesos.

2.6 Revisión de Post Implementación (PIR ) Gestión de Problemas archiva las Solicitudes de Cambios (RFC). Sólo después de implementar un Cambio, puede determinar si el Cambio ha producido la reducción o la eliminación del Incidente. La Revisión de Post Implementación (PIR) comprueba si se da el caso.


CIBERTEC


69

3. DESCRIPCIÓN DEL PROCESO 3.1 Terminología 3.1.1 Problema Un Problema describe una situación no deseada, indicando la causa raíz desconocida de uno o más Incidentes existentes o potenciales. 3.1.2 Error Conocido Un Error Conocido es un problema del que se ha determinado la causa. El Error es eliminado mediante la implementación de un Cambio.

3.2 Entradas y Salidas 3.2.1 Entradas   

Detalles de Incidentes Detalles de configuración Workarounds efinidos

3.2.2 Salidas    



Errores Conocidos Solicitudes de Cambio Registro de Problemas actualizado, incluyendo soluciones o Workarounds Respuesta del emparejamiento de Incidentes con Problemas y Errores Conocidos Información de gestión

3.3 Control de Problemas Las actividades de Control de Problemas se pueden observar en la Figura 8.1. 3.3.1 Identificación y Registro 







Si hubo un Incidente con considerable impacto que se ha solucionado, lo más probable es que el Gestor de Problemas registre el inconveniente donde iniciará una investigación para encontrar la raíz del problema. Durante el análisis de tendencias se puede encontrar un número de Incidentes con síntomas similares. Si se descubre una fuente potencial de Problemas. Si un Incidente se cierra con el código “Workaround”.

3.3.2 Clasificación     

Qué CI’s están involucrados;

Cuáles son los Incidentes relacionados; Cuáles son los síntomas; Cuáles son las causas; Cuáles son las resoluciones/ Workaround; Cuáles son los Cambios relacionados a este CI;

CIBERTEC


70

  

 

Qué niveles de servicio están relacionados; Cuál es el peligro; Qué Clientes están implicados; Cuánto tiempo necesitamos (esperamos) para encontrar una solución (tanto de duración como de esfuerzo); Con cuánta urgencia necesitamos resolver el problema; Cuánto es el posible beneficio si solucionamos el problema (impacto); Basado en esta información se asigna Impacto y urgencia (=prioridad).

Figura 8.1 Control de Problemas 3.3.3 Asignar Recursos Después de la clasificación, se pueden priorizar los problemas más importantes con el impacto de negocio más alto. Basado en el número de recursos que se tienen, se pueden asignar o reasignar problemas a los recursos disponibles. 3.3.4 Investigación y Diagnóstico El objetivo de la investigación y diagnóstico es detectar la causa subyacente de uno o más Incidentes. Las actividades de investigación deberían incluir los Workarounds disponibles para los Incidentes relacionados con el Problema, los Cambios recientes y la información histórica de Cl’s de la CMDB.

3.3.5 Establecer el Error Conocido Después de la fase anterior, se determinará el Error Conocido. Esta fase registra que un Error es Conocido y pasa el Error al proceso de Control de Errores.


CIBERTEC


71

3.4 Control de Errores Las actividades de Control de Errores se pueden observar en la Figura 8.2.

Figura 8.2 Control de Errores 3.4.1 Identificación y Registro Un error se identifica cuando se detecta un CI roto. Un estado de Error Conocido se asigna cuando se encuentra la causa raíz de un Problema. 3.4.2 Evaluación Este paso realiza una evaluación inicial de los medios para resolver el Error, en colaboración con personal especialista. El proceso de resolución para cada Error Conocido debe ser grabado en el sistema de Gestión de Problemas. Es vital que los datos de los CI’s, síntomas y acciones de resoluci ón o Workaround relacionados con todos los Errores Conocidos se registren en la base de datos de Errores Conocidos para que estén disponibles para emparejamiento de Incidentes, proporcionando una guía para futuras investigaciones y para proporcionar información de gestión. 3.4.3 Registro de Resolución El paso registra una resolución de un Error y completa una RFC de acuerdo con los procedimientos de Gestión de Cambio. La prioridad de la RFC se determina por la urgencia e impacto del Error en el negocio. El identificador de la RFC debería incluirse en el registro del Error Conocido y viceversa a fin de mantener un rastro de auditoría completo, o se deben enlazar los dos registros. Las etapas finales de la resolución de un Error (análisis de impacto, evaluación detallada de la acción de resolución a llevar a cabo, modificación del CI con Error, y la prueba del Cambio) están bajo el control de Gestión de Cambio.

CIBERTEC


72

3.4.4 Cierre Tras implementar con éxito los Cambios (determinado por la Revisión Post Implementación) para resolver Errores, el Error Conocido relevante se cierra, junto a los expedientes de Incidentes o Problemas relacionados.

3.5 Incidentes versus Problemas Incidentes y Problemas (y Cambios) son entidades separadas. No es cierto que cuando hay un Problema, el Incidente que inició el Problema ha desaparecido. La Figura 8.3 muestra un modelo en el que Incidentes, Problemas e incluso Cambios estarán vivos simultáneamente.

Figura 8.3 Incidentes versus Problemas 3.5.1 Comienzo: Solo un Incidente Cuando ocurre un Incidente, el proceso de Gestión de Incidentes intentará resolverlo cuanto antes. El Incidente solo se puede cerrar una vez resuelto. Durante la fase de Investigación del Incidente no se encuentra ninguna solución. El proceso de Gestión de Incidentes entonces busca la ayuda de Gestión de Problemas porque la causa raíz de los Incidentes se tiene que determinar en primer lugar. 3.5.2 Investigación y Escalamiento: Incidente y Problema existen simultáneamente La Gestión de Problemas define un Problema con alta urgencia e inmediatamente asigna recursos. Esos recursos diagnostican el Problema y encuentran la causa raíz del Incidente subyacente. 3.5.3 Diagnóstico: Incidente, Problema y Error Conocido existen simultáneamente Definen un Error Conocido y tras averiguar cómo resolverlo emiten una RFC a Gestión de Cambio para resolver la situación.


CIBERTEC


73

3.5.4 Cambio en trámite: Incidente, Problema, Error Conocido y Cambio existen simultáneamente El Cambio se implementa con éxito. La Revisión Post Implementación muestra que el Cambio realmente ha eliminado el Error Conocido con éxito. La investigación muestra también que el Incidente se ha resuelto y el Problema, por lo tanto, se puede cerrar también. 3.5.5 Final: Incidente resuelto, Cambio, Problema y Error Conocido cerrados Si en algún momento durante la fase de diagnóstico el equipo de Problemas encuentra un Workaround, el Incidente se resolverá antes. Esto no significa que el Problema ya no exista. El único cambio en registro del Problema será que la urgencia caerá de urgente a no urgente. El proceso de Problemas decidirá si hay recursos suficientes libres en ese momento para realizar el diagnóstico del Problema o si esos recursos serán mejor utilizados en otro lugar. 3.6 Gestión de Problemas Proactiva Las actividades descritas hasta ahora en el Control de Errores y Problemas son principalmente reactivas. Las actividades de Gestión de Problemas Proactiva tratan de identificar y resolver Problemas y Errores Conocidos antes de que ocurran Incidentes, dicho de otro modo minimizan el impacto adverso en el servicio y los costos relacionados con el negocio. La prevención de Problemas va desde la prevención de Problemas individuales hasta decisiones estratégicas que requieran mayor gasto de implementación, tal como una inversión en una mejor red de conexión. Las actividades principales dentro de los procesos de Gestión de Problemas Proactivadeson el análisis de tendencias el marcar objetivos preventiva. TI, El análisis tendencias puede llevar a la yidentificación de fallosde enacción la infraestructura los cuales pueden ser analizados y corregidos como se describe en las secciones de Control de Errores y Problemas. El análisis de tendencias también puede llevar a la identificación de áreas de Problemas generales que necesitan más atención de soporte. Debería ser posible hacer comparaciones significativas al expresar esto en términos de costo financiero para la organización. Los informes de análisis de Problemas e Incidentes proporcionan información de medidas proactivas para mejorar la calidad de servicio. El objetivo es identificar los componentes “frágiles” de la infraestructura TI e investigar las razones para la fragilidad. En este contexto la “fragilidad” es proporcional al impacto al negocio si falla

el CI. La categorización de Incidentes y Problemas y el análisis de los mismos pueden revelar tendencias y llevar a la identificación de áreas de Problemas específicos (potenciales) que necesitan más investigación. Por ejemplo, el análisis puede indicar que los Incidentes relacionados con la utilidad de los sistemas cliente-servidor recientemente instalados sean el área de Problemas que tiene más crecimiento en términos de impacto negativo en el negocio.

3.7 Informes de gestión e indicadores de rendimiento El éxito de la Gestión de Problemas se demuestra a través de:

CIBERTEC


74



 

La reducción de la cantidad de Incidentes, resolviendo problemas. La reducción del tiempo necesario para resolver problemas. Disminución de otros costos asociados con la resolución.

Los informes de la Gestión de Problemas pueden cubrir los siguientes temas:    



Informe de tiempo Calidad del producto Eficacia de la Gestión de Problemas Relación entre la Gestión de Problemas reactiva y proactiva Calidad de los productos en desarrollo Estado y planes de acción para problemas abiertos Propuestas para mejorar la Gestión de Problemas

3.8 Factores críticos de éxito Eficacia en el registro automatizado de Incidentes y del registro del comportamiento de la infraestructura. Objetivos viables y hacer el mejor uso posible de la experiencia del personal, por ejemplo acordando sobre su disponibilidad a determinados horarios y reservando tiempo para investigar las causas principales de los Problemas. Es imprescindible contar con una cooperación eficaz entre la Gestión de Incidentes y la de Problemas. Al asignar las tareas y las actividades se debe estar al tanto del conflicto entre la Gestión de Incidentes y la identificación de las causas de la Gestión de Problemas.

4. ROLES Y RESPONSABILIDADES 4.1 Gestor de Problemas  

  



Desarrollar y mantener el Control de Problemas y Control de Errores Evaluar la eficiencia y la eficacia del Control de Problemas y Control de Errores Ofrecer información administrativa Gestionar el personal de la Gestión de Problemas Obtener los recursos para las actividades Desarrollar y mejorar los sistemas de Control de Problemas y Control de Errores Analizar y evaluar la eficacia de la Gestión de Problemas Proactiva

4.2 Personal para el manejo de Problemas 4.2.1 Responsabilidades reactivas 

 



Identificar y registrar los problemas analizando los detalles de los Incidentes Investigar los problemas basándose en su prioridad Elevar RFCs Realizar el seguimiento del progreso de la resolución de los Errores Conocidos Aconsejar a la Gestión de Incidentes sobre la existencia de soluciones temporales y de reparaciones rápidas


CIBERTEC


75

4.2.2 Responsabilidades proactivas Identificar las tendencias Elevar RFC’s

Prevenir que los Problemas no se extiendan a otros sistemas

CIBERTEC


76

Resumen



La Gestión de Problemas busca encontrar la causa raízde los Incidentes e iniciar las acciones para mejorar o corregir la situación.



Un Problema describe una situación no deseada, indicando la causa raíz desconocida de uno o más Incidentes existentes o potenciales.



Un Error Conocido es un problema del quese ha determinado la causa. El Error es eliminado mediante la implementación de un Cambio.






CIBERTEC


77


2 TEMA

8

GESTIÓN DE CAMBIOS LOGRO DE LA UNIDAD DE APRENDIZAJE Al término de la unidad, el alumno explicará las funciones del centro de servicios o service desk y los procesos que conforman el soporte del servicio de TI, identificando con precisión sus características, componentes, ventajas, recomendaciones de implementación y medición, así como la interrelación de dichos procesos.

TEMARIO Objetivos Actividades

Descripción del Proceso Roles y Responsabilidades



CIBERTEC


78

1. OBJETIVOS 

El objetivo del proceso de Gestión de Cambios es asegurar que se utilizan procedimientos y métodos estandarizados para el manejo eficiente y puntual de todos los Cambios, a fin de minimizar el impacto de éstos sobre la calidad de servicio y como consecuencia mejorar las operaciones cotidianas de la organización.

2. ACTIVIDADES La Gestión de Cambios es responsable de dirigir el proceso de Cambios. Este proceso no está a cargo de implementar Cambios, sólo controlará que se aprueben éstos y que se implementen de forma eficiente y efectiva en lo que se refiere a costos y con un mínimo riesgo para los servicios nuevos y existentes. Para evaluar el riesgo de cada Cambio es muy importante tener una idea de la Configuración que controlamos, por lo cual necesita de la Gestión de Configuración. La Gestión de Cambios también es responsable de alcanzar los Cambios que se van a programar. Solamente Cambios programados y adecuadamente sincronizados pueden ser controlados. Lo más importante es tener una percepción de los recursos que se requieren y que están disponibles. La comunicación es la clave en un proceso de Cambio exitoso. Una falta de comunicación es muy a menudo la razón para que los Cambios no se implementen bien y que ocurran Incidentes. El proceso de Gestión de Cambios posee las siguientes actividades:

2.1 Solicitud de Cambio Una RFC es el comienzo de un ciclo de la vida de un Cambio.

2.2 Registro y Clasificación Recoger la información necesaria para tomar decisiones sobre qué se ha de cambiar y cuál será la categoría y el impacto para que la autorización se pueda hacer correctamente. Se asigna una prioridad y categoría que se basan en el impacto del Cambio. La evaluación de riesgo es de una importancia crucial en este momento.

2.3 Monitorear y Programar Todos los cambios se programarán y un plan (con hitos) será proporcionado si es necesario para el control óptimo de los Cambios.

2.4 Aprobar Decidir si el Cambio se va a manejar o no.

2.5 Construir y Probar Las RFCs autorizadas deberán ser pasadas a los grupos técnicos relevantes para la construcción de Cambios. La Gestión de Cambios tiene un rol de coordinación, apoyado por la Gestión de Versiones y la Dirección para asegurar que las actividades tengan recursos y se completen de acuerdo con el programa. Para prevenir que los


CIBERTEC


79

Cambios impacten en la calidad de servicio, se recomienda que los Cambios se prueben rigurosamente por adelantado (incluidos procedimientos de retroceso, vuelta atrás o backout).

2.6 Autorizar Implementación Después de una prueba adecuada y la comprobación de que todo lo necesario se ha llevado a cabo, se puede autorizar la implementación del Cambio.

2.7 Implementación La Gestión de Cambios tiene la responsabilidad de asegurar que los Cambios se implementen ya según aunque esto en gran medida un rol(p.ej. de coordinación que programa, la implementación será será la responsabilidad de otros ingenieros llevando a cabo Cambios de hardware).

2.8 Evaluar La Gestión de Cambios debe evaluar todos los Cambios implementados después de haber transcurrido un periodo predefinido. Esto se puede hacer con la Revisión de Post Implementación. Este proceso puede involucrar miembros del Comité de Asesoramiento de Cambios (CAB).

3. DESCRIPCIÓN DEL PROCESO 3.1 Terminología 3.1.1 Cambio Adición, modificación, eliminación o retorno a la línea base aprobado de cualquier CI. 3.1.2 Solicitud de Cambio (RFC) Formulario usado para registrar los detalles de un requerimiento de Cambio. 3.1.3 Programa Adelantado de Cambios (FSC) Programa que contiene los detalles de todos los Cambios aprobados para implementar y sus fechas propuestas de implementación. 3.1.4 CAB 

Comité de Asesoramiento de Cambios o Change Advisory Board.

3.1.5 CAB/EC 

Comité de Emergencia del CAB.

3.2 Inputs y Outputs 3.2.1 Inputs 



RFCs CMDB

CIBERTEC


80

FSC 3.2.2 Outputs FSC RFCs

Acciones y minutas del CAB Informes de gestión

3.3 Solicitud de Cambio (RFC) Las Solicitudes de Cambio son el comienzo del ciclo de vida del Cambio y pueden referirse a cualquier parte de la infraestructura, servicio o actividad. Todas las RFCs se deben registrar y contar con un número de identificación. Los siguientes elementos se pueden incluir en el formulario de la RFC: 



El número de RFC (más la referencia al número de informe de Problema, de ser necesario) Descripción e identidad de los elementos a cambiar (incluidas las identificaciones de los CI’s )

 



  













  

Razón para el Cambio Efecto de no implementar el Cambio Versión del CI a ser cambiado

Nombre, localización y número de teléfono de la persona que propone el Cambio Fecha en la que se propuso el Cambio Prioridad del Cambio Evaluación del impacto y recursos (que pueden estar en formularios separados de ser necesario) Recomendaciones del CAB en caso de ser apropiado (que se pueden tener por separado, con impactos y recursos donde sea conveniente) Firma de autorización (podría ser electrónica) Fecha y hora de autorización Implementación programada (identificación, fecha y hora) Localización del plan de implementación Detalles del constructor / responsable de implementar el Cambio Plan de retroceso o marcha atrás Fecha y hora de la implementación real Fecha de revisión Resultados de la revisión (incluida la contra referencia a la nueva RFC de ser necesario) Gestión y evaluación de riesgo Impacto en la continuidad del negocio y planes de contingencia Estado de “dormida”

la

RFC:

“registrada”,

“evaluada”,

‘rechazada”,

‘aceptada”,

A medida que el Cambio transcurra por su ciclo de vida, la RFC debe ser actualizada para queutilizados la persona que inicióincurridos el Cambio esté alregistrar tanto decomo su estado. recursos actuales y los costos se deben parte deLos la RFC.


CIBERTEC


81

3.4 Determinación de la prioridad Una vez aceptada la RFC, se indica la prioridad y la categoría de la misma. La prioridad indica la importancia del Cambio y se dirige por el impacto y la urgencia. El código de prioridad ya puede estar atribuido por la Gestión de Problemas, pero los códigos definitivos están determinados por la Gestión de Cambios, considerando cualquier RFC pendiente de discusión. A continuación se presenta un ejemplo de códigos de prioridad: 







Prioridad 0, la prioridad más alta: La RFC trata de un Problema, lo que causa una inmensa molestia en el uso de servicios esenciales, o concierne un ajuste urgente de ejemplo una pequeña nueva funcionalidad a causa Los de consideraciones de TIla (por compañía o una ley de emergencia). Cambios en esta prioridad caen bajo la categoría de “Cambios Urgentes”. Los Cambios Urgentes se difieren de los procedimientos normales porque los recursos necesarios necesitan estar disponibles inmediatamente. Una reunión de emergencia del CAB o el comité dirigente de TI puede ser necesaria. Prioridad 1, alta prioridad: Causa problemas técnicos severos para un gran número de usuarios o concierne otras situaciones urgentes. Este Cambio obtiene la prioridad más alta en la próxima reunión programada del CAB. Prioridad 2, prioridad normal: No representa una emergencia o alto impacto pero el Cambio no se puede posponer. Este Cambio dentro del CAB recibe prioridad normal con la atribución de recursos. Prioridad 3, baja prioridad: Un Cambio es deseado pero podría esperar hasta un momento más conveniente (por ejemplo la próxima implementación o mantenimiento programado).

3.5 Determinación de la categoría Las categorías las atribuye el Gestor de Cambios, cuando es necesario en deliberación con el CAB, e indican el impacto del Cambio y la demanda de recursos que tiene para la organización TI. A continuación se presenta un ejemplo de categorías: 





Categoría 1, pocas consecuencias: Un Cambio que no conlleva mucho trabajo. El Gestor de Cambios puede aprobar este tipo de Cambios sin consultar con el CAB. Categoría 2, consecuencias sustanciales: Cambios que requieren esfuerzos mayores y que tienen mayor impacto en los servicios. Tales Cambios se discuten en la próxima reunión del CAB para predecir los esfuerzos necesarios y posibles consecuencias. Antes de la reunión, la documentación necesaria será enviada a los miembros del CAB y potencialmente a varios especialistas y encargados de desarrollo. Categoría 3, consecuencias inmensas: Un Cambio que requiere una gran cantidad de esfuerzo. El Director de Cambios necesita obtener autorización de la Dirección TI o un Comité Dirigente TI y luego debe discutirlo con el CAB.

3.6 Comité de Asesoramiento de Cambios (CAB) El CAB existe para aprobar la mayoría de los Cambios y para asistir a la Gestión de Cambios en la evaluación y priorización de Cambios. Siempre y cuando se convoque al CAB, los miembros elegidos deben ser capaces de evaluar adecuadamente desde CIBERTEC


82

un punto de vista tanto técnico como de negocio. Para alcanzar esta combinación, el CAB necesita incluir personas con un entendimiento claro de las necesidades de negocio del Cliente y de la comunidad Usuaria, además de las funciones de desarrollo técnico y de soporte. Los miembros del CAB podrían ser el Gestor de Cambios, Cliente(s), Director(es) de Usuarios, representante(s) del grupo de Usuarios, encargados de desarrollo /mantenimiento de aplicaciones, consultores técnicos, expertos, personal de servicio (según la necesidad), personal de servicios de oficina (donde los Cambios puedan afectar las instalaciones), contratantes y representantes de terceros según demanda, por ejemplo en contratar a terceros (outsourcing). Es importante enfatizar que el CAB:  

  

Estará compuesto de acuerdo con los Cambios considerados Puede variar considerablemente en su composición incluso a lo largo de una sola reunión Debería involucrar a proveedores cuando sea de utilidad Debería reflejar los puntos de vista tanto del Cliente como del usuario Es probable que incluya al Gestor de Problemas y el Gestor de Nivel de Servicio y personal de Atención al Cliente según la situación y en función del tiempo

Cuando surjan Problemas mayores, puede que no haya tiempo de crear el CAB entero, y por lo tanto es necesario identificar una organización más pequeña con autoridad para tomar decisiones de urgencia, la cual se conoce como elComité de Emergencia del CAB (CAB/EC). Los procedimientos de Cambio deben especificar cómo el formato del CAB y CAB/EC se determinará en cada instancia. La composición del CAB/EC proporcionará la habilidad, tanto desde el punto de vista del negocio como técnico, de tomar decisiones en cualquier eventualidad concebible.

3.7 Relaciones con otros procesos La Gestión de Cambios y de Configuración están muy relacionados. El proceso de Verificación de la Gestión de Configuración se puede usar para controlar la efectividad de la Gestión de Cambios. Si, tras la verificación, el Gestor de Configuración ha encontrado CI’s que no están en la base de datos hay dos opcione s: 



La base de datos no está actualizada, que puede indicar que no se informó a la Gestión de Configuración del Cambio. Alguien ha ejecutado un Cambio ilegal no aprobado.

El campo más importante donde se relacionan los procesos es en el análisis de impacto y riesgo de un Cambio (ver Figura 9.1). La mayor parte de esto se tiene que hacer con la ayuda de la CMDB. El envío de una RFC implica averiguar: 



Qué CI o Cl’s se tienen que cambiar y cuál es el impacto en la infraestructura

existente. Si esta RFC resultará en más RFCs por el hecho de tener que cambiar más Cl’s como resultado de esta solicitud.



Si el Cambio sólo afecta a uno o más usuarios, una o más áreas o uno o más servicios a fin de asignar el código correcto de impacto a este Cambio.


CIBERTEC


83

Basado en todo esto, se puede decidir si el CAB es necesario, a quién se tiene que invitar, en qué nivel se tiene que discutir y aprobar el Cambio y poder generar la lista de actividades más completa.

Figura 9.1 Relaciones con otros procesos 3.8 Informes de gestión e indicadores de rendimiento

Considere los datos y estadísticas a continuación en los informes de Gestión de Cambios y como indicadores de rendimiento: 



 





  

El número de Cambios implementados enel periodo, en total y por CI, tipo de configuración, servicio, etc. Un desglose razonesllamadas para el Cambio (solicitudes de Usuarios, mejoras, requisitos delde negocio, de servicio, Incidentes, Problemas, mejoras de procedimientos, etc.). El número de Cambios con éxito. El número de Cambios retrocedidos, junto a las razones (p.ej. evaluación incorrecta, mala construcción). El número de Incidentes que llevan a Cambios (desglosados por niveles de severidad de Problemas) y las razones (p.ej. evaluación incorrecta, mala construcción). El número de RFCs (y tendencias en proceso de srcinarse). El número de Cambios implementados revisados.

Cifras de periodos anteriores. El número de RFCs rechazadas. La proporción de Cambios implementados que no tienen éxito (en total y desglosado por CI’s)



Atrasos de Cambios, desglosados por CI y por etapa en el proceso de Gestión de Cambios.

CIBERTEC


84

4. ROLES Y RESPONSABILIDADES 4.1 Gestor de Cambios 









 





 

 

Recibir, registrar y asignar una prioridad, en colaboración con el solicitante, de todas las RFCs. Rechazar cualquier RFC que no sea completamente práctica. Presentar todas las RFCs para una reunión del CAB, publicar una agenda y hacer circular todas las RFCs a los miembros del CAB antes de las reuniones para permitir consideraciones previas. Decidir qué personas irán a qué reuniones, dependiendo de la naturaleza de la RFC. Convocar CAB urgentes o reuniones CAB/EC para todas las RFCs urgentes. Presidir todas las reuniones CAB y CAB/EC. Después de la consideración del consejo dado por CAB o CAB/EC, autorizar cambios aceptables. Publicar FSCs, via Service Desk. Comunicar con todos los grupos para coordinar la construcción de Cambios, prueba e implementación, de acuerdo con los programas. Actualizar el registro de Cambios con todos los avances que ocurran, incluyendo cualquier acción para corregir Problemas y/o aprovechar para mejorar la calidad del servicio. Revisar todos los Cambios implementados para asegurar que hayan conseguido los objetivos completamente. Remitir de vuelta cualquiera que haya retrocedido o haya fallado. Revisar todas las RFCs importantes que esperan consideración o acción. Analizar los registros de Cambios para determinar cualquier tendencia o Problema aparente que ocurra. Buscar rectificaciones con los grupos relevantes. Cerrar RFCs. Producir informes de gestión regulares y exactos.


CIBERTEC


85

Resumen



Un Cambio es una adición, modificación, eliminación o retorno a la línea base aprobado de cualquier CI.



Una Solicitud de Cambio (RFC) es un formulario usado pararegistrar los detalles de un requerimiento de Cambio.



El CAB es el Comité de Asesoramiento de Cambios o Change Advisory Board que aprueba la mayoría de los Cambios y asiste a la Gestión de Cambios en la evaluación y priorización de éstos.





CIBERTEC


86


CIBERTEC


87


3 TEMA

9

GESTIÓN DE VERSIONES LOGRO DE LA UNIDAD DE APRENDIZAJE Al término de la unidad, el alumno explicará las funciones del centro de servicios o service desk y los procesos que conforman el soporte del servicio de TI, identificando con precisión sus características, componentes, ventajas, recomendaciones de implementación y medición, así como la interrelación de dichos procesos.

TEMARIO Objetivos Actividades




CIBERTEC


88

1. OBJETIVOS  













Planificar y supervisar el despliegue de software y hardware. Diseñar e implementar procedimientos eficientes para la distribución e instalación de Cambios en los sistemas TI. Asegurar que el hardware y el software que se cambia se puedan localizar, sean seguros y que solo se instalen versiones correctas, autorizadas y probadas. Comunicar y gestionar las expectativas del Cliente durante la planificación y despliegue de nuevas Versiones. Acordar el contenido exacto y plan de despliegue de la Versión con la Gestión de Cambios. Implementar nuevas Versiones de software y hardware en el ambiente operativo usando los procesos de control de Gestión de Configuración y Gestión de Cambios. Una Versión debe estar bajo la Gestión de Cambios y puede consistir de cualquier combinación de hardware, software, firmware y documentos CI. Asegurar que las copias maestras de todo el software están seguras en la Biblioteca de Software Definitiva (DSL) y que la Base de Datos de Gestión de Configuración (CMDB) esté actualizada. Asegurar que todo el hardware desplegado o cambiado está seguro y puede ser localizado, usando los servicios de Gestión de Configuración.

2. ACTIVIDADES Las actividades de la Gestión de Versiones son:    



 

  

Política y planificación de las Versiones Diseño, construcción y configuración de las Versiones Aceptación de las Versiones Planificación del despliegue Extensas pruebas de los criterios de aceptación predefinidos Visto bueno de la Versión a implementar Comunicación, preparación y capacitación Auditorías de hardware y software antes y después de la implementación de Cambios Instalación de hardware nuevo o actualizado Almacenamiento de software controlado en sistemas centralizados y distribuidos Despliegue, distribución e instalación de software


CIBERTEC


89

Figura 10.1 Principales actividades en la Gestión de Versiones

3. DESCRIPCIÓN DEL PROCESO 3.1 Proceso de despliegue de software 



El proceso comienza con la adquisición del software o con la asignación del desarrollo del software. Cuando se entrega el software se realizará una comprobación de calidad.



En la comprobación de calidad, adoptasi en la DSL. Se examina por ejemplo si este realmente es el software software se pedido, nuevas versiones se han desarrollado de la fuente correcta, si todos los ajustes han sido autorizados por Gestión de Cambios y si todos los CI’s están registrados en la CMDB. 



Una vez aceptado el software, se hace un backup de la DSL, después del cual el software será aceptado en la DSL. Estos backups deben ocurrir frecuentemente para que, en caso de un desastre, la última Versión correcta pueda ser cargada con rapidez. La compilación y sincronización de cada Versión son decididas por adelantado por la Gestión de Cambio, un “Registro de Versión” se hace en la CMDB y







todos los detalles se registran. Cuando todos los componentes del software están preparados, el paquete se envía a un área de prueba donde todos los tests obligatorios se puedan ejecutar. Cuando se encuentran demasiados errores, el software se devuelve para más desarrollo. Cuando se aprueba el software, la Versión será distribuida y llevada a producción.

CIBERTEC


90

Las copias del software se pueden distribuir desde la DSL hacia los otros ambientes que corresponda: 







Ambiente de Desarrollo: El desarrollo de una nueva Versión se puede srcinar de una Versión anterior de la DSL. El número de Versión se incrementa con cada nueva Versión. El software solo se puede cambiar en el ambiente de desarrollo. Ambiente de Pruebas: Es el ambiente para probar las versiones. A menudo se divide en pruebas técnicas que hacen los desarrolladores, pruebas funcionales realizadas por usuarios, pruebas de implementación hecha por desarrolladores de Versión, y posiblemente una prueba de aceptación final entre los usuarios y la organización administrativa. Ambiente de Explotación: El ambiente real (en vivo) donde se ponen a disposición del usuario los sistemas de información. Archivos: Aquí se guardan las Versiones srcinales (anteriores) de software que ya no están en uso.

3.2 Biblioteca de Software Definitiva (DSL) La Biblioteca de Software Definitiva (DSL) es un conjunto de CI’s de software y documentación en un lugar seguro. Físicamente, la DSL puede ser una colección de medios electrónicos en distintos formatos de software, archivos y documentación electrónica. La DSL es una biblioteca lógica y representa una sola entidad de software almacenada, la cual físicamente puede tener muchas copias almacenadas en distintos lugares. Cada CI de software autorizado se almacena (físicamente) en la DSL. En la DSL, se guardan todas las Versiones srcinales de software que han sido distribuidas al ambiente de producción.

3.3 Almacén de Hardware Definitivo (DHS) Se debe apartar un área para el almacenaje seguro de repuestos de hardware. Estos son componentes y piezas que se mantienen en el mismo nivel que sus contrapartes en el ambiente de producción. Detalles de estos componentes y sus respectivos contenidos y estructuras se deben registrar exhaustivamente en la CMDB. Estos se pueden utilizar entonces de manera controlada cuando se necesiten sistemas adicionales o en la recuperación de Incidentes mayores. Una vez que su uso (temporal) haya terminado, deben ser devueltos al DHS o se deben obtener sus remplazos.

3.4 Política de Versiones El Gestor de Versiones debe fijar una Política de Versiones en la que se decide cómo y cuándo se configuran y despliegan las actualizaciones del software. Esto implica especificar a qué nivel se pueden distribuir unos CI´s independientemente de otros (unidades de Versión), lo cual depende de: 

La cantidad de trabajo que el ajuste de un componente del programa cause a otros componentes del programa (incluido el software del sistema).


CIBERTEC








91

La cantidad de horas/hombre para construir y probar los Cambios por separado comparándolo con el esfuerzo asociado para juntarlos e implementarlos simultáneamente. El grado de dificultad de la instalación con los usuarios. Puede ser más fácil instalar un programa completo porque se dispone de los mecanismos estándar para ello. La complejidad de las dependencias entre el software, hardware nuevo y el resto de la infraestructura TI; cuánto más fácil es separar el hardware del software, más fácil es probarlo.

Es de gran importancia evaluar el número de ajustes que se pueden probar todos juntos en un cierto tiempo, una Versión Empaquetada (agrupación de Cambios diferentes en un solo despliegue) puede ser tan compleja que nunca pase a la fase de prueba. Como resultado del rápido desarrollo del nuevo software, la nueva Versión puede que ya no esté actualizada para cuando sea desplegada. Por otro lado, una gran cantidad de ajustes puede resultar en grandes molestias para el servicio.

3.5 Tipos de Versiones Según el nivel de Versión, las Versiones a menudo se dividen en: 





Versiones mayores: Despliegue importante de hardware y software, generalmente derivado de modificaciones sustanciales en las funcionalidades. Estas versiones suelen eliminar gran cantidad de Errores Conocidos, incluyendo soluciones temporales y soluciones rápidas. Versiones menores: Por lo general incluyen mejoras menores y soluciones a Errores Conocidos. Algunas de estas correcciones pueden haber sido implementadas anteriormente como reparaciones de emergencia (hotfixes), pero ahora quedan incluidas dentro de la Versión. Reparaciones de emergencia: Normalmente implementado como una reparación rápida para un Problema o Error Conocido.

Según el número de Cambios (ver Figura 10.2), se pueden seleccionar algunas de las siguientes opciones: 



Versión Delta: Una versión Delta solo incluye hardware y software cambiado. Esto por lo general se relaciona con una reparación de emergencia o una reparación rápida. La desventaja de este tipo de Versiones es que no siempre es posible probar todos los vínculos con el resto del ambiente TI, y que los módulos que ya no usa el software no se borran. Una Versión Delta resulta apropiada en caso de que se pueda separar el software del resto del ambiente TI. La ventaja de una Versión Delta es que da menos trabajo establecer el ambiente de prueba. Versión Completa: Una Versión Completa significa que el programa se distribuye incluyendo los está módulos cambiados. Estaenvíadetalle es muy aconsejable cuando no claroque quénosefueron cambió. Se probará el hardware y el software y habrá menos Incidentes después de la implementación. Cuando se prepara una Versión Completa resulta más fácil evaluar si se alcanzarán los criterios de rendimiento esperados. La ventaja de una Versión Total es que se pueden implementar simultáneamente varios

CIBERTEC


92

Cambios. Sin embargo, una Versión Total requiere de una mayor preparación y mayor cantidad de recursos que una Versión Delta. 

Paquete de Versiones: Un paquete de Versiones es un conjunto de Versiones (ya sean mayores o menores) agrupadas en un único paquete. Hace énfasis en largos períodos de estabilidad para los Usuarios. El arreglo de errores menores de software y la incorporación de nuevas funcionalidades son actividades que se pueden combinar. Las actualizaciones programadas de software de terceras partes como el software del sistema y las aplicaciones de ofimática son las que por lo general se tratan con el Paquete de Versiones.

Figura 10.2 Tipos de Versiones

3.6 Informes de gestión 











 

Versiones construidas e implementadas según programa, y dentro de los recursos presupuestados Un número muy bajo (de forma ideal ninguna) de Incidencias de Versiones que se han tenido que retroceder debido a errores inaceptables Baja incidencia de fallas de construcción Gestión segura y precisa de la DSL

Ninguna evidencia de software en la DSL que no ha pasado las comprobaciones de calidad y ninguna evidencia de retrabajos en cualquier software extraído de la DSL Tamaño de la DSL de acuerdo con la demanda de espacio y mantenimiento preciso y puntual de la las DSLrestricciones legales relacionadas con el software Cumplimiento de todas comprado Distribución precisa de las Versiones a lugares remotos Implementación puntual de Versiones a todos los lugares, incluidos los remotos


CIBERTEC




 









 

93

Ninguna evidencia de retroceso no autorizado a Versiones anteriores en ninguna ubicación Ninguna evidencia del uso de software no autorizado en ninguna ubicación Ninguna evidencia del pago de multas de licencia o esfuerzo de mantenimiento malgastado, por software que no está actualmente en uso en ninguna ubicación Ninguna evidencia de duplicación malgastada en la construcción de Versiones (p.ej. construcciones múltiples de ubicaciones remotas, cuando copias de una sola construcción serían suficiente) Registro puntual y preciso de toda actividad de construcción, distribución e implementación dentro de la CMDB La composición programada de Difusiones de acuerdo con la composición actual Recursos TI y humanos requeridos por la Gestión de Versiones de acuerdo a lo planeado El número de Versiones mayores y menores por período de informe El número de Problemas en el ambiente de producción que se pueden atribuir a nuevas Versiones, lo cual solo necesita ser medido durante los primeros meses de vida de una nueva Versión, clasificados por su causa de raíz (p.ej. “Versión errónea de archivo”, o “archivos faltantes”)





El número de objetos nuevos, cambiados o eliminados introducidos por la nueva Versión- p.ej. cuántos módulos y programas El número de Versiones completadasen el tiempo acordado

4. ROLES Y RESPONSABILIDADES 4.1 Gestor de Versiones 













Planear y supervisar la evolución satisfactoria del software y el hardware relacionado. Diseñar e implementar eficientemente procedimientos para la distribución e instalación de Cambios para los sistemas TI. Asegurar que el hardware y el software que están siendo cambiados puedan ser controlados, son seguros y que sólo sean instaladas versiones correctas y autorizadas. Comunicar y gestionar las expectativas del Cliente durante la planificación y presentación de nuevas Versiones. Aprobar el contenido exacto y plan de presentación para el despliegue, con la colaboración de Gestión de Cambios. Implementar nuevas Versiones de software y hardware en el ambiente operativo usando los procesos de Gestión de la Configuración y Gestión de Cambios. Asegurar que las copias maestras de todo el software están seguras en la DSL y que la CMDB está actualizada.

CIBERTEC


94

Resumen

 La Biblioteca de Software Definitiva (DSL) es un conjunto de CI’s de software y

documentación en un lugar seguro. Físicamente, la DSL puede ser una colección de medios electrónicos en distintos formatos de software, archivos y documentación electrónica. 

El Almacén de Hardware Definitivo (DHS) es un área para el almacenaje seguro de repuestos de hardware. Estos son componentes y piezas que se mantienen en el mismo nivel que sus contrapartes en el ambiente de producción.



Tipos de Versiones: mayores, menores, de emergencia, delta, completa y paquete de Versiones.






CIBERTEC


95


3 TEMA

10

GESTIÓN DE LA CAPACIDAD LOGRO DE LA UNIDAD DE APRENDIZAJE Al término de la unidad, el alumno explicará las funciones de los procesos que conforman la entrega del servicio de TI, identificando con precisión sus características, componentes, ventajas, recomendaciones de implementación y medición, así como la interrelación de dichos procesos.

TEMARIO Objetivos Alcance




CIBERTEC


96

1. OBJETIVOS La Gestión de la Capacidad es responsable de asegurar que la Capacidad de la infraestructura TI esté alineada con las demandas de la empresa de la manera más efectiva en costo y tiempo. El proceso abarca: 









El monitoreo del rendimiento de los Servicios TI y los componentes de soporte de la infraestructura Encargarse de las actividades de ajuste para utilizar los recursos existentes de la manera más eficiente Entender las demandas actuales de recursos TI y realizar pronósticos de requerimientos futuros Influir en la demanda de recursos, puede ser en coordinación con la Gestión Financiera La producción de un Plan de Capacidad (CapacityPlan) que permita proporcionar servicios TI de la calidad definida en los Acuerdos de Nivel del Servicio (SLAs)

La Gestión de la Capacidad equilibra: 



Costos con Capacidad: Por ejemplo, la necesidad de asegurar que la Capacidad de procesamiento que se compra no solo es justificable económicamente en términos de la necesidad del negocio, sino también la necesidad de usar de la manera más eficiente dichos recursos. Suministro con demanda: Por ejemplo, asegurarnos que el suministro disponible de potencia de procesamiento está alineado con las demandas del negocio, ahora y en el futuro. Puede también ser necesario gestionar o influir en la demanda de un recurso particular.

2. ALCANCE El proceso de la Gestión de la Capacidad debe ser el centro de coordinación de todos los temas de Capacidad y rendimiento de TI. Otras áreas técnicas, como el Soporte de Red, puede llevar a cabo la mayor parte de las obligaciones cotidianas relevantes, pero la responsabilidad total recae en el proceso de Gestión de la Capacidad. Tanto para el ambiente de producción como el de desarrollo, el proceso debe abarcar: 

 



Todo el hardware (PCs, servidores, mainframes y supercomputadoras) Todo el equipamiento de red (LANs, WANs, routers, etc.)

Todos los periféricos (dispositivos de almacenamiento, impresoras, etc.) Todo el software (sistemas operativos y software de red, desarrollos internos y paquetes comprados) Recursos humanos, pero solamente donde la falta de recursos humanos podría resultar en un retraso del tiempo de respuesta del servicio.

Sin embargo, el motor de la Gestión de Capacidad debe ser los requerimientos del negocio. La Figura 11.1 muestra que la Gestión de la Capacidad tiene una relación bidireccional con los procesos de estrategia y planificación del negocio. Normalmente la estrategia a largo plazo está contenida en los planes de negocio actualizados. Los planes de negocio se desarrollan en base al entendimiento de la organización sobre factores externos como el mercado competitivo, el panorama económico y la legislación, y su capacidad interna en términos de recursos humanos, capacidad de entrega, etc.


CIBERTEC


97

La Gestión de la Capacidad necesita entender la estrategia del negocio a largo plazo para proveer información sobre las últimas ideas, tendencias y tecnologías que han sido desarrolladas por los proveedores del hardware y del software. Los planes de negocio de la organización dictan la estrategia y los planes de negocio específicos de TI/SI, los cuales deben contar con la participación y conocimiento de la Gestión de la Capacidad. En los planes de negocio específicos de TI/SI se identifican las tecnologías, el hardware y el software y sus tiempos de implementación.

Figura 11.1 Gestión de la C apacidad y el negocio

3. DESCRIPCIÓN DEL PROCESO 3.1 Entradas y Salidas 3.1.1 Entradas  



Tecnología Acuerdos de Niveles de Servicio (SLAs), Requisitos de Niveles de Servicio (SLRs) y Catálogo de Servicios Planes y estrategia del negocio Planes y estrategia de TI/SI



Requisitos y volumen del negocio Calendarios de operaciones



Planes y programas de desarrollo y despliegue FSC

CIBERTEC


98





Incidentes y Problemas Revisiones del servicio Incumplimientos de SLA Planes financieros Presupuestos

3.1.2 Salidas  

 

  

Plan de Capacidad (Capacity Plan) Base de Datos de Capacidad (Capacity Data Base – CDB) Líneas de base y perfiles Umbrales (thresholds) y alarmas Informes de Capacidad (regulares, ad hoc y excepcionales) Recomendaciones de SLA y SLR Recomendaciones de costos y precios Cambios proactivos y mejoras del servicio Calendario de operaciones revisado Revisiones de efectividad Informes de auditoría

3.2 Subprocesos La Gestión de Capacidad consiste de tres subprocesos, dentro de los cuales hay varias actividades (ver Figura 11.2). 3.2.1 Gestión de Capacidad de Negocio Este subproceso es responsable de asegurar que se consideren, programen e implementen de modo puntual los requerimientos futuros del negocio sobre servicios TI. Esto se puede alcanzar usando los datos existentes de la utilización actual de los recursos de varios servicios para definir tendencias, pronosticar o modelar requerimientos futuros. Estos requerimientos futuros provienen de los planes de negocio esbozando nuevos servicios, mejoras y crecimiento en servicios existentes, planes de desarrollo, etc. 3.2.2 Gestión de Capacidad de Servicio El enfoque de este subproceso es la gestión del rendimiento de los servicios TI utilizados por los Clientes. Es responsable de asegurar que el rendimiento de todos los servicios, como se detalla en los objetivos de los SLA’s y SLR’s, es monitoreado y

medido, y que los datos recogidos son registrados, analizados e informados. Según sea necesario, se tomará acción para asegurar que el rendimiento de los servicios cumpla con los requerimientos del negocio. Para llevar a cabo este trabajo, el proceso de la Gestión de la Capacidad. Esto se lleva a cabo por el personal que posee conocimiento de todas las áreas de tecnología utilizadas en la entrega del servicio, y frecuentemente implica buscar asesoramiento de especialistas involucrados en la Gestión de Capacidad de Recursos. 3.2.3 Gestión de Capacidad de Recursos El enfoque en este subproceso es la gestión de los componentes individuales de la infraestructura TI. Es responsable de asegurar que todos los componentes dentro de la infraestructura TI son monitoreados y medidos, y que los datos recogidos son registrados, analizados e informados. Según sea necesario, se tomará acción para


CIBERTEC


99

gestionar los recursos disponibles para asegurar que los servicios TI cumplan con los requerimientos del negocio. Al realizar este trabajo, el proceso de Gestión de Capacidad es asistido por personas especializadas en determinadas áreas de tecnología. Cada uno de los subprocesos realizan muchas actividades comunes, pero cada subproceso tiene un enfoque muy diferente: La Gestión de Capacidad de Negocio se centra en los requerimientos de negocio actuales y futuros, mientras que la Gestión de Capacidad de Servicio se centra en la entrega de los servicios existentes que soportan el negocio y la Gestión de Capacidad de Recursos se centra en la tecnología que soporta toda la provisión del servicio.

Figura 11.2 Subprocesos y sus ac tividades

3.3 Plan de Capacidad (Capacity Plan) El Plan de Capacidad describe la Capacidad actual de la infraestructura TI y los Cambios que se esperan en la demanda de los servicios TI, la sustitución de los componentes antiguos y los desarrollos técnicos. El Plan de Capacidad también define los Cambios necesarios para proporcionar los niveles de servicios acordados en los SLAs y a un costo aceptable. Se debe diseñar un plan todos los años, y debe examinarse cada trimestre para confirmar su validez. En cierta manera, el Plan de Capacidad es la producción más importante de la Gestión de la Capacidad. Las producciones a menudo incluyen un plan anual que se sincroniza con el presupuesto o el plan de inversión, un plan a largo plazo y planes trimestrales con detalles de los Cambios de Capacidad programados. Con esto se consigue un conjunto de planes coherentes, donde el nivel de detalle aumenta al acercarse al horizonte proyectado.

3.4 Base de Datos de Capacidad (CDB) Crear y poblar la CDB significa unir y actualizar la información técnica, la información del negocio y toda información que afecte a la Gestión de la Capacidad. Puede resultar imposible almacenar toda la información de Capacidad en una sola base de datos. Los administradores de red pueden utilizar sus propios planteamientos. Por lo general, la CDB hace referencia a la colección de fuentes con información de Capacidad.

CIBERTEC


100

3.5 Modelamiento (Modelling) El objetivo principal de la Gestión de Capacidad es predecir el comportamiento de los Servicios TI bajo un volumen dado y variedad de trabajo. El modelamiento es una actividad que puede beneficiar a cualquiera de los subprocesos de Gestión de la Capacidad. Los distintos tipos de modelamiento varían desde hacer estimados basados en la experiencia y en información de utilización de recursos actuales, hasta estudios pilotos, prototipos y “benchmarks” a gran escala. Lo primero es un enfoque

económico y razonable para decisiones pequeñas diarias, mientras que lo segundo es costoso pero puede ser aconsejable al implementar un nuevo proyecto grande. Algunas técnicas de modelamiento son:   



Análisis de tendencias Modelamiento analítico Modelamiento de simulación Modelos de línea de base

3.6 Dimensionamiento (Sizing) de la aplicación El dimensionamiento de la aplicación tiene una vida finita. Se inicia en la etapa de Iniciación del Proyecto de una nueva aplicación o cuando hay un Cambio mayor de una aplicación existente, y se completa cuando la aplicación se acepta en el ambiente de producción. El objetivo principal del dimensionamiento de la aplicación es estimar los requerimientos de recursos para soportar un Cambio propuesto de la aplicación o una nueva aplicación, y para asegurar que alcanza los niveles de servicio requeridos. Para conseguir esto el dimensionamiento de la aplicación tiene que ser una parte integral del ciclo vida de las aplicaciones.

3.7 Informes de gestión

Los informes de gestión que da el proceso de Gestión de la Capacidad incluyen por un lado, información de control del proceso en términos de características del Plan de Capacidad, recursos utilizados para implementar el progreso de las actividades de mejora, y por otro lado, los informes de excepción sobre temas tales como: 

 



Discrepancias entre la utilización de la Capacidad real y la planeada Tendencias en las discrepancias Impacto en los niveles de servicio Incremento/disminución de la utilización de la Capacidad esperada a corto y largo plazo Umbrales o marcas que, cuando se alcancen, necesitarán de capacidad adicional

3.8 Factores críticos de éxito e indicadores de rendimiento La Gestión de la Capacidad depende de los siguientes factores críticos de éxito: Expectativas y previsiones del negocio correctas Comprensión de la estrategia y planificación TI y su veracidad Apreciación de los desarrollos técnicos Cooperación con los otros procesos  




CIBERTEC


101

El éxito de Gestión de la Capacidad depende de los siguientes indicadores de rendimiento: 







Predicción de la demanda del Cliente: Carga de trabajo, tendencias en el tiempo y veracidad del Plan de Capacidad. Tecnología: Rendimiento de todos los servicios TI, implementación de nueva tecnología (tiempo, costo y funcionalidad) y cumplimiento de los SLAs. Costos: Reducción en el número de compras, reducción de sobrecapacidad y diseño de planes de inversión. Operaciones: Reducción del número de Incidentes debido a Problemas de rendimiento y satisfacción de la demanda del Cliente.

4. Roles y Responsabilidades 4.1 Rol La Gestión de la Capacidad tiene la responsabilidad de asegurar que hay una adecuada Capacidad TI para alcanzar los niveles de servicio requeridos y que los directivos TI están asesorados correctamente de cómo emparejar la Capacidad con la demanda, y asegurar también que el uso de la Capacidad existente es óptimo. La Gestión de la Capacidad es también responsable de recomendar al proceso de Gestión de Niveles de Servicio (SLM) sobre los niveles de servicio apropiados o las opciones del nivel de servicio.

4.2 Responsabilidades 



  

    

Asegura que los niveles apropiados de monitoreo de recursos y rendimiento del sistema son establecidos, y que la información registrada en una CDB se mantiene actualizada y utilizada por todas las partes del proceso de la Gestión de la Capacidad. Produce Planes de Capacidad alineados con el ciclo de planeamiento del negocio, identificando los requerimientos de Capacidad con suficiente antelación para tener en cuenta los plazos de entrega. Documenta la necesidad de cualquier incremento o reducción en hardware basada en SLRs y restricciones de costos. Produce informes de gestión periódicos, que incluyen el uso actual de los recursos actuales, tendencias y pronósticos. Dimensiona todos los nuevos sistemas propuestos para determinar los recursos de cómputo y de red requeridos, para determinar la utilización del hardware, niveles de servicio de rendimiento y los costos implicados. Evalúa la nueva tecnología y su relevancia en la organización en términos de rendimiento y costos. Evalúa los nuevos productos de hardware y software para el uso de la Gestión de Capacidad que pueden mejorar la eficiencia y efectividad del proceso. Lleva a cabo pruebas de rendimiento de los nuevos sistemas. Informa sobre el rendimiento vs los objetivos que contienen los SLAs. Mantiene un conocimiento de la demanda futura para los Servicios TI y predice los efectos de la demanda en los niveles de servicio de rendimiento.

CIBERTEC


102

 

     

Determina los niveles de servicio de rendimiento que pueden mantenerse con costos justificables. Recomienda el ajuste de los sistemas y da recomendaciones sobre el diseño y el uso de los sistemas para asegurar un uso óptimo de todos los recursos de hardware y software. Recomienda resoluciones para Incidentes y Problemas relacionados con el rendimiento. Recomienda cuando gestionar la demanda de los clientes sobre sistemas. Lleva a cabo estudios de Capacidad y rendimiento ad-hoc. Asegura que los requerimientos de confiabilidad y disponibilidad son considerados en el planeamiento y dimensionamiento de la Capacidad. Está representada en el CAB, evaluando y autorizando los Cambios. Asegura la realización de auditorías periódicasy ad-hoc.


CIBERTEC


103

Resumen



La Gestión de la Capacidad esresponsable de asegurar que la Capacidad dela infraestructura TI esté alineada con las demandas de la empresa de la manera más efectiva en costo y tiempo.



La Gestión de Capacidad consiste de tres subprocesos: -

Gestión de Capacidad de Negocio Gestión de Capacidad de Servicio Gestión de Capacidad de Recursos



El Plan de Capacidad (Capacity Plan) describe la Capacidad actual de la infraestructura TI y los Cambios que se esperan en la demanda de los servicios TI, la sustitución de los componentes antiguos y los desarrollos técnicos.





CIBERTEC


104


CIBERTEC


105


3 TEMA

11

GESTIÓN DE LA DISPONIBILIDAD LOGRO DE LA UNIDAD DE APRENDIZAJE Al término de la unidad, el alumno explicará las funciones de los procesos que conforman la entrega del servicio de TI, identificando con precisión sus características, componentes, ventajas, recomendaciones de implementación y medición, así como la interrelación de dichos procesos.

TEMARIO Objetivos Alcance

Descripción del Proceso Responsabilidades y Habilidades



CIBERTEC


106

1. OBJETIVOS 











Asegurar que los Servicios TI son diseñados para entregar los niveles de Disponibilidad requeridos por el negocio. Proveer una variedad de informes de Disponibilidad TI para asegurar que los niveles acordados de Disponibilidad, confiabilidad y mantenimiento son medidos y monitoreados continuamente. Optimizar la Disponibilidad de la Infraestructura TI para entregar mejoras rentables (efectivas en costo) que proporcionan beneficios tangibles al negocio y a los Usuarios. Lograr, durante un periodo de tiempo, una reducción en la frecuencia y en la duración de los Incidentes que impactan la Disponibilidad TI. Asegurar que las caídas en la Disponibilidad TI se reconozcan y que se identifiquen y realicen las acciones correctivas apropiadas. Crear y mantener un plan de Disponibilidad cuyo objetivo sea la mejora de la Disponibilidad total de los Servicios TI y los componentes de la Infraestructura, para asegurar la satisfacción de los requerimientos actuales y futuros de la Disponibilidad del negocio.

2. ALCANCE La Gestión de la Disponibilidad se refiere al diseño, implementación, medición y gestión de la Disponibilidad de la Infraestructura TI para asegurar que los requerimientos del negocio sobre Disponibilidad se cumplan. La Gestión de la Disponibilidad: 









Debe aplicarse a todos los nuevos Servicios TI y para los servicios existentes que tengan definidos los Requerimientos del Nivel de Servicio (SLRs) o Acuerdos de Nivel de Servicio (SLAs). Puede aplicarse a aquellos Servicios TIque son críticos para el negocio y que no tengan definido un SLA. Debe aplicarse a los proveedores (internos y externos) que forman la organización de soporte TI, antes de la definición de un SLA. Considera todos los aspectos de la Infraestructura TI y su organización de soporte que puede impactar a la Disponibilidad, incluyendo capacitación, habilidades, políticas, efectividad de los procesos, procedimientos y herramientas. No es responsable de la Gestión de Continuidad del Negocio y la reanudación de los procesos del negocio después de un desastre (lo cual es responsabilidad de la Gestión de Continuidad del Servicio TI– ITSCM), pero provee de entradas clave a ITSCM, teniendo ambos una relación muy estrecha.

3. DESCRIPCIÓN DEL PROCESO 3.1 Terminología 

Disponibilidad (Availability): Es la capacidad de un Servicio TI o componente



para realizar sus funciones en un periodo de tiempo definido. Confiabilidad (Reliability): Es la capacidad de un Servicio TI de no presentar fallas operativas.


CIBERTEC






107

Sostenibilidad (Maintainability): Es la capacidad del componente de la Infraestructura TI de mantenerse en el estado operativo o recuperarse de una falla. Servicialidad (Serviciability): Describe los acuerdos contractuales definidos con proveedores externos sobre disponibilidad, confiabilidad y sostenibilidad de los Servicios TI y componentes bajo su responsabilidad.

3.2 Entradas y Salidas 3.2.1 Entradas   



 

Requerimientos de Disponibilidad Evaluación del impacto para todosdel losnegocio procesos del negocio que soporta TI Requerimientos de Disponibilidad, confiabilidad y sostenibilidad para los componentes de la Infraestructura TI Información sobre fallas de los Servicios TI y componentes, normalmente en la forma de registros de Incidentes y Problemas Datos de configuración y monitoreo de los Servicios TI y componentes Niveles de servicio alcanzados comparados con los niveles de servicio acordados para cada Servicio TI que tenga un SLA

3.2.2 Salidas 











Criterios de diseño de Disponibilidad y recuperación para cada Servicio TI nuevo o mejorado Detalles de las técnicas de Disponibilidad que serán desplegadas para proveer mayor resistencia (resilience) a la Infraestructura con la finalidad de prevenir o minimizar el impacto de las fallas en los Servicios TI Objetivos acordados de Disponibilidad, confiabilidad y sostenibilidad de los componentes de la Infraestructura TI que soportan los Servicios TI Informes sobre Disponibilidad, confiabilidad y sostenibilidad para reflejar las perspectivas del negocio, del Usuario y de la organización de soporte TI Los requerimientos de monitoreo de los componentes TI para asegurar que se detecten e informen las desviaciones en Disponibilidad, confiabilidad y sostenibilidad Plan de Disponibilidad para la mejora proactiva de la Infraestructura TI

3.3 Actividades Las actividades claves del proceso son las siguientes: 









Determinar los requerimientos de Disponibilidad del negocio para un Servicio TI nuevo o mejorado y formular los criterios de diseño de Disponibilidad y recuperación para la Infraestructura TI. En coordinación con la ITSCM, determinar las funciones vitales del negocio y el impacto que surge del fallo de los componentes TI. Definir los objetivos de Disponibilidad, confiabilidad y sostenibilidad para los componentes de la Infraestructura TI que soportan el Servicio TI para permitir que éstos se documenten y estén de acuerdo con los SLAs, OLAs y contratos. Establecer medidas e informes de Disponibilidad, confiabilidad y sostenibilidad que reflejen las perspectivas del negocio, el Usuario y la organización de soporte TI.

Monitorear y analizar las tendencias de Disponibilidad, confiabilidad y sostenibilidad de los componentes TI.

CIBERTEC


108



 

Revisar la Disponibilidad de los Servicios TI y de los componentes e identificar niveles inaceptables. Investigar las razones subyacentes de Disponibilidad inaceptable. Producir y mantener un Plan de Disponibilidad que priorice y planifique las mejoras de Disponibilidad TI.

3.4 El ciclo de vida de la no Disponibilidad Las fases por las que pasa un servicio debido a problemas técnicos son (ver Figura 12.1): 

Inicio: El Usuario reconoce un problema técnico en el servicio.



Detección: Se informa al proveedor del servicio sobre el problema técnico.







Diagnóstico: El proveedor del servicio toma la acción de localizar la causa del problema técnico. Reparación: El proveedor del servicio repara el servicio. El tiempo necesario para esto se calcula desde el momento en el que se ha informado al proveedor del servicio sobre el problema técnico. Recuperación – Restauración: Tiempo que se necesita para conseguir que vuelva a funcionar el servicio, incluidas todas las actividades de configuración e inicialización, y el tiempo necesario para que el servicio vuelva a estar disponible para el Usuario.

El tiempo depende en parte de la velocidad de reacción de la organización TI y posibles proveedores externos. Para conseguir una buena perspectiva de esto, se toman los valores medios de las medidas. Estos valores medios se utilizan para predecir la Disponibilidad un servicio futuro y paraen discutir silas lasexpectativas mejoras son de urgentes. Los valoresdesiguientes sonen loselmás comunes la Gestión de la Disponibilidad: 

Tiempo Medio de Reparación (MTTR): Es el tiempo medio entre la aparición del incidente y su restauración, también llamado tiempo de parada o “Downtime”.

Este valor mide la sostenibilidad y la servicialidad. 

Tiempo Medio Entre Fallos (MTBF): Es el tiempo medio entre la restauración del Incidente y la aparición del próximo, también llamado tiempo de Disponibilidad o “Uptime”. Este valor mide la Disponibilidad.



Tiempo Medio Entre Incidentes del Sistema (MTBSI): Es el tiempo medio entre la aparición de dos Incidentes consecutivos. Es la suma de MTTR y MTBF. Este valor mide la confiabilidad.

La relación entre MTBF y MTBSI indica si hay muchas fallas menores o solo algunas fallas mayores.


CIBERTEC


109

Figura 12.1 Ciclo de vida de la no Disponibilidad

3.5 Cálculo de la Disponibilidad Para determinar la Disponibilidad básica de un Servicio TI o componente como un porcentaje de Disponibilidad se puede usar la siguiente fórmula básica: Disponibilidad = (Horas Acordadas de Servicio – Downtime) X 100 Horas Acordadas de Servicio 3.5.1 Configuración en serie Esta configuración de la Infraestructura TI se caracteriza por no tener componentes adicionales que provean de mayor resistencia a la infraestructura (ver Figura 12.2) . El porcentaje de Disponibilidad para esta configuración se basa en el producto de los porcentajes de Disponibilidad de todos los componentes individuales. 3.5.2 Configuración en paralelo Esta configuración de la Infraestructura TI se caracteriza por tener componentes adicionales que proveen de mayor resistencia a la infraestructura (ver Figura 12.2), de tal manera que los componentes de respaldo (backup) comienzan a funcionar automáticamente. El porcentaje de Disponibilidad se calcula multiplicando la noDisponibilidad (recíproco de la Disponibilidad) de cada componente.

CIBERTEC


110

Figura 12.2 Disponibilidad en serie y en par alelo

3.6 Informes de gestión Los informes de Disponibilidad incluyen las siguientes métricas: 





 

Tasa de Disponibilidad (o falta de Disponibilidad) en términos de MTTR, MTBF y MTBSI. Tiempo de Disponibilidad y de parada total. Número de fallas. Información adicional de fallas que real o potencialmente dan como resultado una falta de Disponibilidad más alta que la acordada. Tiempos de detección, respuesta, reparación y recuperación Tiempo de procesamiento de implementación de servicios, SLAs y grupos de Clientes cubiertos por SLAs.

Algunas métricas se pueden determinar para cada servicio, equipo o dominio de infraestructura (red, centro de cómputo y ambiente de las estaciones de trabajo). El problema con los informes de disponibilidad es que las métricas que se presentan pueden no corresponder con la percepción del Cliente. Es por lo tanto importante informar sobre la Disponibilidad desde el punto de vista del Cliente. El informe debe proporcionar en primer lugar información sobre la Disponibilidad del servicio para las funciones esenciales del negocio, los servicios de aplicación, y la disponibilidad de los componentes TI técnicos. Los informes deben redactarse en un lenguaje que el Cliente pueda entender.

3.7 Factores críticos de éxito e indicadores de rendimiento 3.7.1 Factores críticos de éxito El negocio debe haber definido claramente los objetivos de Disponibilidad. Se debe haber constituido la Gestión de Niveles de Servicio para formalizar los acuerdos.  


CIBERTEC






111

El negocio y la organización TI deben usar las mismas definiciones de Disponibilidad y tiempo de parada. El negocio y la organización TI deben ser conscientes de los beneficios de la Gestión de la Disponibilidad.

3.7.2 Indicadores de rendimiento 

 

Porcentaje de Disponibilidad (Uptime) por servicio o grupo de Usuarios. Duración del tiempo de parada. Frecuencia del tiempo de parada.

4. RESPONSABILIDADES Y HABILIDADES 4.1 Responsabilidades 









 









Desplegar el proceso de Gestión de la Disponibilidad y los métodos y técnicas asociadas. Asegurar que el proceso de Gestión de la Disponibilidad, sustécnicas y métodos asociados son regularmente revisados, auditados, y mejorados continuamente. Determinar los requerimientos de Disponibilidad del negocio para nuevos y mejorados Servicios TI. Crear los criterios de diseño de Disponibilidad y recuperación a ser aplicados a un nuevo o mejorado diseño de Infraestructura. Asegurar que los niveles de Disponibilidad TI requeridos tienen costos justificados Definir los objetivos de la Disponibilidad requerida por la Infraestructura TI y sus componentes que soportan un nuevo o mejorado Servicio TI. Establecer las medidas y los informes que reflejan los requerimientos del negocio, dellaUsuario y de laTI organización de soporte TI. Monitorear Disponibilidad real alcanzada vs los objetivos y asegurar que las caídas son direccionadas correctamente. Producir y mantener el Plan de Disponibilidad, que prioriza y planifica las mejoras de la Disponibilidad TI. Promocionar el conocimiento y el entendimiento de la Gestión de la Disponibilidad dentro de la organización de soporte TI. Mantener un conocimiento de los avances de la tecnología y la mejor práctica TI, por ejemplo ITIL.

4.2 Habilidades clave     







Tener experiencia práctica en gestión de procesos. Tener un buen entendimiento de las disciplinas de ITIL. Tener experiencia práctica de técnicas y métodos de mejora continua. Tener un buen entendimiento de principios y procesos estadísticos y analíticos. Poseer buenas habilidades interpersonales para la comunicación escrita, oral y cara a cara. Poseer habilidades en técnicas y métodos de negociación. Tener habilidad numérica. Tener un buen conocimiento de las tecnologías TI disponibles y emergentes. Tener la habilidad para entender cómo la tecnología TI soporta el negocio.

Tener un conocimiento razonablede la Gestión de Costos.

CIBERTEC


112

Resumen



La Disponibilidad (Availability) es la capacidad de un Servicio TI o componente para realizar sus funciones en un periodo de tiempo definido.



La Gestión de la Disponibilidad trabaja con los siguientes valores: -

Tiempo Medio de Reparación (MTTR) Tiempo Medio Entre Fallos (MTBF) Tiempo Medio Entre Incidentes del Sistema (MTBSI)



La configuración en paralelo dela Infraestructura TI ofrece mayorDisponibilidad que la configuración en serie por tener componentes adicionales que proveen de mayor resistencia a la Infraestructura.






CIBERTEC


113


3 TEMA

12

GESTIÓN DE LA CONTINUIDAD LOGRO DE LA UNIDAD DE APRENDIZAJE Al término de la unidad, el alumno explicará las funciones de los procesos que conforman la entrega del servicio de TI, identificando con precisión sus características, componentes, ventajas, recomendaciones de implementación y medición, así como la interrelación de dichos procesos.

TEMARIO Introducción Objetivos Descripción del Proceso Habilidades Clave



CIBERTEC


114

1. INTRODUCCIÓN Han habido cambios significativos en la tecnología y la forma en la que se utiliza ésta en el negocio. Las dependencias entre los procesos del negocio y la tecnología están tan unidas actualmente que la Planificación de la Contingencia (también llamada Gestión de la Continuidad del Negocio o Business Continuity Management– BCM) incorpora un elemento del negocio (Planificación de la Continuidad del Negocio) y un elemento de tecnología (Planificación de la Gestión de la Continuidad del Servicio TI). Sus dependencias determinan que una es un subconjunto de la otra, dependiendo de la naturaleza del negocio y en la medida en que la tecnología se ha extendido en la organización. Se asume que la Continuidad del Negocio es lo principal y que la Gestión de la Continuidad del Servicio TI (ITSCM) es un subconjunto de los procesos de la Gestión de la Continuidad del Negocio (BCM).

2. OBJETIVOS El objetivo principal de la ITSCM es dar soporte a los procesos del BCM asegurando que las facilidades técnicas y servicios TI requeridos (incluyendo computadoras, redes, aplicaciones, telecomunicaciones, soporte técnico, y Service Desk) pueden recuperarse en los plazos requeridos y acordados con el negocio. La ITSCM es responsable de:  

 

 

Evaluar el impacto de la interrupción de los servicios TI tras un desastre. Identificar los servicios críticos para el negocio que requieren de medidas y de prevenciones adicionales. Definir los periodos dentro de los cuales se deben restaurar los servicios. Tomar medidas para prevenir, detectar, preparar y mitigar los efectos de los desastres o para reducir su impacto. Definir el plan a utilizar para restaurar los servicios. Desarrollar, evaluar y mantener un plan de recuperación con detalles suficientes para sobrevivir al desastre y restaurar los servicios a la normalidad tras un periodo definido.

3. DESCRIPCIÓN DEL PROCESO La Figura 13.1 muestra las etapas y las actividades del proceso ITSCM.

3.1 Etapa 1 - Iniciación Las actividades a considerar durante el proceso de iniciación dependen de la medida en que las facilidades de contingencia se han aplicado dentro de la organización. Algunas partes del negocio pueden haber establecido Planes de Continuidad individuales basados en Workarounds manuales y TI puede haber desarrollado planes de contingencia para sistemas críticos. Esto es una buena entrada para el proceso, sin embargo, una ITSCM efectiva depende de soportar funciones críticas del negocio y asegurar que el presupuesto disponible se aplica de la manera más apropiada.

El procesoactividades: de iniciación considera a la organización como un todo y consiste de las siguientes


CIBERTEC


115

Figura 13.1 Modelo del Proceso ITSCM 3.1.1 Definición de la política Se debe definir lo antes posible la política y se debe comunicar a toda la organización para que todos los involucrados sean conscientes de la necesidad de la ITSCM. La gestión debe mostrar su compromiso. 3.1.2 Definición del alcance y las áreas relevantes Requisitos de seguridad, estándares de calidad como la serie ISO 9000, estándares de Gestión de la Seguridad como ISO 27001, y principios de política del negocio generales que se usan para seleccionar el plan y los métodos de evaluación de riesgo y el análisis de impacto del negocio. También se identifica la estructura de gestión correcta y la estructura de proceso para hacer frente a los desastres. 3.1.3 Asignación de recursos Establecer un ambiente necesitará inversión recursos. También será ITSCM necesario capacitardeeluna personal paraimportante que este en se personal encuentrey preparado para implementar la Etapa 2 del proceso ITSCM (Requerimientos y Estrategia).

CIBERTEC


116

3.1.4 Establecer la organización del proyecto Es aconsejable usar métodos de gestión de proyecto formales, por ejemplo PMI, soportado por software de planificación.

3.2 Etapa 2 - Análisis de Requerimientos y Definición de Estrategia Esta etapa constituye el fundamento de la ITSCM y es un componente crítico para determinar qué tan bien sobrevivirá una organización ante una interrupción del negocio o un desastre y los costos que incurrirán. Las actividades de esta etapa se dividen en dos secciones: 



Requerimientos: Realiza el Análisis de Impacto del Negocio (Business Impact Analysis – BIA) y la evaluación de riesgo. Estrategia: Determina y acuerda las medidas de reducción del riesgo y las opciones de recuperación para soportar los requerimientos.

3.2.1 Análisis de Impacto del Negocio El propósito del Análisis de Impacto del Negocio es identificar el daño o pérdida potencial que puede sufrir la organización como consecuencia de una interrupción de los procesos críticos del negocio. Para ello se realiza unanálisis de los servicios TI esenciales para el negocio (p.e. sistema de información, aplicaciones office, de contabilidad, e-mail, etc.) y cuáles deben estar disponibles de acuerdo con los SLAs. Para algunos servicios no esenciales, se puede acordar la provisión de un servicio de emergencia con capacidad y disponibilidad limitadas. Los niveles de servicio durante la recuperación ante un desastre solo podrán ser modificados si el Cliente está de acuerdo. Para los servicios críticos, se debe encontrar el balance entre prevención y opciones de recuperación. A continuación se debe hacer una evaluación de las dependencias entre servicios y recursos TI. La información de la Gestión de la Disponibilidad se usa para analizar hasta qué punto los recursos TI tienen una función crítica en el soporte de los servicios TI que se describieron anteriormente. La Gestión de la Capacidad proporciona información sobre la capacidad necesaria. También se determina hasta que punto se pueden interrumpir los servicios, desde la pérdida del servicio hasta su restauración. Más tarde, esta información se utilizará para identificar las opciones de recuperación para cada servicio. 3.2.2 Evaluación del Riesgo Un análisis de riesgo puede ayudar a identificar los riesgos a los que está expuesto un negocio. También dará información valiosa a la gestión porque identificará las amenazas y vulnerabilidades y las medidas de prevención que correspondan. Ya que es bastante costoso mantener un plan de recuperación ante desastres, primero se deben tomar medidas preventivas. Una vez que se tomaron tales medidas para la mayoría de los riesgos, se determinará si aún existen riesgos que puedan necesitar de un plan de contingencia. La Figura 13.2 muestra los vínculos entre el Análisis del Riesgo y la Gestión del Riesgo, se basa en la CCTA Risk Analysis and Management Method (CRAMM).


CIBERTEC


117

Figura 13.2 Evaluación del Riesgo El modelo está formado por las siguientes actividades: Identificar riesgos: Es decir riesgos de componentes (activos o bienes) específicos del servicio TI que soportan el proceso del negocio y, que de fallar, causarán una interrupción del servicio. Los riesgos típicos de TI incluyen:  

  













Daño o denegación de acceso al edificio. Pérdida de sistemas TI, redes, sistemas de Distribución de Llamada Automática (ACDs), firewalls, sistemas criptográficos, Infraestructura de Clave Pública (PKI), etc. Pérdida de datos o pérdida de integridad de datos. Pérdida de servicios de red incluidos problemas de telecomunicaciones. No disponibilidad de Personal clave, p.e. solo una persona que sabe cómo mantener un servidor de red crítico o una aplicación de negocio y que no exista documentación. Falla de partners o proveedores de servicio, p.e. organizaciones externas proveedoras de sistemas o servicio TI (p.e. soporte, desarrollo, mantenimiento). Pérdida de servicio de un partner debido a una excesiva demanda de servicio (p.e. visitas o volúmenes excesivos de una página web). Falta de seguridad (p.e. fraude, sabotaje, virus informáticos o software malicioso) y pérdida de elementos del ambiente de operaciones (p.e. aire acondicionado). Pérdida de expedientes de papel críticos o medios (p.e. manuales, documentos, backups, etc.). Pérdida de elementos básicos del negocio (p.e. luz, gas, agua).

Evaluar los niveles de amenaza y vulnerabilidad : La amenaza se define como “la probabilidad de que una interrupción del servicio ocurrirá” y la vulnerabilidad se define como “si, y en qué medida, le afectará a la organización la materialización de la amenaza”. Ejemplo de amenaza es la combinación de provisión de energía

poco fiable y un área con muchas tormentas o con tormentas eléctricas. Un 

CIBERTEC


118

pararrayos brindará algo de protección contra los rayos, pero todavía pueden afectar seriamente a la red y a los sistemas, es decir todavía son vulnerables. 



Evaluar los niveles de riesgo: Se evalúan las amenazas y vulnerabilidades en el contexto de los componentes TI para dar una estimación de los riesgos. Determinar contramedidas:Después del análisis del riesgo, es posible determinar contramedidas apropiadas o medidas de reducción del riesgo (mecanismos de la ITSCM) para gestionar los riesgos, es decir reducirlos a un nivel mínimo aceptable o mitigarlos.

3.2.3 Estrategia de Continuidad del Negocio La mayoría de las organizaciones tienen que adoptar un balance entre la reducción del riesgo (prevención) y las opciones de recuperación (plan de recuperación), las cuales son tratadas a continuación. 



Medidas de reducción del riesgo: Estas medidas de prevención se pueden tomar en base al análisis del riesgo, considerando con mucho cuidado costos y riesgos. Las medidas pueden tender a reducir la probabilidad o el impacto de las contingencias, y por lo tanto reducir el alcance del plan de recuperación. Se pueden tomar medidas contra el polvo, las temperaturas demasiado altas o bajas, fuego, interrupción de energía y robo. El resto de los riesgos están cubiertos en el plan de recuperación. Las medidas de reducción del riesgo se toman junto con la Gestión de la Disponibilidad y pueden incluir el uso de UPS y provisiones de energía de backup, sistemas tolerantes a fallos, almacenamiento en otro lugar, sistemas RAID, equipos y componentes de repuesto, etc. Opciones de recuperación: Lasopciones de recuperación deben considerar: 

 



Personal y alojamiento – cómo hacer frente al alojamiento, mobiliario, transporte, distancias de viaje, etc. Sistemas TI, hardware, aplicaciones, software, redes y la información. Servicios críticos como energía, telecomunicaciones, agua, correo y servicios de mensajería. Activos críticos como registros en papel y material de referencia.

Hay un número de opciones disponibles para la recuperación de los servicios TI:   







No hacer nada. Sistema manual basado en papel. Acuerdos Recíprocos – esta opción puede utilizarse si dos organizaciones tienen hardware similar y acuerdan prestarse las instalaciones en caso de desastre. Hoy en día esta opción no es muy atractiva debido a los sistemas on-line. Recuperación Gradual (stand-by frío) – es cuando se reconstruye (una parte de) la infraestructura a partir de cero en un local que se acuerde por la dirección. Este local se equipa con energía, teléfonos y facilidades de red. Se puede realizar por contrato con proveedores externos. Recuperación Intermedia (stand-by cálido) – es cuando se alquila la capacidad y el espacio de una compañía especial que asumirá los servicios del negocio. Recuperación Inmediata (stand-by caliente) – es cuando se tiene más locales o se construye un segundo local. En tiempos de desastre, se puede cambiar al


CIBERTEC


119

otro local a veces en segundos. Estos locales se usan mayormente como locales de prueba.

3.3 Etapa 3 - Implementación Una vez acordada la estrategia el ciclo vida de la Continuidad del Negocio pasa a la etapa de Implementación, involucrando a TI. La etapa de implementación consiste de los siguientes procesos: 







Establecer la organización y desarrollar planes de implementación Implementar arreglos de stand-by Implementar medidas de reducción del riesgo Desarrollar planes de recuperación de TI Desarrollar procedimientos Realizar pruebas iniciales

Cada uno de los procesos mencionados se considera con respecto a las responsabilidades específicas que TI debe asumir.

3.3.1 Secciones del plan de recuperación 













Administración: Cuándo y cómo ejecutar el plan, programas de acción y personal involucrado. Infraestructura TI: Las partes de la infraestructura que estén sujetas a la Gestión de la Continuidad. Ej.: detalles de hardware, software y telecomunicaciones, incluyendo repuestos, contratos y acuerdos de soporte de recuperación. Procedimientos de Operación de Gestión de Infraestructura TI: Instrucciones requeridas para recomenzar operaciones, incluidos detalles de SLA y manuales. Personal: Información sobre el personal a transferir al local de contingencia, quién va a sustituir al personal que no asistirá al local de contingencia o, en el peor de los casos, ha muerto. En tiempos de desastre, el personal está más interesado en cómo está su propia familia y propiedad que cómo está TI. Se tiene que idear un plan para reponer personal. Seguridad: Instrucciones para protección contra robo, fuego y explosiones en el local principal y de contingencia, e información sobre las instalaciones de almacenamiento externo como depósitos y bóvedas. Local de contingencia: Situación, contactos, facilidades, acuerdos de seguridad y transporte al local, cómo construir el local, cómo implementar infraestructura y aplicaciones, cómo restaurar datos, etc. Restauración: Procedimiento detallando cómo, dónde y cuánto tardará en restaurarse la infraestructura completa, especialmente si solo se restauran los servicios más importantes.

CIBERTEC


120

3.4 Etapa 4- Gestión Operacional Una vez que la implementación se ha completado, hay necesidad de asegurar que el proceso se mantiene como parte del negocio. Esto se consigue a través de la gestión operacional e incluye: 











Educación y previsión: Todo el personal debe tener conocimiento de las implicancias de la Continuidad del Negocio y de la Continuidad del Servicio y considerarlos como parte de su rutina de trabajo normal y presupuesto. Capacitación: Personal TI tendrá que capacitar a miembros no-TI del equipo de recuperación de negocio no-TI para asegurar que tengan el nivel de competencia necesario para facilitar la recuperación. Revisión: todoslos entregables del proceso ITSCM para asegurar Revisar que se regularmente mantienen actualizados. Con respecto a TI sederequerirá cada vez que haya un cambio importante en su infraestructura, elementos o dependencias tales como sistemas nuevos o redes o cambio de proveedores de servicio, así como cuando hay un cambio en la dirección del negocio, estrategia de negocio o estrategia TI. Pruebas: Luego de las pruebas iniciales es necesario establecer un programa de pruebas periódicas para asegurar que los componentes críticos de la estrategia se prueben al menos anualmente o como lo indique la dirección ejecutiva o auditoría.

Control de Cambios: Después de las pruebas y revisiones y en respuesta a los Cambios del día a día, los planes de la ITSCM se deben actualizar. La ITSCM se debe incluir como parte del proceso de Gestión de Cambios para asegurar que cualquier Cambio en la Infraestructura se refleje en los acuerdos de contingencia proporcionados por TI o terceros. Planes inexactos o capacidades de recuperación inadecuadas pueden resultar en el fracaso de la ITSCM. Garantía: El proceso final en el ciclo de vida de la ITSCM implica obtener la garantía de que la calidad de los resultados de la ITSCM es aceptable para la dirección ejecutiva y que los procesos de la gestión operacional funcionan en forma satisfactoria.

4. HABILIDADES CLAVE Las habilidades que debe presentar la persona encargada de la Gestión de la Continuidad son:   





Experimentado Nivel de Gestión TI. Experiencia en ITSCM. Conocimiento y experiencia de las tareas de Gestión de Contratos. Habilidad para trasladar los requerimientos de recuperación del negocio a requerimientos técnicos y especificaciones. Buenos conocimientos técnicos de TI para asegurar la calidad de los procedimientos a realizarse. Habilidad para comunicarse a todos los niveles dentro de la organización.


CIBERTEC


121

Resumen

El objetivo principal de la ITSCM es dar soporte a los procesos del BCM asegurando que las facilidades técnicas y servicios TI requeridos (incluyendo computadoras, redes, aplicaciones, telecomunicaciones, soporte técnico, y Service Desk) pueden recuperarse en los plazos requeridos y acordados con el negocio. El proceso ITSCM consta de cuatro etapas: -

Iniciación Requerimientos y Estrategia Implementación Gestión Operacional

Un análisis de riesgo puede ayudar a identificar los riesgos a los que está expuesto un negocio. También dará información valiosa a la gestión porque identificará las amenazas y vulnerabilidades y las medidas de prevención que correspondan. Si desea saber más acerca de estos temas, puede consultar la siguiente página. http://itil.osiatis.es/Curso_ITIL/ Aquí hallará más información sobre el presente capítulo.

CIBERTEC



122


4 TEMA

13

GESTIÓN DE NIVELES DE SERVICIO LOGRO DE LA UNIDAD DE APRENDIZAJE Al término de la unidad, el alumno explicará las funciones de los procesos que conforman la entrega del servicio de TI, identificando con precisión sus características, componentes, ventajas, recomendaciones de implementación y medición, así como la interrelación de dichos procesos.

TEMARIO Objetivos Conceptos Básicos Descripción del Proceso Roles y Responsabilidades



CIBERTEC


123

1. OBJETIVOS El objetivo de la Gestión de Niveles de Servicio (o Service Level Management – SLM) es mantener y mejorar la calidad del Servicio TI, a través de un ciclo constante de acuerdos, monitoreo e informes de los logros del Servicio TI y la realización de acciones para erradicar un servicio pobremente alineado con el negocio o la justificación de costos. A través de estos métodos, se puede desarrollar una mejor relación entre TI y sus Clientes.

2. CONCEPTOS BÁSICOS Requerimientos de Nivel de Servicio (Service Level Requirement - SLR): Cubren las definiciones detalladas de las necesidades del Cliente, y se utilizan para desarrollar, modificar y comenzar los servicios. Pueden servir como guías para el servicio y sus SLAs. Hojas de Especificación de Servicio: Describen la relación entre funcionalidad (como se acordó con el Cliente, y por consiguiente dirigido externamente desde el punto de vista del proveedor) y tecnología (implementación dentro de la organización, y por lo tanto dirigido internamente) y brindan una especificación detallada del servicio. Traducen los SLR (especificaciones externas) a definiciones técnicas necesarias para prestar el servicio (especificaciones internas). Son una herramienta importante para monitorear la correspondencia entre las especificaciones internas y externas. Catálogo de Servicios: El desarrollo de un Catálogo de Servicios puede ayudar a la organización TI a perfilarse y a presentarse como un proveedor de Servicios TI y no solo como la que implementa y mantiene la tecnología. Da una descripción detallada de los servicios operativos en el lenguaje del Cliente, junto con un resumen de los niveles de servicio asociados que la organización puede dar a sus Clientes. una herramienta comunicación muy importante. Puede ayudar a dirigir las Es expectativas de los de Clientes y de esta manera se facilita el proceso de alineación entre los servicios del Cliente y del proveedor. Este documento surge de las especificaciones externas en las Hojas de Especificación y por lo tanto debe redactarse en un lenguaje sencillo para el Cliente, y no en forma de especificaciones técnicas. Acuerdo de Nivel de Servicio (Service Level Agreement - SLA): Es un acuerdo entre la organización TI y el Cliente, en el que se detalla el servicio o los servicios a brindar. El SLA describe los servicios en términos no técnicos, de acuerdo con la percepción del Cliente, y durante el tiempo que dure el acuerdo sirve como estándar para medir y ajustar los servicios TI. Los SLAs por lo general tienen una estructura jerárquica, por ejemplo los servicios generales como redes y los servicios del Centro de Servicios se definen para toda la organización y los aprueba la gerencia. Los servicios más específicos, asociados con las actividades del negocio, se acuerdan a un nivel más bajo en la organización, por ejemplo con la unidad de administración de servicio, responsable de presupuesto o representante de Clientes. Programa de Mejora de Servicio (Service Improvement Program – SIP): Se implementa a menudo como un proyecto, define las actividades, fases e hitos asociados con la mejora de un servicio TI.


CIBERTEC


124

El Plan de Calidad de Servicio (Service Quality Plan - SQP): Es un documento importante ya que tiene toda la información administrativa necesaria para manejar la organización TI. Define los parámetros del proceso de la Gestión de Servicios y de la administración de las operaciones. El SLA define qué se entregará, a diferencia del SQP que define cómo se entregará. Incluye metas para cada proceso, en forma de Indicadores de Rendimiento. Por ejemplo, para la Gestión de Incidentes tiene los tiempos de resolución para varios niveles de impacto, y para la Gestión de Cambios tiene los tiempos del ciclo y costos de los Cambios estándar. Se definen los informes y los intervalos de los mismos para todos los procesos. Los Indicadores de Rendimiento derivan de los SLRs y se documentan en las Hojas de Especificaciones de Servicio. Cuando están implicados proveedores externos en la entrega del servicio, como la gestión externa de un Service Desk o el se mantenimiento PC’s, entonces Indicadores de Rendimiento también registran en losdeContratos de Soportelos(UC).

Acuerdo de Nivel Operacional (Operational Level Agreement - OLA): Es un acuerdo con un departamento TI interno que detalla los acuerdos sobre la provisión de ciertos elementos de un servicio, como un OLA sobre la disponibilidad de la red o la disponibilidad de los servidores de impresoras. Por ejemplo, si el SLA contiene objetivos para resolver Incidentes de alta prioridad, los OLAs deben incluir objetivos para cada elemento de la cadena de soporte (objetivo para el Centro de Servicios para responder llamadas, escalamiento, etc., objetivos para que el Soporte de Red comience a investigar y resolver Errores relacionados con la red que se les asignó, etc.). los OLAs ayudan a la organización a proporcionar los servicios. Contrato de Soporte (Underpinning Contract - UC): Es un contrato con proveedores externos que define los acuerdos sobre la provisión de ciertos elementos de un servicio, por ejemplo el arreglo de estaciones de trabajo, o el alquiler de líneas de comunicación. Esto resulta similar a la implementación externa de un OLA. En muchas organizaciones, un departamento TI interno proporciona los servicios TI. Los SLAs y OLAs son a menudo descripciones de lo que se acordó entre los departamentos internos, más que los contratos legales. Sin embargo, un UC con un proveedor externo se hará por lo general como un contrato formal.

3. DESCRIPCIÓN DEL PROCESO El proceso es un ciclo completo de calidad. Una vez que se han definido los SLAs, empieza el ciclo (ver Figura 13.1).

3.1 Establecer Función Si todavía no se ha establecido la Gestión de Nivel de Servicio entonces el primer paso es programar el proceso. Actividades tales como diseñar procedimientos, crear catálogos de servicio, editar SLAs y campañas de concientización son entre otros, los temas que se tienen que planificar. Esta fase comprende: 

 



Planificación inicial de actividades Plan de capacidad de monitoreo Establecimiento de la percepción inicial de los servicios Establecimiento y comprobación de los OLAs y UCs

CIBERTEC


125

Figura 13.1 Proceso SLM

3.2 Implementar SLAs Esta fase comprende:   

  

Producción de un Catálogo de Servicios Gestión de expectativas Planificación de la estructura del SLA Establecimiento de los SLRs y edición de los SLAs Elección del texto y los términos de los SLAs

Búsqueda de acuerdos Establecimiento de las capacidades de monitoreo Revisión de los OLAs y UCs Definición de los procesos de revisión e informes Anuncio (publicidad) de la existencia de SLAs

3.3 Gestionar el proceso continuado Esta fase comprende:  

Monitoreo e informes Reuniones de revisión de servicios ad-hoc

3.4 Revisión periódica Esta fase comprende:  

Reuniones de revisión de servicio periódicas Creación del SIP Mantenimiento de SLAs, UCs y OLAs


CIBERTEC


126

3.5 Contratos y Acuerdos Los UCs y los OLAs se deben desarrollar para permitir alcanzar los objetivos de los SLAs. Los proveedores internos normalmente estarán proporcionando servicios de instalaciones (alojamiento) y varias formas de soporte técnico. Si es necesario, puede que haga falta modificar los SLAs para alinearlos con los contratos existentes pero es preferible renegociar el contrato. Ventajas claras surgen de alinear la dirección de contratación de proveedores con la dirección de SLAs.

Figura 13.2 Contratos y Acuerdos

3.6 Programa de Mejora de Servicio El proceso de Gestión de Nivel de Servicio a menudo genera un buen punto de partida para un Programa de Mejora de Servicio (SIP). Cuando se ha identificado una dificultad que impacta negativamente la calidad del servicio, la Gestión de Nivel de Servicio debe, conjuntamente con la Gestión de Problemas y Disponibilidad, iniciar un SIP para identificar e implementar las acciones necesarias para superar las dificultades y restaurar la calidad del servicio. Las iniciativas de SIP también pueden centrarse en aspectos como capacitación del Usuario, pruebas (testing) de sistemas y documentación. En estos casos, se involucran a las personas relevantes y se proporciona el feedback adecuado para hacer mejoras en el futuro. En cualquier momento, un número de iniciativas separadas que forman parte del SIP se pueden realizar en paralelo para afrontar las dificultades de varios servicios.

CIBERTEC


127

3.7 Elementos de un SLA 3.7.1 General Introducción     





Partes en el acuerdo Título y breve descripción del acuerdo Signatarios o firmantes Fechas: inicio, fin, revisión Alcance del acuerdo: qué cubre y qué excluye Responsabilidades del proveedor del servicio y del Cliente Una descripción de los servicios que cubre Informes y revisiones del servicio: Contenido, frecuencia y distribución de informes del servicio, y la frecuencia de reuniones de revisión del servicio. Incentivos y penalidades por rendimiento: Detalles de los acuerdos respecto a incentivos o penalidades financieras, basados en el rendimiento contra los niveles de servicio.

3.7.2 Soporte del servicio 





Horas de servicio: 24x7, 8x5, requerimiento de extensiones del servicio, horas especiales (feriados), calendario del servicio. Soporte: Horas de soporte, requerimiento de extensiones del soporte, horas especiales (feriados), tiempos de respuesta y de reparación (según prioridad). Cambios: Objetivos para aprobar, manejar e implementar RFCs (según categoría o urgencia/prioridad).

3.7.3 Entrega del servicio 











Disponibilidad: Objetivos de disponibilidad dentro de las horas acordadas (normalmente expresados en porcentajes), periodo y método de medición. Confiabilidad: Número de interrupciones del servicio, MTBF, MTBSI. Rendimiento: Número de transacciones a ser procesadas, número de usuarios concurrentes, cantidad de datos a ser transmitidos por la red. Tiempo de respuesta por transacción: Percentiles(p.e. 95% <= 2 seg.). Contingencia y seguridad: Breve mención de los Planes de Continuidad del Servicio TI, cómo invocarlos, y cobertura de aspectos de seguridad (p.e. backups, passwords). Cobros: Detalles de la fórmula y periodos de cobro.


CIBERTEC


128

3.8 Monitoreo Las mediciones del Nivel de Servicio tienen que ser correctamente definidas y tienen que cumplir con los valores objetivos fijados. Los Niveles de Servicio tienen que medirse desde la perspectiva del Cliente, no solo trata de asuntos técnicos, sino también de asuntos de procedimiento, p.e. siempre y cuando no se haya informado al Cliente que el servicio se ha restaurado, entenderá que sigue sin funcionar. También datos como tiempos de respuesta, tiempos de escalamiento y soporte se deben volver mensurables. A fin de obtener una visión completa, la información de gestión de los sistemas como de la Gestión de Servicios deben ser combinados.

3.9 Informes de servicio y de gestión Los informes de servicio (de Clientes) se deben producir de forma regular como se acuerde en el SLA. Estos informes comparan los niveles de servicio acordados y los niveles de servicio que se miden en realidad. Estos informes pueden incluir: 



 



La disponibilidad o no-disponibilidad medida durante una cierta cantidad de tiempo (Downtime) Los tiempos de respuesta medios durante las horas punta de carga de trabajo Las velocidades de transacción durante las horas punta El número de errores funcionales en el servicio TI Frecuencia y duración de la degradación del servicio (cuando los servicios rinden por debajo de un nivel determinado) El número medio de usuarios en horas punta de carga de trabajo El número de intentos con o sin éxito de violación de la seguridad

Los informes de gestión, a diferencia de los de nivel de servicio, no se muestran al Cliente pero se utilizan para controlar y mejorar los servicios internos. Pueden tener métricas sobre los niveles de servicio que soportan en realidad y sobre tendencias como:  



Número de SLAs concluidos Número de veces en las que no se cumplió con el SLA Costo de monitoreo y medición del SLA Satisfacción del Cliente al realizar encuestas y registros de quejas Estadísticas de Incidentes, Problemas y Cambios

4. ROLES Y RESPONSABILIDADES 4.1 Rol del Gestor de Nivel de Servicio Implementar y mantener el proceso de la SLM en el nivel requerido por la organización.

4.2 Responsabilidades 





Crea y mantiene un catálogo de los servicios existentes ofrecidos por la organización. Formula, acuerda y mantiene una estructura SLM apropiada para la organización. Negocia, acuerda y mantiene los SLAs con el Cliente. Negocia, acuerda y mantiene los OLAs con el proveedor TI. Negocia y acuerda con el Cliente y el proveedor TI los SLRs.

CIBERTEC


129

 



 



Analiza y revisa el rendimiento del servicio contra los SLAs y OLAs. Realiza informes periódicos sobre el rendimiento y los logros del servicio para el Cliente y el proveedor TI en un nivel apropiado. Organiza y mantiene el proceso periódico de revisión de Nivel del Servicio regularmente con el Cliente TI y el proveedor TI. Inicia las acciones requeridas para mantener o mejorar los niveles del servicio. Conduce las revisiones anuales del proceso de Nivel del Servicio y negocia, acuerda y controla las enmiendas necesarias. Coordina los cambios temporales de los niveles del servicio (p.e. horas extra de soporte requeridas por el cliente, reducción de los Niveles de Servicio durante un periodo de mantenimiento requerido por el proveedor TI, etc.).

4.3 Habilidades clave  



 



 





Habilidades de Gestión de Relaciones. Buen conocimiento de los servicios de los Proveedores TI para entender como los requerimientos del Cliente afectarán la entrega. Conocimiento del negocio del Cliente y cómo TI contribuye con el mismo. Excelentes habilidades de comunicación y negociación. Paciencia, tolerancia y capacidad para adaptarse. Conocimiento y experiencia en la gestión de proveedores y contratos. Buenas habilidades administrativas y de gestión de personal.

Buenos conocimientos de los principios y procesos estadísticos y analíticos. Buenas habilidades para la realización de presentaciones. Buenas habilidades numéricas. Habilidad de interactuar satisfactoriamente en todos los niveles de la organización del Cliente y del proveedor TI. Conocimientos técnicos y habilidades para traducir los requerimientos y especificaciones técnicas en conceptos fácilmente entendibles por el negocio y viceversa. con respecto a la calidad del servicio y formas de mejorarlo, teniendo Innovador en cuenta los límites de la organización (recursos, presupuestos, leyes, etc.).


CIBERTEC


130

Resumen



El Acuerdo de Nivel de Servicio (Service Level Agreement - SLA) esun acuerdo entre la organización TI y el Cliente, en el que se detalla el servicio o los servicios a brindar. El SLA describe los servicios en términos no técnicos, de acuerdo con la percepción del Cliente, y durante el tiempo que dure el acuerdo sirve como estándar para medir y ajustar los servicios TI.



El Acuerdo de Nivel Operacional (Operational Level Agreement - OLA) es un acuerdo con un departamento TI interno que detalla los acuerdos sobre la provisión de ciertos elementos de un servicio, como un OLA sobre la disponibilidad de la red o la disponibilidad de los servidores de impresoras.



) es un contrato con El Contrato de Soporte (Underpinning Contract - UC proveedores externos que define los acuerdos sobre la provisión de ciertos elementos de un servicio, por ejemplo el arreglo de estaciones de trabajo, o el alquiler de líneas de comunicación.



Si desea saber más acerca deestos temas, puede consultar la siguiente página. 


CIBERTEC



131


4 TEMA

14

GESTIÓN DE LA DEMANDA LOGRO DE LA UNIDAD DE APRENDIZAJE Al término de la unidad, el alumno explicará la principal función de la Gestión de la Demanda, priorizando los activos de TI según la demanda del servicios.

TEMARIO Objetivos Conceptos Básicos Descripción del Proceso

ACTIVIDADES PROPUESTAS Los alumnos seleccionarán una empresa y la describirán en base a los conceptos tratados en el capítulo. Analizar el caso propuesto por el profesor en clase.


CIBERTEC


132

Al contrario que los bienes materiales, los servicios no pueden producirse con antelación y almacenarse hasta que el cliente los solicita. Es un proceso simultáneo: la producción y el consumo tienen lugar al mismo tiempo, circunstancia que complica enormemente la planificación de la demanda. La Gestión de la Demanda se encarga de predecir y regular los ciclos de consumo, adaptando la producción a los picos de mayor exigencia para asegurar que el servicio se sigue prestando de acuerdo a los tiempos y niveles de calidad acordados con el cliente. Por lo general, cuanto mejor funciona un servicio, mayor demanda genera. Ésta, a su vez, provoca exigencias de capacidad que los responsables compensan,como es natural, incrementando los activos del servicio. Se genera así un ciclo de consumo-producción en el que el consumo es un estímulo positivo para la producción y viceversa.

1. OBJETIVOS El objetivo principal de la Gestión de la Demanda es optimizar y racionalizar el uso de los recursos TI. Su papel cobra especial protagonismo cuando existen problemas de capacidad en la infraestructura TI, tanto por exceso como por defecto. El srcen de los problemas que la Gestión de la Demanda debe subsanar a corto plazo se puede encontrar en:   

Degradación del servicio por aumentos no previstos de la demanda. Interrupciones parcialesdel servicio por errores de hardware o software. Incremento innecesario de costes ocasionado por unpero exceso capacidadno pensado para compensar los picos de demanda quederealmente aporta valor al servicio.

La Gestión de la Demanda es la encargada en estos casos de redistribuir la capacidad para asegurar que los servicios críticos no se ven afectados o, cuando menos, lo sean en la menor medida posible. Para llevar a cabo esta tarea de forma eficiente es imprescindible que la Gestión de la Capacidad conozca las prioridades del negocio del cliente y pueda actuar en consecuencia. Pero una tarea no menos importante es la Gestión de la Demanda a medio y largo plazo. Un aumento de la capacidad siempre conlleva costes que muchas veces resultan innecesarios. Una correcta monitorización de la capacidad permite reconocer puntos débiles de la infraestructura TI o cuellos de botella y evaluar si es posible una redistribución a largo plazo de la carga de trabajo que permita dar un servicio de calidad sin aumento de la capacidad. Por ejemplo, una incorrecta distribución de tareas puede provocar que el ancho de banda contratado la organización se muestre asociados insuficienteaen horas punta porque se estén enviandopor miles de correos electrónicos procesos automáticos (tales como campañas de marketing promocional, informes de rendimiento para clientes, etcétera). En la mayoría de los casos esos procesos pueden desplazarse fuera de horas punta sin degradar la calidad del servicio, ahorrando a la organización una gravosa ampliación del ancho de banda. CIBERTEC



133

2. CONCEPTOS BÁSICOS Paquete de Servicio (SP) Es una descripción completa de un servicio TI que ya está disponible para ser entregado a los clientes. Los SP comprenden un Paquete de Nivel de Servicio (SLP), uno o más servicios esenciales y uno o más servicios de soporte. Paquete de Nivel de Servicio (SLP) Consiste de en Servicio la definición de un utilidad yconforme garantíaa específicos para de un Paquete concreto. Losnivel SLP de se diseñan las necesidades un Patrón de Actividad de Negocio (PBA) particular. Paquete de Servicio Esencial (CSP) Es una descripción detallada de un servicio básico que puede ser compartido por dos o más Paquetes de Nivel de Servicio. Línea de Servicio (LOS) Es un servicio esencial o de soporte común a varios Paquetes de Nivel de Servicio (SLP). Cada LOS tiene asignado un Gestor de Producto.

3. DESCRIPCIÓN DEL PROCESOS 3.1 Análisis de actividad El primer paso a la hora de acometer la racionalización de los recursos de una organización por TI consiste en que conocer cuáles son las necesidades de rendimiento ocasionadas los servicios presta. El enfoque más extendido para predecir la demanda es el basado en actividades, y consiste en analizar los patrones de actividad del negocio (PBAs) y predecir la demanda tomando como referencia los activos del servicio que soportan esas actividades.

Figura 14.1 Análisis de actividades basado en actividades CARRERAS PROFESIONALES

CIBERTEC


134

La Gestión de la Demanda basada en actividades se encarga de: 





Monitorizar y analizar los patrones de actividad del proceso de negocio con el fin de predecir la demanda de servicios. Asignar las unidades de demanda adicionales generadaspor la actividad del negocio a elementos de la capacidad del servicio. Asegurarse de que, en lo que se refiere a patrones de demanda, los planes de negocio del cliente están alineados con los planes de gestión del servicio del proveedor.

Por otro lado, también es clave para que la Gestión de la Demanda pueda tomar decisiones estratégicas acertadas que en esta primera etapa se recabe y analice información sobre el mercado en el que opera el servicio: 



Necesidades de los clientes a los que se dará servicio, agrupándolos por segmentos de mercado. Alternativas de las que disponen los clientes de esos segmentos, tanto si se trata de servicios ofrecidos por sus propias organizaciones como de otros proveedores de la competencia.

3.2 Desarrollo de la Oferta Una vez realizado un análisis del negocio y concretados una serie de patrones de demanda del mismo, es el momento de racionalizar los servicios. El punto de partida consiste en distinguir dos grandes grupos de servicios: 



Servicios esenciales, sin los que el negocio no puede satisfacer las necesidades del cliente. Representan el valor que el cliente desea y por tanto, por lo que está dispuesto a pagar. Servicios de soporte, que pueden estar orientados a dar continuidad al servicio o a mejorar su propuesta de valor (p.ej. Centro de Atención al Usuario). Representan aquellas características que diferencian nuestro producto de otros similares ofrecidos por la competencia.

La Gestión de la Demanda toma estos elementos y, con la información que tiene a su alcance acerca del mercado y las necesidades de los clientes, define una serie de paquetes de servicio adaptados a los distintos segmentos de clientes. Los paquetes de servicio contienen una descripción detallada del servicio TI, que ha de incluir necesariamente: 

 

Paquete de nivel de servicio (SLP). En él se especifican los niveles de utilidad y garantía de los que disfrutarán los usuarios de los servicios. Uno o más servicios esenciales y su descripción. Uno o más servicios de soporte y su descripción.

Este proceso, que podemos llamar empaquetado o paquetización, permite a la organización adaptar el suministro de un mismo servicio a distintos casos de negocio, con diferentes niveles de servicio, precios, etc. CARRERAS PROFESIONALES

CIBERTEC


135

Adicionalmente, al definir una serie de servicios esenciales, se crea un Paquete de Servicio Esencial (CSP) cuyos activos son compartidos para todos los paquetes de servicio.

Figura 14.2 Empaquetado de Servicios

La Gestión de la Demanda debe comprobar, por último, que los distintos paquetes de servicio deben ajustarse debidamente a las restricciones financieras (p.ej. políticas de precios y facturación), técnicas (p.ej. conexión) y físicas (p.ej. disponibilidad) a las que está sometida la organización TI. Dado el caso, la Gestión de la Demanda puede introducir desde la raíz algunas técnicas que ayuden a regular el consumo y racionalizar los recursos. Algunas de estas técnicas son:

  

Escalonar el inicio de la jornada laboral Dar prioridad a los informes y procesos por lotes Ejecutar durante la noche (o fuera de las horas de trabajo) aquellos informes y trabajos que no sean críticos.

Restringir aquellas actividades que no sean urgentes durante los periodos de mayor actividad. }


CIBERTEC


136

Resumen 

Encargada de predecir y regular el consumo de los servicios adaptando la producción del servicio según os picos de mayor exigencia y consumo para asegurar que el servicio se sigue prestando de acuerdo a los tiempos y niveles de calidad acordados con el cliente



El proceso cuenta con dos principales actividades: 

Análisis de la actividad

Consiste en conocer cuáles son las necesidades de rendimiento ocasionadas por los servicios que presta. 

Desarrollo de la oferta Consiste en racionalizar los servicios en función del análisis de la demanda, los servicios que cuenten con mayor demanda contaran con mayor capacidad en cuanto a sus recursos, cuando estos servicios bajen en cuanto a su demanda ya no será necesario el aumento de la capacidad permitiendo mejorar la capacidad de otros servicios más urgentes.






CIBERTEC


137


4 TEMA

15

GESTIÓN DEL CONOCIMIENTO LOGRO DE LA UNIDAD DE APRENDIZAJE Al término de la unidad, el alumno será capaz de reconocer la importancia de gestionar el conocimiento o experiencias vividas para las decisiones o soporte en el futuro.

TEMARIO Objetivos Conceptos Básicos Descripción del Proceso



CIBERTEC


138

El aspecto más beneficioso de trabajar en equipo reside en la oportunidad de compartir el saber, las ideas y la experiencia acumulada de todos los integrantes del mismo. Este fenómeno se reproduce, a mayor escala, cuando son todos los miembros de una organización los que contribuyen a crear un acervo común de conocimientos. La experiencia y conocimientos del personal, información de contacto y servicios ofrecidos por los proveedores, así como detalles sobre la rutina diaria (comportamiento de los usuarios, rendimiento de la organización, etc.) constituyen información muy útil para ahorrar tiempo y esfuerzo. La cantidad de información una organización puede como generar, incluso de dimensiones modestas, es que suficientemente voluminosa para que una resulte imprescindible una gestión centralizada de la misma. La Gestión del Conocimiento se encarga de establecer unos criterios de registro y de acometer labores periódicas de clasificación, evaluación y mejora de los datos disponibles. Una buena Gestión del Conocimiento ha de colaborar estrechamente con los procesos de las otras fases del Ciclo de Vida para documentar y analizar: 



Los errores detectados y las soluciones aportadas en cada caso, principalmente desde la Gestión de Incidencias y Errores. De esta manera, puede confeccionarse un registro que recibe el nombre de KEDB y que ayuda a minimizar el tiempo de catalogación y solución de los mismos en el futuro. Asimismo, la Gestión de Problemas puede hacer un seguimiento del histórico de errores, establecer relaciones y determinar con mayor facilidad las causas de los mismos. La Gestión de Cambios aportará documentación sobre las propuestas de cambio llegadas desde de Mejora Continua del Servicio, tanto si han sido preaprobadas comolasifase se han desechado.



La información relativa a las posibles consecuencias del error, que puede proporcionar al Centro de Servicios la posibilidad de anticiparse al cliente.

La Gestión del Conocimiento es la encargada, por último, de centralizar toda esta información en un repositorio denominado Sistema de Gestión del Conocimiento del Servicio (SKMS).

1. OBJETIVOS La Gestión del Conocimiento es la encargada de reunir, analizar, almacenar y compartir el conocimiento e información de la organización. El objetivo principal del proceso consiste en mejorar la eficiencia, reduciendo la necesidad de redescubrir el conocimiento. La Gestión del Conocimiento contribuye a mejorar la calidad de las decisiones que se adoptan en una organización, al garantizar que aquellos a quien corresponde tomarlas disponen de información segura y fiable.


CIBERTEC


139

Sin embargo, una organización puede tener las herramientas adecuadas para registrar y organizar los datos, pero los buenos propósitos pueden no llegar a materializarse nunca si no existe una unidad de Gestión del Conocimiento que impulse, coordine y estructure el proceso para:







Garantizar el personal hacedisponibles. uso de las herramientas, tanto para registrar como para que consultar los datos Evaluar los datos recogidos, velando por que estén permanentemente actualizados. Analizar las necesidades de información de ciertos departamentos y coordinar la correcta transferencia de conocimiento desde aquellos que poseen los datos.

Estas funciones requieren, de quienes desempeñan las labores de Gestión del Conocimiento, un entendimiento profundo de los procesos que se desarrollan en la organización, así como una constante monitorización del registro, organización y aprovechamiento de los datos. Los beneficios obtenidos de una correcta Gestión del Conocimiento son numerosos: 

 

No se duplica el trabajo innecesariamente. Sisurge un problema que ya se presentó en el pasado, pueden recuperarse con facilidad los detalles de la solución aplicada entonces, ahorrando tiempo y esfuerzo. Mejor aprovechamiento de losde recursos existentes. en caso de faltar los Prevención de situaciones desinformación “propietarios” de los datos de acceso a una aplicación, de contacto con un

cliente, etc. Las principales dificultades que se presentan a la hora de abordar la Gestión del Conocimiento consisten en: 







Los miembros del personal están saturados de trabajo y no disponen de tiempo para documentar los datos o dan prioridad a otras tareas más urgentes. Los miembros del personal no confían en los datos registrados, de modo que recurren a otras vías a la hora de buscar información. Los datos están mal estructurados, son incompletos o no están adaptados a la audiencia a la que van destinados, por lo que en la práctica resultan inservibles. Los datos se registran pero no se revisan, por lo que la información disponible está desactualizada o incompleta.


CIBERTEC


140

2. CONCEPTOS BÁSICOS Sistema de Gestión del Conocimiento del Servicio (SKMS) Un Sistema de Gestión del Conocimiento del Servicio o SKMS es una herramienta que proporciona funcionalidades de presentación, procesamiento y gestión para interactuar con la Base de Datos de Gestión del Conocimiento del Servicio de la organización IT. Un SKMS está estructurado de forma estratificada, en varias capas que se articulan en torno a la base de datos donde se almacena la información propiamente dicha: 







Capa de presentación. Es la interfaz que permite buscar, explorar, almacenar, recuperar y actualizar los datos a través de una serie de interfaces específicas para cada proceso interesado: vista de Gestión de la Calidad, vista de Activos y Configuración, etc. Capa de procesamiento de conocimiento. Las funciones asociadas a esta capa incluyen el análisis de los datos, la elaboración de informes, la planificación, el modelado de los datos y la monitorización de los cambios a través de paneles de control. Capa de Integración de la Información. Es donde está la Base de Datos de Gestión, propiamente dicha, y donde se desarrollan todas las actividades de integración de datos: minería de datos, gestión de metadatos, sincronización, etc. Herramientas y fuentes de datos e información. En esta capa es donde se estructura la información

Figura 15.1 SKMS y su alcance en el c iclo de vida del Servicio


CIBERTEC


141

3. DESCRIPCIÓN DEL PROCESOS 3.1 Estrategia del conocimiento A la hora de planificar el proceso de Gestión del Conocimiento es preciso definir, desarrollar y difundir: 







Una serie de políticas generales referentes a los datos: qué registrar, cuándo hacerlo, cómo estructurar los datos, etc. Las condiciones de administración: qué clase de información es susceptible de ser corregida o eliminada. Los roles: quién registra la información, quién la revisa, quién la valida, quienes la pueden consultar libremente. Procedimientos de registro, revisión y validación de la información.

3.2 Transferencia del conocimiento Es tarea de la Gestión del Conocimiento, en primera instancia, transmitir a todos los miembros de la organización TI la importancia de registrar la información relacionada con su trabajo en las herramientas dispuestas para ello. Por otro lado, es también su labor instalar una cultura de aprendizaje constante entre los miembros del personal. No sólo se trata de hacer que los empleados registren los datos, sino también motivarlos a que acudan a las fuentes de conocimiento para completar aquello que no saben. Asimismo, la Gestión del Conocimiento se ocupa de: 

 

Detectar las necesidades de conocimiento existentes en la organización, tanto a nivel particular como grupal. Conocer en todo momento quién o quiénes poseen esa información. Establecer el canal adecuado para que los “propietarios” del conocimiento

puedan transferirlo a quienes lo necesitan: seminarios, anuncios, boletín, periódico.

3.3 Gestión del conocimiento La Gestión del Conocimiento debe garantizar que la información disponible sea completa y esté puntualmente actualizada, ya que de otro modo puede resultar inútil. Las labores de gestión comportan una monitorización exhaustiva de los cambios registrados en el SKMS, y una serie de tareas asociadas a esta revisión:   

Iniciar y gestionar procesosdedelas borrado de información. Determinar la periodicidad revisiones. Detectar y subsanar incoherencias en los datos registrados.


CIBERTEC


142

3.3 Uso del SMKS En el SKMS han de estar disponibles todos los documentos generados por el resto de procesos: 



 



Gobierno de TI: Cartera de Servicios, informes, CSI, Riesgos y otras cuestiones. Calidad: Políticas, procesos, procedimientos, formularios, plantillas, listas de comprobación. Servicios: Catálogo de Servicios, SPs, informes del servicio. Activos y Configuración: Activo financiero, información del CMS, informes de estado, datos de la CMDB, fuentes definitivas. Centro de Servicios / Soporte: Catálogo de Servicios, clientes, usuarios, grupos de interés, CIs, incidencias, problemas, cambios, entregas, rendimiento de las configuraciones.

3.3 Control del Proceso Las métricas de referencia para evaluar si la Gestión del Conocimiento está desarrollando correctamente su labor son: 













Número de solicitudes de entradas nuevas recibidas en un periodo específico. Número de solicitudes de modificaciones/actualizaciones enviadas en un periodo específico. Número de entradas nuevas publicadas en la base de datos del SKMS en un periodo específico. Número de entradas modificadas en la base de conocimiento en un periodo específico. Número de incidentes que recurrieron a entradas existentes en la base de conocimiento en un periodo específico. Tiempo ahorrado gracias al uso de la base de conocimiento. Se calcula comparando el tiempo medio de resolución de incidentes que se cerraron empleando la base de conocimiento con los que no la usaron. Número de peticiones de autoayuda que declararon que la base de conocimiento ayudó en la resolución de un asunto en un periodo determinado.


CIBERTEC


143

Resumen 

Encargada de gestión el conocimiento de gestión de TI ed toda la organización, estructurando la información, experiencia, documentos, problemas ubicación de activos, comportamientos los cuales podrán incidentes, ser de mucha utilidad en el futuro.



El proceso cuenta con dos principales actividades: 

Estrategia del conocimiento Políticas generales asociado a los datos y como estos deben de estructurarse, condiciones de administración, definición de roles y procesos.



Transferencia del conocimiento Transmite a todos los miembros de la organización de TI la importancia de registrar toda la información relacionada.



Gestión del conocimiento Garantiza que la información esté disponible y sea completa y actualizada.



Uso de SMKS Se refiere al uso de toda la información estructurada, permite elaborar informes






CIBERTEC


144


4 TEMA

16

MEJORA CONTINUA DE LOS SERVICIOS DE TI LOGRO DE LA UNIDAD DE APRENDIZAJE Al término de la unidad, el alumno reconoce el proceso de mejora continua necesario para los servicios de TI pueden alinearse al negocio o cambios en los procesos de la organización.

TEMARIO Objetivos Definiciones



CIBERTEC


145

Los tiempos modernos nos exigen continuos cambios y éstos deben tener un solo objetivo en el campo de la gestión de servicios TI: ofrecer mejores servicios adaptados a las siempre cambiantes necesidades de nuestros clientes y todo ello mediante procesos internos optimizados que permitan mayores retornos a la inversión y mayor satisfacción del cliente. Pero este objetivo de mejora sólo se puede alcanzar mediante la continua monitorización y medición de todas las actividades y procesos involucrados en la prestación de los servicios TI:    

Conformidad: los procesos se adecúan a los nuevos modelos y protocolos. Calidad: se cumplen los objetivos preestablecidosen plazo y forma. Rendimiento: los procesos son eficientes y rentables para la organización TI. Valor: los servicios ofrecen el valor esperado y se diferencian de los de la competencia.

Los resultados de esta fase del ciclo de vida han de verse reflejados en Planes de Mejora del Servicio que incorporen toda la información necesaria para:  



Mejorar la calidad de los servicios prestados. Incorporar nuevos servicios que se adapten mejor a los requisitos de los clientes y el mercado. Mejorar y hacer más eficientes los procesos internos de la organización TI.

1. OBJETIVOS Los principales objetivos de la fase de Mejora Continua del servicio se resumen en: 



 

Recomendar mejoras para todos los procesos y actividades involucrados en la gestión y prestación de los servicios TI. Monitorizar y analizar los parámetros de seguimiento de Niveles de Servicio y contrastarlos con los SLAs en vigor. Proponer mejoras que aumenten el ROI y VOI asociados a los servicios TI. Dar soporte a la fase de estrategia y diseño para la definición de nuevos servicios y procesos/ actividades asociados a los mismos.

2. DEFINICIONES 2.1 Ciclo de Deming El ciclo PDCA: Planificar (Plan), Hacer (Do), Verificar (Check) y Actuar (Act), también conocido como ciclo de Deming en honor a su creador, Edwards Deming, constituye la columna vertebral de todos los procesos de mejora continua:   

Planificar: definir los objetivos y los medios para conseguirlos. Hacer: implementar la visión preestablecida. Verificar: comprobar que se alcanzan los objetivos previstos con los recursos asignados.


CIBERTEC




146

Actuar: analizar y corregir las desviaciones detectadas así como proponer mejoras a los procesos utilizados.

Las fases del ciclo de vida del servicio son un reflejo de esta estructura básica:

Figura 16.1 Ciclo de Deming

En cierta medida todos y cada uno de los procesos de gestión de los servicios TI deben reproducir esa estructura asegurando que cada una de estas fases se encuentra correctamente documentada. La fase de Mejora Continua del Servicio juega un papel esencial en las etapas de verificación y actuación aunque también debe colaborar en las otras etapas de planificar y hacer:   

Ayudando a definir los objetivos y las métricas de cumplimiento asociadas. Monitorizando y evaluando la calidad de los procesos involucrados. Definiendo y supervisando las mejoras propuestas.

2.2 Métricas No se puede mejorar aquello que no se conoce y no se puede llegar realmente a conocer aquello que no se puede medir. Es indispensable que la organización TI defina una serie de métricas que permitan determinar si se han alcanzado los objetivos propuestos así como la calidad y rendimiento de los procesos y tareas involucrados. Una organización TI debe utilizar tres tipos de métricas:


CIBERTEC








147

Tecnológicas: que miden la capacidad, disponibilidad y rendimiento de las infraestructuras y aplicaciones. De procesos: que miden el rendimiento y calidad de los procesos de gestión de los servicios TI. De servicios: que evalúan los servicios ofrecidos en términos de sus componentes individuales.

Las métricas deben adaptarse a los Factores Críticos de Éxito (CSFs) que describen aquello que “debe pasar” para que se cumplan los objetivos preestablecidos.

Asociados a cada CSF es necesario definir una serie de Indicadores Críticos de Rendimiento (KPIs) que permitan evaluar el rendimiento y la calidad de los procesos así como su valor y adecuación. Los KPIs deben medir aspectos cualitativos y cuantitativos y deben permitir evaluar el cumplimiento de los objetivos. Si la organización TI se ha propuesto, por ejemplo, como CSF la mejora en la atención al usuario los KPIs incluirían:   

Tiempo medio de resolución de los incidentes. Adecuación de los procesos de escalado. Percepción de los usuarios respecto a la atención prestada mediante encuestas de satisfacción.

Es importante que los KPIs no obvien aspectos clave y que su cumplimiento sea una medida objetiva del cumplimiento de los CSFs asociados. Por ejemplo, en el caso anterior no se hace mención a los costes y una reducción de los mismos podría ser parte de los objetivos preestablecidos por lo que en ese caso los KPIs utilizados no proporcionarían todas las métricas necesarias. 2.3 DIKW DIKW es el acrónimo de: 







Datos (Data): o materia prima, que está compuesta de mensajes o símbolos sin procesar, por ejemplo, la lista de elementos de configuración de una infraestructura TI. Información (Information):que proviene del análisis de un conjunto de datos, que, por ejemplo, se correspondería en el caso anterior a una distribución de proveedores por inversiones y tecnologías utilizadas. Conocimiento (Knowledge):este proviene del proceso de interpretación de la información en términos de experiencia y reflexión. Por ejemplo, ciertos proveedores tecnológicos involucrados en servicios clave corren riesgo por no saberse adaptar al mercado y utilizar tecnologías que pueden tornarse en obsoletas. Sabiduría (Wisdom): la capacidad de tomar la mejor decisión posible basada en el conocimiento, información y datos disponibles. Por ejemplo, optar por cambiar de proveedor tecnológico para minimizar los riesgos asociados a depender de proveedores que no están correctamente alineados con las necesidades futuras del negocio.


CIBERTEC


148

Figura 16.2 Flujo de DIKW La sabiduría es el componente esencial en lo que respecta al proceso de Mejora Continua. A partir de los datos, información y conocimiento obtenidos durante todas las fases del ciclo de vida del servicio se deben elaborar unos Planes de Mejora que incorporen los cambios necesarios para aumentar la satisfacción del cliente mejorando el rendimiento, calidad y gestión de todos los procesos implicados. 2.4 Modelos CSI Nunca podremos saber si hemos llegado si primero no decidimos adónde queremos ir. El proceso de Mejora Continua requiere de una serie de metas y objetivos que determinen la dirección de avance y sirvan de pilares para el resto de las actividades involucradas en el mismo. Pero la determinación de esas metas y objetivos está asimismo sometido a un proceso de constante revisión que forma parte de un ciclo descrito por el modelo CSI. Este ciclo continuo se compone de 6 fases: 1. Establecer la visión: se deben establecer metas y objetivos alineados con el modelo de negocio de la organización. 2. Conocer el estado actual: saber de dónde partimos (organización, recursos, capacidades, procesos,…) para poder utilizar ese estado como referencia de base.

3. Establecer objetivos cuantificables: a partir de la visión establecer hitos y entregables que permitan realizar un seguimiento del proceso. 4. Planificar: establecer un Plan de mejora del Servicio (SIP) que determine qué acciones son necesarias para obtener los objetivos deseados en los plazos previstos y con el nivel de calidad predeterminado. 5. Comprobar: determinar si se han cumplido los planes y se han seguido lo procesos establecidos. 6. Integrar los cambios: asegurase de que los cambios realizados forman parte de la cultura de la organización permitiéndonos así reiniciar el ciclo con nuevo impulso. CARRERAS PROFESIONALES

CIBERTEC


149

Figura 16.3 Modelos CSI

2.5 Herramientas y Metodologías Una mejora propuesta no siempre implica una mejora real. Incluso tras exhaustivos procesos de análisis y planificación de las posibles mejoras se han podido obviar aspectos críticos o imponderables que pueden afectar negativamente a los servicios y procesos. Es indispensable disponer de metodologías y herramientas que permitan valorar las mejoras introducidas y comparar el “estado de situación” antes

y después de la introducción de los cambios. Es imposible enumerar todas las herramientas y metodologías disponibles por lo que aquí nos centraremos en algunas de las más populares. Éste listado, puede servirnos como punto de partida para ahondar en el tema. 2.5.1 Análisis comparativo Consiste en comparar el rendimiento de las actividades y procesos llevados a cabo por la organización con aquellos que han sido considerados como “mejores prácticas”.

Este análisis puede ser realizado a distintos niveles: 



Interno: comparando con otros procesos o funciones de la propia organización. Externo: comparando con otras organizaciones competidoraso directamente con los estándares del sector.


CIBERTEC


150

Los resultado de este análisis deben incluir:   

Información sobre el rendimiento de la organización. Factores de éxito y riesgos. Propuestas sobre nuevas líneas de actuación.

2.5.2 Análisis de brechas (Gap analysis) El análisis de brechas se basa en contrastar el “estado de la situación actual” y el “estado esperado o ideal”. Las diferencias entre ambas situaciones suponen las

brechas que se desea eliminar. Este análisis se puede realizar a diferentes niveles: estratégico, táctico y operativo. 2.5.3 Análisis DAFO Se centra en el análisis de las Debilidades, Amenazas, Fortalezas y Oportunidades. Las Debilidades y Fortalezas son de carácter interno y dependientes en este caso de la propia organización TI mientras que las Amenazas y Oportunidades provienen de factores de mercado u otros factores externos. El análisis DAFO puede realizarse a diferentes niveles, desde una componente o función hasta englobar a toda la organización TI. Sus principales objetivos consisten en:    

Determinar las Debilidades y buscar métodos para eliminarlas. Valorar las Amenazas e intentar minimizar su impacto. Conocer las propias Fortalezas y buscar la mejor manera de rentabilizarlas. Estudiar las Oportunidades y desarrollar estrategias que permitan aprovecharlas.

2.5.4. Cuadro de Mando Integral (CMI) Es un método diseñado por Robert Kaplan y David Norton para evaluar la actividad de una organización en términos de cumplimiento de su plan estratégico. El Cuadro de Mando Integral (CMI) propone analizar la actividad de una organización respecto a diferentes perspectivas:    

Financiera Clientes Procesos Innovación y Aprendizaje

Es imprescindible determinar los KPIs asociados a cada una de estas perspectivas y cuáles son los objetivos buscados. Se recomienda buscar un conjunto reducido de KPIs que luego pueda ir ampliándose con el tiempo para evitar CMIs excesivamente complejos que dificulten su implementación.


CIBERTEC


151

Resumen



Objetivos: Recomendar mejoras para todos los procesos y actividades involucrados en la gestión y prestación de los servicios TI. Monitorizar y analizar los parámetros de seguimiento de Niveles de Servicio y contrastarlos con los SLAs en vigor. Dar soporte a la fase de estrategia y diseño para la definición de nuevos servicios y procesos/ actividades asociados a los mismos. 







Definiciones:



Ciclo de Deming El ciclo PDCA: Planificar (Plan), Hacer (Do), Verificar (Check) y Actuar (Act), también conocido como ciclo de Deming en honor a su creador, Edwards Deming, constituye la columna vertebral de todos los procesos de mejora continua



Métricas Es indispensable que la organización TI defina una serie de métricas que permitan determinar si se han alcanzado los objetivos propuestos así como la calidad y rendimiento de los procesos y tareas involucrados.



DIKW DIKW es el acrónimo de: Datos (Data), Información (Information), Conocimiento (Knowledge), Sabiduría (Wisdom).






CIBERTEC

Manual 2017-I 04 Gestioìn de Servicios de TI - Cibertec

Recommend Documents