UNIVERSIDAD TECNOLÓGICA DEL PERÚ

Curso:
Calidad de servicio de TI

Actividad:
Avance 3

Docente:
Yataco Gens Eduardo

Sección:
10840

Nombre:
· Padilla Ninaquispe Alfredo

· Díaz Paredes Alexa Sophia

· Ayala Gonzales Yanira Kimberly

· Camargo Meneses Angye Geraldyne

· Vasquez Chavez Jose Manuel

Lima, 09 de julio del 2022

 CASO 1: Constantemente se despliegan mejoras entre áreas de la

Organización sin previo informe a las áreas involucradas o afectadas en

las plataformas de gestión de tickets, ocasionando confusión en los

usuarios de estas herramientas.

Con el problema que identificado que es el desconocimiento entre áreas

sobre implementaciones o mejoras en herramientas proponemos a la empresa

CLARO PERÚ el uso de algunos puntos que ITIL V4 nos ofrece:

 CONTROL DE CAMBIO:

Está orientado en realizar mejoras en procesos o tecnologías para que se

adapten a las nuevas necesidades y herramientas en el mercado. Para ello, es

necesario que CLARO PERÚ tenga un comité encargado de la gestión del

cambio, para que analicen y realicen la documentación necesaria.

El comité de cambio deberá estar conformado por el Gerente General, los

gerentes de áreas y gestores de cambio (encargado de gestionar aspectos

relacionados a TI). Además, es necesario la participación de trabajadores de la

empresa según el cambio que se desea realizar.

Es necesario establecer una calendarización en los cambios que se va a

realizar, esto permitirá que ayude a planificar los cambios previamente y se

establezca los lineamientos que contendrán. Además, se debe de fortalecer la

comunicación entre las áreas para que conozcan los cambios y se eviten

conflictos como lo planteado en el caso.

  GESTIÓN DE LA IMPLEMENTACIÓN:

Este principio de ITIL busca la buena práctica de implementar o modificar

hardware, software, procesos con respecto los activos de la organización.

Entonces, encontramos una relación que tiene con el control de cambios.

Para realizar una implementación, es necesario establecer un documento que

detalle información de cuando, quienes son los involucrados y el plan de

capacitación al personal. Por lo que, cada vez que se mejora el software,

hardware y/o proceso, la información tiene que ser actualizada.

CASO 2: El equipo de infraestructura está constantemente solucionando

fallas de los servidores (Apagando Incendios) y los tipos de fallas

normalmente son recurrentes.

Practicas a utilizar Gestión de Riesgos y Gestión de activos de TI.

Se aplicaría la Practica de Gestión de riesgos, ya que esta busca asegurar que

la organización donde se está dando este incidente comprenda y maneje los

riesgos de una manera efectiva, esto podría ser bajo la aplicación de la ISO

27005 (Gestión de riesgos de la seguridad de la información)

Asimismo, la gestión de riesgos es primordial en todas las actividades de la

organización, en esta oportunidad el equipo de infraestructura soluciona los

incendios de los servidores, y como son recurrentes son se centran en

solucionarnos de manera momentánea, por lo que se debe de dar un correcto

análisis y evaluación de esos riesgos para poder mitigarlos y evitar esos

inconvenientes.
Esta práctica permitirá que la cultura se la empresa entienda que una correcta

gestión es vital para la sostenibilidad de la empresa,

Esta situación también se puede complementar con la Practica de GESTION

DE ACTIVOS DE TI, ya que su propósito es gestionar los activos de TI, en este

caso serían los servidores, en donde se planificará y administrara el ciclo de

vida del activo de TI, porque es posible que ese servidor sea antiguo y no

cuente con las características suficientes para desarrollar correctamente su

función.

Esto ayudara a la organización Hacer frente a los riesgos, asimismo esta

práctica incluye la gestión de software, hardware, redes, servicios en la nube,

también puede incluir activos que no sean de TI, como infraestructura e

información, y tecnología operativa

Posibles actividades propuestas:

 Definir un registro de los activos en términos de infraestructura e

instalaciones de almacenamiento de los activos.

 Controlar ciclo de vida de los activos, como cambios y actualización de

activos.

 Proporcionar informes de soporte (stock de activos y características)

CASO 3: No existe priorización de las fallas, se utiliza el esquema FIFO,

independientemente del impacto al negocio.

Debido al problema identificado en que la empresa no cuenta con un sistema

de priorización ante fallas en las distintas operaciones y teniendo esta solo un

esquema FIFO como método se plantea las siguientes acciones a tomar dentro

del ISO- 20000 que son las siguientes:

 Generación de informes del servicio

La generación de informes del servicio ayudará a que la empresa puede

establecer parámetros que permitan que dentro de una ficha informativa de

incidentes o fallas dentro de la empresa se pueda tener un correcto control

para su posterior análisis ayudando así que se tome acciones de mitigación o

prevención anticipándose a futuras repeticiones de problemas o en otros casos

nuevos permitir las comparaciones para que el tiempo de respuesta sea menor.

 Gestión de la continuidad

Esta gestión tiene con principal fin garantizar que las operaciones que se

desarrollan dentro de la empresa CLARO cumplan con un correcto

funcionamiento en sus labores y a su vez estas sean en los plazos

determinados.

Lo que se busca es implementar un sistema de atenciones que brinde un canal

de derivación en donde el tiempo estimado en ejecutar las soluciones se

reduzcan a fin de poder conseguir mayor satisfacción entre los clientes. Esto se

dará con un sistema de tickets que identifique cada atención con un nivel de

jerarquía y una derivación inmediata hacia las áreas designadas para su

ejecución. Asimismo, se puede llevar dentro de esta gestión guías ante casos

de desastres, estrategias o acciones a tomar ante casos de incidentes e

informes en donde se establezcan las características de cada incidente para

generar las acciones respectivas.

CASO 4: Los servicios internos provistos para esta organización no

tienen métricas, indicadores ni objetivos

En el caso anteriormente mencionado se indican que los servicios que brinda la

organización no tienen medidas de calidad, de esta manera no se sabe si los

servicios ofrecidos cuentan con una buena puntuación en satisfacción del

cliente, si se cumplen plazos establecidos por las áreas de la empresa.

Además, no se pueden medir los avances de los objetivos que tiene la

empresa.

 Generación de informes del servicio

Para generar informes del servicio se necesitan medidas de nivel de servicio

que ofrece la empresa (SLA, NPS, FCR) al extraer estos datos de cada

atención al cliente tenemos posibilidad de crear informes del servicio que se

está ofreciendo. Al crear estos informes la alta dirección tiene una visión más

clara a la hora de tomar decisiones y proponer mejoras para la empresa.

 Gestión de medición y reporte

No se puede desarrollar la gestión de medición y reporte, ya que al no

existir métricas e indicadores no se pueden generar reportes, es decir que al

momento de existir deficiencias no habrá forma de ubicar el origen de esto.

Otro punto es que no se podrá monitorear la productividad de cada área y de

los colaboradores. Finalmente, al momento de tomar decisiones se tendrá una

vista a ciegas ya que no se evidenciará requerimientos y áreas que requieren

más apoyo, esto finalizara como un desbalance en la empresa.

 GESTIÓN DE EVENTOS Y MONITOREO

En la gestión de eventos y monitoreo se presentan los eventos que

afectan a la empresa, sin embargo, al no existir métricas e indicadores al

presentarse un evento en la organización no se tiene información de

indicadores que apoyen a conocer el origen de los incidentes.

De igual manera no se pueden monitorear grandes datos que se

obtienen de clientes, al querer proponer mejoras no se tendrá puntos de partida

ya que no existen indicadores de cada área. Esto dificulta la focalización en

procesos que requieren una mejora y podríamos centrarnos solamente en la

mejora de un proceso que esta correctamente optimizado, desembocando en

un quiebre en la organización.

CASO 5: Los servicios internos no son medidos, el down time no es

monitorizado

Con la problemática mencionada, podemos definir al Down time del servicio

como a los períodos en los que un sistema no está disponible, este tiempo de

inactividad o del porcentaje de tiempo inactivo puede presentarse en un

servidor, una máquina en general o un servicio de internet. Para mitigar este

problema, se plantea las siguientes prácticas:

  Gestión de incidentes

El principal objetivo de esta práctica es volver a la situación normal lo

antes posible y minimizar el impacto sobre los procesos de negocio.

Esta se ocupa de todo evento que interrumpa, o pueda hacerlo, un

servicio. Por ello, para monitorear los servicios internos, especialmente

ante una caída del sistema que pueda perjudicar el negocio:

Identificar el incidente:

Identificación de la incidencia: En caso de caerse el sistema, se debe

registrar cuando se identifique la caída.

Registro de la incidencia: La incidencia se registrará junto a la

explicación de lo ocurrido (número de orden, prioridad, grupo o agente, usuario

afectado, acciones llevadas a cabo ya para intentar solventarla, fecha, hora,

estado, etc.).

Clasificación de la incidencia: El usuario debe realizar la

recategorización para aportar la mayor información posible, así como el resto

de los campos rellenados, por si hubiera algún campo erróneo o sin rellenar.

Priorización de la incidencia: El personal de soporte debe revisar el nivel

de prioridad, ya que los usuarios tienden a hacer uso de un nivel elevado de

urgencia sólo por tratar de resolver su incidencia lo antes posible. Esta puede

ser clasificada como: baja, media, alta y urgente. Asimismo, la prioridad de la

incidencia se basará en la urgencia (rapidez con la que el negocio requiera su

solución) y posible impacto (el número de usuarios a los que está afectando o

puede llegar a afectar).

 Diagnóstico inicial de la incidencia: en esta parte se realiza el primer

diagnóstico que determine lo que ha fallado y la forma más eficiente de

corregirlo

Escalado de incidencias: Si no se logra solucionar la incidencia, se

escala al siguiente nivel. Esta cuenta con 2 tipos de escalado:

Escalado funcional: se utiliza cuando no se podrá dar soporte a la

incidencia, por lo que será escalada a la línea de soporte que tenga

competencias para ello.

Escalado jerárquico: la incidencia es escalada nivel a nivel

Investigación y diagnóstico de las incidencias: Cada colaborador debe

investigar el fallo presentado y realizar un diagnóstico propio. Esta información

también debe quedar guardada en un registro de incidencias

Resolución y recuperación de las incidencias: Cuando se obtiene una

posible solución, se implementa y se prueba. Asimismo, se puede pedir al

usuario que realice algunas acciones para comprobar la solución. Si la solución

depende de un proveedor externo, se contacta con la empresa para abrir caso

Cierre de incidencias: Una vez conseguida y verificada la solución, la

Mesa de Ayuda procede al cierre la incidencia. La incidencia se cierra tras

comprobar el grado de satisfacción del usuario.

 Gestión de la continuidad de servicio TI: Esta practica apoya la

continuidad del negocio asegurando que los servicios de TI críticos se

recuperarán en el tiempo establecido al asegurar que las instalaciones

técnicas y de servicio de TI requeridas se puedan reanudar conforme a

 las escalas de tiempo requeridas y acordadas del negocio, con el fin de

minimizar las posibles pérdidas que pueda tener el negocio frente a la

caída del sistema ocasionado por la falta de monitorización de los

servicios internos. Sin embargo, para minorizar el impacto, se debe

implementar un plan de monitoreo frente al downtime que pueda ocurrir

en los procesos críticos del negocio.

 Gestión de Eventos y monitoreo: En esta práctica nos ayuda a

monitorear y tener mapeado los eventos que ocurran en el negocio.

Estos eventos pueden aparecer en cualquier instante, por lo que la

organización debe saber cuáles son aquellos eventos que debe detectar

y priorizar en caso de presentarse alguna caída del sistema tanto a nivel

de hardware y software. Con ello, la organización cuenta con

conocimiento de los cambios monitorizados para poder implementar la

acción de control correcta y mitigar el posible riesgo.