11.LOS OBJETIVOS, VALOR AÑADIDO AL NEGOCIO, CONCEPTOS BASICOS, ROLES E INTERFACES.
 

 11.1. GESTION DE PORTAFOLIOS DE SERVICIOS.

„La Gestión del Portafolio de Servicios se encarga de decidir la estrategia a seguir para dar servicio a los clientes y de desarrollar las ofertas y capacidades del proveedor de servicios.

Una correcta Gestión del Portafolio de Servicios repercute en una serie de mejoras y beneficios notables tanto para el servicio como para el negocio en sí:

Al contar con unos objetivos claros que rigen las líneas estratégicas de la organización, se evita el peligro de caer en una excesiva diversificación del negocio en servicios dispares, situación que a menudo es interpretada por los clientes como signo de incoherencia.
 

La Gestión del Portfolio se relaciona directamente con los siguientes procesos de las fases del Ciclo de Vida:
 

Indirectamente, la Gestión del Portfolio alimenta a todas las fases del Ciclo de Vida, ya que provee de información estratégica fundamental para orientar cualquier actividad.
 

El siguiente diagrama muestra los procesos implicados en la correcta Gestión del Portfolio de Servicios:

El punto de partida de la Gestión del Portfolio de Servicios está, como es lógico, en conocer el mercado en que se va a desarrollar el servicio. No hacerlo puede acarrear consecuencias muy graves como, por ejemplo, averiguar demasiado tarde que otro competidor ofrece el mismo servicio por la mitad de precio.
 

Esto es aplicable tanto en el momento de la puesta en marcha de un nuevo servicio como en aquellos casos en que la Mejora Continua del Servicio plantea nuevas funcionalidades.
 

Por tanto, es imprescindible hacer desde un primer momento un ejercicio de evaluación de la situación actual del negocio y definir:
 

Una metodología útil para tomar decisiones respecto al orden y tiempos de las inversiones en el Portfolio de Servicios es la herramienta de Espacio de Opción:

Tras analizar el mercado, se procede a analizar cuidadosamente las posibilidades de la organización. Se trata de concretar las líneas de actuación conforme a las prioridades de la organización, algo imprescindible de cara a la optimización de recursos y el equilibrio del suministro. Sin denominadores comunes, la Gestión de la Demanda apenas tiene margen de maniobra.

Además de ahorrar costes, al existir unos planteamientos que de manera subyacente implican a todos los servicios, se configuran unas señas de identidad que, a ojos del cliente, son percibidos de forma positiva como coherencia en el negocio.

11.2. GESTION DE NIVELES DE SERVICIO.


La Gestión de Niveles de Servicio es el proceso por el cual se definen, negocian y supervisan la calidad de los servicios TI ofrecidos.
 

- Se facilita la comunicación con los clientes impidiendo los malentendidos sobre las características y calidad de los servicios ofrecidos.

- Se establecen objetivos claros y metrizables.

Las principales dificultades a la hora de implementar la Gestión de Niveles de Servicio se resumen en:
 

- No existe una buena comunicación con clientes y usuarios por lo que los SLAs acordados no recogen sus necesidades reales.
 

- Los acuerdos de nivel de servicio están basados más en deseos y expectativas del cliente que en servicios que la infraestructura TI puede ofrecer con un nivel de calidad suficiente.
 

- No se alinean adecuadamente los servicios TI a los procesos de negocio del cliente.

La Gestión de Niveles de Servicio debe velar por la calidad de los servicios TI alineando tecnología con procesos de negocio y todo ello a unos costes razonables.

Para cumplir sus objetivos es imprescindible que la Gestión de Niveles de Servicio:

• Conozca las necesidades de sus clientes.
• Defina correctamente los servicios ofrecidos.
• Monitorice la calidad del servicio respecto a los objetivos establecidos en los SLAs.

Las interacciones y funcionalidades de la Gestión de Niveles de Servicio se resumen sucintamente en el siguiente interactivo:

La Gestión de Niveles de Servicio es el proceso por el cual se definen, negocian y supervisan la calidad de los servicios TI ofrecidos.

La Gestión de Niveles de Servicio es responsable de buscar un compromiso realista entre las necesidades y expectativas del cliente y los costes de los servicios asociados, de forma que estos sean asumibles tanto por el cliente como por la organización TI.
 

La Gestión de los Niveles de Servicio debe:

- Documentar todos los servicios TI ofrecidos.

- Presentar los servicios de forma comprensible para el cliente.

- Centrarse en el cliente y su negocio y no en la tecnología.

- Colaborar estrechamente con el cliente para proponer servicios TI realistas y ajustados a sus necesidades.

- Establecer los acuerdos necesarios con clientes y proveedores para ofrecer los servicios requeridos.

- Establecer los indicadores claves de rendimiento del servicio TI.

- Monitorizar la calidad de los servicios acordados con el objetivo último de mejorarlos a un coste aceptable por el cliente.

- Elaborar los informes sobre la calidad del servicio y los Planes de Mejora del Servicio (SIP).

Conceptos básicos.

Proveedores, clientes y usuarios.

Cliente: es la empresa u organismo que contrata los servicios TI ofrecidos.

Usuarios: las personas que utilizan el servicio.

Proveedor: es la empresa u organismo que proporciona los servicios solicitados por el cliente.

Requisitos de Nivel de Servicio (SLR)

El SLR debe incluir información detallada sobre las necesidades del cliente y sus expectativas de rendimiento y nivel de servicios.

El SLR constituye el elemento base para desarrollar el SLA y posibles OLAs correspondientes.
 

Hojas de Especificación

Las Hojas de Especificación son, primordialmente, documentos técnicos de ámbito interno que delimitan y precisan los servicios ofrecidos al cliente.

Las Hojas de Especificación deben evaluar los recursos necesarios para ofrecer el servicio requerido con un nivel de calidad suficiente y determinar si es necesario el outsourcing de determinados procesos, sirviendo de documento de base para la elaboración de los OLAs y UCs correspondientes.
 

Programa de Calidad del Servicio (SQP)

El SQP debe incorporar toda la información necesaria para posibilitar una gestión eficiente de los niveles de calidad del servicio:
 

• Objetivos de cada servicio.
• Estimación de recursos.
• Indicadores clave de rendimiento.
• Procedimientos de monitorización de proveedores.

En resumen, el SQP debe contener la información necesaria para que la organización TI conozca los procesos y procedimientos involucrados en el suministro de los servicios prestados, asegurando que estos se alineen con los procesos de negocio y mantengan unos niveles de calidad adecuados.

Acuerdo de Nivel de Servicio (SLA)

El SLA debe recoger en un lenguaje no técnico, o cuando menos comprensible para el cliente, todos los detalles de los servicios brindados.

Tras su firma, el SLA debe considerarse el documento de referencia para la relación con el cliente en todo lo que respecta a la provisión de los servicios acordados, por tanto, es imprescindible que contenga claramente definidos los aspectos esenciales del servicio tales como su descripción, disponibilidad, niveles de calidad, tiempos de recuperación, etc.

Acuerdo de Nivel de Operación (OLA)

El OLA es un documento interno de la organización donde se especifican las responsabilidades y compromisos de los diferentes departamentos de la organización TI en la prestación de un determinado servicio.

Contratos de Soporte (UC)

Un UC es un acuerdo con un proveedor externo para la prestación de servicios no cubiertos por la propia organización TI.

Programa de Mejora del Servicio (SIP)

El SIP debe recoger tanto medidas correctivas a fallos detectados en los niveles de servicio como propuestas de mejora basadas en el avance de la tecnología.

 

 

 

El SIP debe formar parte de la documentación de base para la renovación de los SLAs y debe estar internamente a disposición de los gestores de los otros procesos TI.

Las principales actividades de la Gestión de Niveles de Servicio se resumen en:

 

• Planificación:
  • Asignación de recursos.
  • Elaboración de un catálogo de servicios.
  • Desarrollo de SLAs tipo.
  • Herramientas para la monitorización de la calidad del servicio.
  • Análisis e identificación de las necesidades del cliente.
  • Elaboración del los Requisitos de Nivel de servicio(SLR), Hojas de Especificación del Servicio y Plan de Calidad del Servicio(SQP).
     
• Implementación de los Acuerdos de Nivel del Servicio:
  • Negociación.
  • Acuerdos de Nivel de Operación.
  • Contratos de Soporte.
     
• Supervisión y revisión de los Acuerdos de Nivel de Servicio:
  • Elaboración de informes de rendimiento.
  • Control de los proveedores externos.
  • Elaboración de Programas de Mejora del Servicio (SIP).

11.3. GESTION DE INCIDENCIAS.

Los objetivos principales de la Gestión de Incidentes son:
 

• Detectar cualquiera alteración en los servicios TI.
• Registrar y clasificar estas alteraciones.
• Asignar el personal encargado de restaurar el servicio según se define en el SLA correspondiente.

Aunque el concepto de incidencia se asocia naturalmente con cualquier malfuncionamiento de los sistemas de hardware y software según el libro de Soporte del Servicio de ITIL un incidente es:

“Cualquier evento que no forma parte de la operación estándar de un servicio y que causa, o puede causar, una interrupción o una reducción de calidad del mismo”.

Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como un incidente, lo que incluye a las Peticiones de Servicio tales como concesión de nuevas licencias, cambio de información de acceso, etc. siempre que estos servicios se consideren estándar.

Cualquier cambio que requiera una modificación de la infraestructura no se considera un servicio estándar y requiere el inicio de una Petición de Cambio (RFC) que debe ser tratada según los principios de la Gestión de Cambios.

Los principales beneficios de una correcta Gestión de Incidentes incluyen:
 

• Mejorar la productividad de los usuarios.
• Cumplimiento de los niveles de servicio acordados en el SLA.
• Mayor control de los procesos y monitorización del servicio.
• Optimización de los recursos disponibles.
• Una CMDB más precisa pues se registran los incidentes en relación con los elementos de configuración.
• Y principalmente: mejora la satisfacción general de clientes y usuarios.

tiene como objetivo resolver cualquier incidente que cause una interrupción en el servicio de la manera más rápida y eficaz posible.

La Gestión de Incidentes no debe confundirse con la Gestión de Problemas, pues a diferencia de esta última, no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el servicio. Sin embargo, es obvio, que existe una fuerte interrelación entre ambas.

Las propiedades y funcionalidades de la Gestión de Incidentes se resumen sucintamente en el siguiente interactivo:


 

Proceso.

El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Incidentes:




Registro y Clasificación de Incidentes.

Registro.

La admisión y registro del incidente es el primer y necesario paso para una correcta gestión del mismo.
 

Las incidencias pueden provenir de diversas fuentes tales como usuarios, gestión de aplicaciones, el mismo Centro de Servicios o el soporte técnico, entre otros.
 

El proceso de registro debe realizarse inmediatamente pues resulta mucho más costoso hacerlo posteriormente y se corre el riesgo de que la aparición de nuevas incidencias demore indefinidamente el proceso.

 

• La admisión a tramite del incidente: el Centro de Servicios debe de ser capaz de evaluar en primera instancia si el servicio requerido se incluye en el SLA del cliente y en caso contrario reenviarlo a una autoridad competente.

• Comprobación de que ese incidente aún no ha sido registrado: es moneda corriente que más de un usuario notifique la misma incidencia y por lo tanto han de evitarse duplicaciones innecesarias.

• Asignación de referencia: al incidente se le asignará una referencia que le identificará unívocamente tanto en los procesos internos como en las comunicaciones con el cliente.

• Registro inicial: se han de introducir en la base de datos asociada la información básica necesaria para el procesamiento del incidente (hora, descripción del incidente, sistemas afectados...).

• Información de apoyo: se incluirá cualquier información relevante para la resolución del incidente que puede ser solicitada al cliente a través de un formulario específico, o que pueda ser obtenida de la propia CMDB (hardware interrelacionado), etc.

• Notificación del incidente: en los casos en que el incidente pueda afectar a otros usuarios estos deben ser notificados para que conozcan como esta incidencia puede afectar su flujo habitual de trabajo.
   

Clasificación.

La clasificación de un incidente tiene como objetivo principal el recopilar toda la información que pueda ser de utilizada para la resolución del mismo.
 

El proceso de clasificación debe implementar, al menos, los siguientes pasos:
 

• Categorización: se asigna una categoría (que puede estar a su vez subdividida en más niveles) dependiendo del tipo de incidente o del grupo de trabajo responsable de su resolución. Se identifican los servicios afectados por el incidente.

• Establecimiento del nivel de prioridad: dependiendo del impacto y la urgencia se determina, según criterios preestablecidos, un nivel de prioridad.

• Asignación de recursos: si el Centro de Servicios no puede resolver el incidente en primera instancia designara al personal de soporte técnico responsable de su resolución (segundo nivel).

• Monitorización del estado y tiempo de respuesta esperado: se asocia un estado al incidente (por ejemplo: registrado, activo, suspendido, resuelto, cerrado) y se estima el tiempo de resolución del incidente en base al SLA correspondiente y la prioridad.

En primera instancia se examina el incidente con ayuda de la KB para determinar si se puede identificar con alguna incidencia ya resuelta y aplicar el procedimiento asignado.

 

Si la resolución del incidente se escapa de las posibilidades del Centro de Servicios éste redirecciona el mismo a un nivel superior para su investigación por los expertos asignados. Si estos expertos no son capaces de resolver el incidente se seguirán los protocolos de escalado predeterminados.
 

Durante todo el ciclo de vida del incidente se debe actualizar la información almacenada en las correspondientes bases de datos para que los agentes implicados dispongan de cumplida información sobre el estado del mismo.
 

Si fuera necesario se puede emitir una Petición de Cambio (RFC). Si la incidencia fuera recurrente y no se encuentra una solución definitiva al mismo se deberá informar igualmente a la Gestión de Problemas para el estudio detallado de las causas subyacentes.
 

Cuando se haya solucionado el incidente se:

 

• Confirma con los usuarios la solución satisfactoria del mismo.

• Incorpora el proceso de resolución a la KB.

• Reclasifica el incidente si fuera necesario.

• Actualiza la información en la CMDB sobre los elementos de configuración (CI) implicados en el incidente.

• Cierra el incidente.