Actividad AA8-1: Conceptualizar sobre los niveles de servicio y gestión

de incidentes

FORERO NEME JUAN GUILLERMO

GARCIA AGUDELO JORGE ALBERTO
SALAMANCA MORENO JEFFERSON ALEJANDRO
TOVAR JIMENEZ BRAYAN LEONEL
VARON MARTINEZ HERNAN DARIO
GAES 5

SERVICIO NACIONAL DE APRENDIZAJE

CENTRO DE SERVICIOS FINANANCIEROS

GESTIÓN Y SEGURIDAD DE BASES DE DATOS

Contenido

INTRODUCCION ............................................................................................ 3
DESARROLLO ............................................................................................... 4
Niveles de servicio, como se establecen, acuerdos, clientes, usuarios,
disponibilidad. .............................................................................................. 4
Gestión de Incidentes, características, planeación, diagnóstico, evaluación,
soluciones.................................................................................................... 7
Bases de datos de Conocimiento. ............................................................. 11
BIBLIOGRAFIA ............................................................................................ 12
INTRODUCCION

El presente trabajo se realiza con el fin de cumplir con el requerimiento

solicitado por el Servicio Nacional de Aprendizaje en marco de la
especialización técnica en Gestión de Bases de Datos.

El eje temático de esta evidencia de aprendizaje gira en torno al proceso de

gestión de niveles de servicio y de incidentes.

Las labores diarias que debe atender un DBA giran en torno a la atención de
los incidentes que se puedan presentar en las áreas funcionales y que guarden
relación directa o indirecta con las bases de datos administradas.

ITIL V3 ofrece una visión estandarizada de modelo de atención de mesas de

soporte, el conocimiento de este compendio de buenas prácticas y su
adaptación al negocio ayudará a tener una mejor atención de incidentes.
Actividad AA8-1: Conceptualizar sobre los niveles de servicio y gestión
de incidentes.

En el desarrollo de esta actividad usted deberá fundamentarse y ampliar sus

conocimientos acerca de:

 Niveles de servicio, como se establecen, acuerdos, clientes, usuarios,

disponibilidad.
 Gestión de Incidentes, características, planeación, diagnóstico,
evaluación, soluciones.
 Bases de datos de Conocimiento.

Hacer lectura y análisis del caso de estudio: “Incidentes en la secretaría de

salud de la alcaldía San Antonio del Sena”

DESARROLLO

En marco de esta investigación se procede a consultar los conceptos de ITIL

en lo que refiere a los niveles de servicio y la gestión de incidentes en las áreas
TI

Niveles de servicio, como se establecen, acuerdos, clientes, usuarios,

disponibilidad.

El propósito del proceso de gestión de niveles de servicio es asegurar que los

servicios actuales y planificados sean entregados de acuerdo con lo
negociado, acordado, y dentro de los objetivos establecidos.

Esto es facilitado a través de un ciclo constante de negociación, acordando,

supervisando, reportando y revisando los objetivos del servicio y los logros del
servicio que ya fue proporcionado y será necesario tomar diferentes acciones
para mejorar el nivel del servicio entregado.

ITIL define los siguientes objetivos para el proceso de gestión de niveles de

servicio:

 Definir, documentar, acordar, monitorear, medir, reportar y revisar el

desempeño del servicio.
 Iniciar mediciones correctivas como sea apropiado.
 Trabajar con la gestión de las relaciones con el negocio para proveer y
mejorar la relación con el cliente y el negocio.
 Asegurar que son negociados objetivos específicos y medibles para
todos los servicios.
  Monitorear y mejorar la satisfacción del cliente mediante la calidad del
servicio.
 Establecer expectativas claras e inequívocas del desempeño del
servicio.
 Asegurar de que incluso cuando los objetivos acordados se cumplan,
los niveles del servicio serán medibles y evaluados para detectar
oportunidades de mejora

El alcance de la gestión de niveles de servicio engloba la cooperación con el

proceso de gestión de las relaciones con el negocio, esto incluye desarrollar
la relación con el negocio como se necesite para lograr los objetivos del
proceso de gestión de niveles de servicio.

La gestión de niveles de servicio se enfoca en la garantía y en el nivel de

servicio entregado mientras que la gestión de las relaciones con el negocio se
enfoca en la utilidad del servicio. Las interacciones entre estos dos procesos
deben estar claramente definidas.

Dentro del alcance: Los siguientes puntos son parte del alcance de la
gestión de niveles de servicio:

 Negociación y acuerdos de requisitos de nivel de servicio actuales y

futuros y sus objetivos, además de la documentación y gestión de
los acuerdos de nivel de servicio (SLAs) para todos los servicios en
operación.
 Desarrollo y gestión de los acuerdos de nivel
operativo (OLAs) apropiados para asegurar que los objetivos son
alineados con los objetivos de los SLAs.
 Revisión de acuerdos con proveedores externos y contratos de
soporte (UCs) con la gestión de proveedores para asegurar que los
objetivos son alineados con los objetivos de los SLAs.
 Prevención proactiva de fallas del servicio, reducción de riesgos del
servicio y mejoras en la calidad del servicio en conjunto con los demás
procesos de la gestión de servicios.
 Reportes y gestión de todos los logros del nivel de servicio y revisión de
las infracciones del SLA.
 Revisión periódica, de los SLAs, alcance del servicio y OLAs tanto como
sea apropiado. Identificación de acciones de mejora para incluirlas en
el registro del CSI.
 Revisión y priorización de mejoras en el registro CSI, así como instigar
y coordinar los planes de mejora del servicio o SIPs (Service
Improvement Plan) para gestionar, planear e implementar mejoras del
proceso y servicios.

Fuera del alcance: Los siguientes puntos no están incluidos en el alcance

de la gestión de niveles de servicio:
  Negociaciones y acuerdos de funcionalidad o utilidad.
 Atención detallada para actividades necesarias para entregar niveles de
servicio que son representados por otros procesos tales como gestión
de la disponibilidad y gestión de la capacidad.
 Negociación de contratos de soporte o acuerdos con proveedores
externos. Esto es parte del alcance del proceso gestión de proveedores.

Requisito de nivel de servicio (SLR): Es un requerimiento del cliente para

un aspecto de un servicio de TI. Los requisitos del nivel del servicio están
basados en los objetivos del negocio y son usados para los objetivos de nivel
de servicio acordados.

Objetivos de nivel de servicio: Son un compromiso que es documentado en

un SLA. Los objetivos de nivel de servicio se necesitan para asegurar que el
servicio permite cumplir los objetivos del negocio.

Tipos de acuerdos:

Acuerdo de nivel de servicio o SLA (Service Level Agreement): Es un

acuerdo entre un proveedor de servicios de TI y el cliente, este describe el
servicio, los objetivos del nivel de servicio, y especifica las responsabilidades
del proveedor de servicios y el cliente. Un solo acuerdo de nivel de servicio
puede cubrir múltiples servicios y/o múltiples clientes.

Existen 3 tipos de acuerdos de nivel de servicio o SLA:

SLA basado en el servicio: Cubre un servicio para todos los clientes de ese
servicio, por ejemplo, un SLA puede ser establecido para el servicio de correo
electrónico de una organización, cubriendo todos los clientes de ese servicio.
Un SLA basado en el servicio puede ser eficiente cuando se requieren los
mismos niveles de servicio en todas las áreas del negocio, por ejemplo, para
correo electrónico o telefonía.

SLA basado en el cliente: Este es un acuerdo con un grupo de clientes

particulares, que cubre todos los servicios que ellos usan, por ejemplo:

Un acuerdo basado en el cliente con el departamento de finanzas de una

organización, cubriendo, digamos, el sistema de finanzas, el sistema de
contabilidad, el sistema de facturación y cualquier otro sistema de TI que el
departamento use.

Los clientes a menudo prefieren este tipo de acuerdo si todos sus requisitos
están cubiertos en un solo documento. Normalmente se requiere solo una
firma, lo cual simplifica este tema.
  SLA multinivel: Algunas organizaciones escogerán enfoque multinivel,
por ejemplo, una estructura de tres niveles como sigue:
 Nivel corporativo: Este va a cubrir todos los temas genéricos
apropiados a cada cliente en toda la organización.
 Nivel del cliente: Un acuerdo por cada cliente consumiendo servicios
únicos no capturados dentro del acuerdo de nivel corporativo.
 Nivel del servicio: Este cubrirá temas relevantes para el servicio
específico en relación a un grupo de cliente específico (uno por cada
servicio cubierto por el SLA).

Acuerdo de nivel operativo u OLA (Operational Level Agreement): Es un

acuerdo entre el proveedor de servicios de TI y otra parte de la misma
organización, este acuerdo soporta la entrega de servicios para los clientes y
define los bienes o servicios que serán proporcionados y la responsabilidad de
ambas partes.

Contrato de apoyo o UC (Underpinning Contract): Es un acuerdo legal

entre un proveedor de servicios de TI y una tercera parte. La tercera parte
provee bienes o servicios que soportan la entrega de servicios para los
clientes.

Gestión de Incidentes, características, planeación, diagnóstico,

evaluación, soluciones.

Qué es la Gestión de incidencias y sus principales actividades según ITIL v3

La Gestión de Incidencias (Incident Management) es un proceso ITIL
enmarcado en la fase de Operación del Servicio.

Una incidencia es toda interrupción o reducción de la calidad no planificada

del servicio. Pueden ser fallos o consultas reportadas por los usuarios, el
equipo del servicio o por alguna herramienta de monitorización de eventos.

El principal objetivo de la gestión de incidencias es restaurar cuanto antes la

operativa normal del servicio minimizando el impacto negativo en las
operaciones de negocio.

Se entiende por operativa normal aquella que se encuentra dentro de los

límites del SLA.

3 conceptos básicos sobre la Gestión de Incidencias

Escala de tiempos

A partir del SLA se establecen los tiempos máximos en los que se deben
responder y resolver las incidencias.
Debemos usar herramientas de gestión para el cálculo y la asignación de
estas escalas de tiempo, así como para utilizar alertas y escalados para
facilitar la respuesta/resolución de las incidencias dentro del tiempo máximo
definido.

Modelos de incidencia

Los modelos de incidencia permiten optimizar el proceso de resolución.

Existen incidencias que no son nuevas, sino que ya se han producido
anteriormente y que se volverán a producir en el futuro. Muchas empresas
encuentran útil la definición de modelos de incidencia que se puedan aplicar a
incidencias recurrentes del servicio.

Un modelo de incidencia debería incluir:

 Los pasos a seguir para la resolución de la incidencia.

 El orden cronológico de estos pasos y sus dependencias si las hubiera.
 Responsabilidades: quién debe hacer qué.
 Plazos para la realización de las actividades.
 Procedimientos de escalado: quién debería ser contactado y cuando.

Incidencias graves

Cada servicio debe definir cuáles son los criterios para que una incidencia se
considere grave.

Las incidencias graves deben tener asociado su propio procedimiento de

resolución y escalado, y tener una escala de tiempos menor que el resto. La
actividad de priorización, que veremos más adelante, debe tener en cuenta
estos criterios.

Actividades principales de la Gestión de Incidencias según ITIL v3

Detección

Cuanto antes se detecte una incidencia, menor será su impacto en el negocio.

Por lo tanto, es importante monitorizar los recursos con el objetivo de detectar
incidencias potenciales y normalizar el servicio antes de que se produzca
un impacto negativo en los procesos de negocio o, si esto no es posible, que
el impacto sea mínimo.

Registro

Todas las incidencias del servicio deben ser registradas, y cada incidencia
debe registrarse de forma independiente, la información a registrar
generalmente incluye:
  Identificador único.
 Categorización.
 Urgencia, impacto y prioridad.
 Fecha y hora.
 Persona/grupo que registra la incidencia.
 Canal de entrada.
 Datos del usuario.
 Síntomas.
 Estado.
 CIs (Configuration Items, elementos de configuración) asociados.
 Persona/grupo asignado para la resolución.
 Problema/Known error asociado.
 Actividades realizadas para la resolución.
 Fecha y hora de la resolución.
 Categoría del cierre.
 Fecha y hora de cierre.

Categorización

En esta actividad se establece el tipo exacto de la incidencia.

Generalmente se establece una categorización multinivel con dependencias
entre niveles. El número de niveles dependerá de la granularidad con la que
necesitemos tipificar las incidencias.

A veces, no se categoriza adecuadamente una incidencia en el momento del

registro. Si esto sucede, debemos asegurarnos de que en el momento del
cierre la categorización queda correctamente establecida.

Priorización

Generalmente, la prioridad de la incidencia nos indica cómo se ha de

gestionar.

La prioridad de la incidencia suele depender de:

 La urgencia: rapidez con que la incidencia necesita ser resuelta.

 El impacto: generalmente se determina por el número de usuarios
afectados, aunque lo realmente importante es la criticidad para el
negocio de los usuarios afectados por la incidencia. Al final, lo que
realmente determina el impacto son los aspectos adversos que la
incidencia tiene en el negocio.

Además de la urgencia y el impacto, la prioridad también puede depender de

otros factores como si el usuario es VIP, el departamento del usuario, etc.
Es muy conveniente que la herramienta de soporte utilizada sea capaz
de calcular la prioridad en base a reglas. En cualquier caso, el equipo de
soporte debe conocer estas reglas para poder priorizar adecuadamente.

Diagnóstico inicial

Cuando el personal de soporte de primer nivel recibe una incidencia, la

diagnostica en base a los síntomas y, si está capacitado para ello, la resuelve.

Escalado

Existen dos tipos de escalado:

 Funcional: el soporte de primer nivel se ve incapaz de resolver la

incidencia y la asigna al grupo resolutor correspondiente.
 Jerárquico: en caso de que se den ciertas circunstancias (incidencias
graves o críticas, riesgo de incumplimiento del SLA) que se deban
notificar a los responsables del servicio correspondiente.

A pesar de que se produzca un escalado, la incidencia sigue perteneciendo al

equipo de Service Desk, y es éste es el responsable de hacer el seguimiento
de la misma y mantener informados a los usuarios hasta su cierre.

Investigación y diagnóstico

Si la incidencia hace referencia a un fallo en el sistema, lo más probable es

que se necesite investigar la causa del fallo.

Las tareas más comunes dentro de esta actividad son las siguientes:

 Establecer exactamente qué es lo que no funciona correctamente y

para qué secuencia de acciones del usuario (casuística).
 Establecer el impacto potencial de la incidencia.
Determinar si la incidencia está producida por la implantación de un
cambio.
 Buscar en la base de datos de conocimiento (base de datos de
errores conocidos, registro de incidencias, etc.) posibles soluciones y/o
workarounds.

Resolución

Cuando se detecta una solución potencial, ésta debería ser aplicada y

testeada. Una vez comprobada la resolución, la incidencia se da por resuelta
y se asigna al equipo de Service Desk para su cierre.
Asimismo, se deben registrar todas las acciones realizadas para resolver la
incidencia en el historial de la misma.

Cierre

Antes de cerrar la incidencia el equipo del Service Desk debería validar lo

siguiente:
 Si el usuario está satisfecho con la resolución de la incidencia.
 Si el cierre ha sido categorizado.
 Si se han cumplimentado todos los datos necesarios.
 Si es un problema recurrente. En este caso, generar un problema.
Eventualmente, se puede pasar una encuesta de satisfacción al
usuario.

Por qué Gestión de Incidencias

Como hemos visto, toda empresa de servicios necesita la Gestión de

Incidencias para prevenir o restaurar tan pronto como sea posible cualquier
interrupción o reducción no planificada en la calidad de su servicio.
Sin embargo, debemos ser conscientes de los desafíos y riesgos de la
Gestión de Incidencias con el fin de garantizar la mejor operación de servicio.

Bases de datos de Conocimiento.

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

Estructura DIKW

El concepto DIKW (Datos-Información-Conocimiento-Saber) recoge y

relaciona las distintas unidades de conocimiento en un proceso lineal que va
de menor a mayor. Esta estructura es un reflejo del modo en que la Gestión
del Conocimiento procesa y transforma los Datos en Saber, que es lo relevante
en la toma de decisiones.

Los Datos consisten en mediciones cuantificables y objetivas, al aportar

contexto a los datos (contrastando con otras fuentes de datos,
interpretándolos, etc.) obtenemos Información.

El Conocimiento se alcanza al completar la información con las experiencias,

ideas y juicios de cada individuo.

El Saber, por último, radica en tomar las decisiones adecuadas aplicando el

conocimiento y el sentido común.

Los Datos, la Información y el Conocimiento pueden ser registrados en bases

de datos, y por lo tanto ser consultados y transferidos. El Saber, sin embargo,
no puede ser capturado puesto que se refiere a la capacidad individual para
hacer juicios válidos y tomar decisiones correctas.

BIBLIOGRAFIA

 https://www.netecdigital.com/courses/195795/lectures/3432553
 https://www.servicetonic.com/es/itil/itil-v3-gestion-de-incidencias/

 http://faquinones.com/gestiondeserviciosit/itilv3/transicion_servicios_TI
/planificacion_soporte_transicion.php