RACI UNIDAD 3

1. Unidad 3
3.1 Funciones roles y procesos en la gestion de servicios de TI: El modelo
RACI
Hay un dicho que reza: “Cuando todos son responsables, nadie es responsable”.
¡Y vaya que esto lo sufrimos en nuestras empresas, con roles y responsabilidades
no siempre bien definidos! Esto tiene varias consecuencias:
• Clientes insatisfechos porque no se les respondió en los plazos solicitados (hubo
que hacer “varias escalas” internas para hallar la respuesta, ya que no estaba
claro quién debía canalizarla).
• Oportunidades de compra con descuento desaprovechadas, porque nadie supo
gestionar las autorizaciones necesarias para darles curso.
• Mal clima interno, echadas en cara, disputas…. porque las “reprimendas” por un
negocio perdido se repartieron indiscriminadamente.
• Pérdida de tiempos por recepción de decenas de emails en vano, o peor aún, no
recepción de emails importantes, necesarios para poder tomar decisiones
oportunas.
• Empleados desmotivados porque quieren desarrollar sus actividades y les falta
autoridad para resolver determinadas cuestiones a su cargo.
Estos ejemplos constituyen sólo la punta del iceberg, a modo ilustrativo.
La Matriz RACI
Por fortuna existen algunas herramientas (simples, concretas y útiles) para
minimizar el impacto de este tipo de situaciones, como por ejemplo la Matriz RACI.
RACI proviene de una sigla en inglés:
• “R” (Responsible): es quien ejecuta una tarea. Su función es "HACER".
• “A” (Accountable): es quien vela porque la tarea se cumpla, aún sin tener que
ejecutarla en persona. Su función es “HACER HACER”.
• “C” (Consulted): indica que una persona o área debe ser consultada respecto
de la realización de una tarea.
• “I” (Informed): indica que una persona o área debe ser informada respecto de la
realización de una tarea.

2. Para aplicarla basta con seguir unas pocas acciones, bastante simples.
1. Identificar las actividades de algún proceso (y colocarlas como filas de la
Matriz).
2. Identificar / definir los principales roles funcionales (y colocarlos como columnas
de la matriz).
3. Asignar los códigos “RACI” a cada tarea (aquí la cosa se potencia si se logra
hacer en equipo).
4. Identificar ambigüedades o problemas (solapamientos, vacíos, dudas, etc.) y
trabajar para solucionarlos.
5. Distribuir la matriz e incorporar el feedback.
6. Comunicarla de modo efectivo a todos los involucrados en el proceso.
7. Asegurar que se haga una actualización periódica de la matriz.
Un mismo rol puede ser compartido por más de una persona o viceversa (sobre
todo en organizaciones más pequeña).
A modo de ejemplo, podemos ver una matriz RACI de un negocio de venta de
flores:
Análisis y “Lectura” de la Matriz
La Matriz RACI resulta de utilidad para efectuar un análisis de los procesos de la
organización.
Desde un análisis vertical (es decir, a nivel roles) es posible obtener determinadas
interpretaciones:

3. • Excesivas “R” a cargo de un mismo rol (¿podría estar existiendo un cuello de
botella allí?).
• Inexistencia de espacios vacíos (¿es necesario que ese rol esté implicado en
tantas tareas?).
• Excesivas “A” para un mismo rol (¿podría pensarse en una mayor delegación de
responsabilidades?).
• Inexistencia de “R” o “A” en un rol de línea (¿es un rol realmente necesario en
este proceso?).
• Existencia de “R” en tareas que deben ser independientes entre sí (¿hay una
debida segregación de funciones, que asegure un adecuado control por oposición
de intereses?).
Desde un análisis horizontal (es decir, a nivel de tareas) también se pueden
obtener luces:
• Excesivas “R” en una misma tarea (¿podemos asegurar que dicha tarea no se
duplique?, ¿habrá que subdividirla en sub-tareas más específicas?).
• Inexistencia de “R” (¿podría suceder que nadie vea dicha tarea como propia y así
nadie la ejecute? ¿O será necesario tal vez definir un nuevo rol actualmente
inexistente?).
• Demasiadas “C” (¿es realmente “costo-beneficioso” incurrir en tantas
consultas?).
• Excesivas “I” (¿no estaremos siendo burocráticos al informar rutinariamente a
tantas personas? ¿Puede pensarse en informarlos sólo ante excepciones?).
• Inexistencia de “A”, implica que nadie garantiza el cumplimiento (¿nadie pondrá
la cara si la tarea no se efectúa?).
• Inexistencias de “C” o “I” (¿podría deberse a deficiencias en las
comunicaciones?).
Con frecuencia se utiliza una matriz su autoridad dentro de las organizaciones
para indicar los roles y responsabilidades relacionaos con los procesos y las
actividades.
Si bien existen muchas variaciones de la matriz de autoridad, el modelo RACI está
respaldado por COBIT (Objetivos de Control para la información y Tecnología
Relacionada), un modelo de gobierno de tecnología de la información
ampliamente reconocido.
Al utilizar el modelo RACI como un ejemplo, solo existe una persona responsable
de una actividad aunque varias personas pueden ser responsables de la ejecución
de algunas partes de la actividad. En este modelo, responsable final significa la
responsabilidad de un extremo a otro del proceso. La responsabilidad debe
permanecer con la misma persona en todas las actividades de un proceso.

4. 3.2 Metas y objetivos de las estrategias de servicios
Proveer orientación, desarrollar e implementar la Gestión de Servicios de TI. Su
meta primordial es que la organización piense y actúe estratégicamente.
Busca conseguir el alineamiento entre el negocio y TI.
Proporciona las herramientas para una planeación de la gestión de servicio de TI.
SS busca mejorar el impacto estratégico (utilidad del servicio y percepción del
cliente) a través del diseño, desarrollo, implementación y práctica de la Gestión del
Servicio (ITSM).
Transformar la gestión del servicio en un activo estratégico: Pensar cómo puedo
mejorar el servicio. Proveer principios de soporte (solo principios) para asistir en el
desarrollo de: políticas, guías y procesos.
El fijar objetivos y expectativas de desempeño hacia el servicio de clientes y los
espacios de mercado. El identificar, seleccionar y priorizar oportunidades. El
asegurar que las organizaciones están en posición de manejar los costes y los
riesgos asociados con las Carteras de Servicios.
Una correcta Estrategia del Servicio debe:
 Gestionar los recursos y capacidades necesarios para prestar los servicios
ofrecidos teniendo en cuenta los costes y riesgos asociados.
 Alinear los servicios ofrecidos con la estrategia de negocio.
 Elaborar planes que permitan un crecimiento sostenible.
 Crear casos de negocio para justificar inversiones estratégicas
 Servir de guía a la hora de establecer y priorizar objetivos y oportunidades.
 Conocer el mercado y los servicios de la competencia.
 Armonizar la oferta con la demanda de servicios.
 Proponer servicios diferenciados que aporten valor añadido al cliente.
Las actividades a realizar en esta fase son:
1. Definir el mercado. Relacionada con el proceso Gestión de la Demanda. ¿Quién
es mi cliente? ¿Competencia? Procesos, etc.
2. Desarrollar las ofertas. Relacionada con el proceso Gestión de la cartera de
servicios.
3. Desarrollar activos estratégicos. Relacionada con el proceso Gestión financiera.
4. Preparar la ejecución. Recopilamos información de los 3 procesos y ordenamos.
La estrategia de servicio busca dar valor a través de RECURSOS (dinero,
hardware , software) y HABILIDADES(gestión, organización, procesos,
conocimiento y LAS PERSONAS).Desde el punto de vista del cliente el valor
significa: UTILIDAD (sirve o no sirve?) y Garantia(es confiable?).

5. 3.3 Importancia de la utilizacion de metricas en la gestion de servicios de
TI
No se puede mejorar aquello que no se conoce .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.
Cada organización debe identificar los objetivos que pretende conseguir midiendo.
· No obstante, existen aspectos genéricos útiles para todas las
organizaciones y que constituyen un buen punto de partida.
· El cuadro de mando integral de Norton y Kaplan es un buen punto de
partida porque maneja cuatro perspectivas fundamentales.
Una organización TI debe utilizar tres tipos de métricas:
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.
Si la organización TI se ha propuesto, por ejemplo, como CSF la mejora en la
atención al usuario los KPIs incluiría:

6.  1. Tiempo medio de resolución de los incidentes.
 2. Adecuación de los procesos de escalado.
 3. Percepción de los usuarios respecto a la atención prestada mediante
encuestas de satisfacción.
Las métricas deberán superar el criterio SMART:
 Specific (específicas)
 Measurable ( medibles)
 Archievables ( alcanzables)
 Relevants (relevantes)
 Timely (a tiempo)
Las métricas que no superan al criterio SMART no aportarán información útil, no
será viable o recuperar la información tendrá coste excesivo.
Todo es de gran importancia ya que el utilizar las métricas nos ayudara a medir los
diferentes aspectos dentro de nuestra organización, que permitan obtener
información para facilitar la toma de decisiones con un criterio fundado y así poder
identificar dónde actuar.
Y estas a su vez se transformaran en acciones de mejora para nuestra
organización.
Los objetivos de cada organización son diferentes, por eso es importante
conocerlos, reflexionar acerca de ellos, localizarlos y realizar acciones para
mejorar.

7. 3.4 Formulacion de estrategias a partir de las mejores practicas de
gestion de servicios de TI
La fase de Estrategia del Servicio es central al concepto de Ciclo de vida del
servicio y tiene como principal objetivo convertir la Gestión del Servicio en un
activo estratégico.
Para conseguir este objetivo es imprescindible determinar en primera instancia
qué servicios deben ser prestados y por qué han de ser prestados desde la
perspectiva del cliente y el mercado.
Una correcta Estrategia del Servicio debe:
· Conocer el mercado y los servicios de la competencia.
· Armonizar la oferta con la demanda de servicios.
· Proponer servicios diferenciados que aporten valor añadido al cliente.
· Alinear los servicios ofrecidos con la estrategia de negocio.
· Elaborar planes que permitan un crecimiento sostenible.
La fase de Estrategia del Servicio es el eje que permite que las fases de Diseño,
Transición y Operación del servicio se ajusten a las políticas y visión estratégica
del negocio. Una correcta implementación de la estrategia del servicio va más allá
del ámbito puramente TI y requiere un enfoque multidisciplinar que ayude a
responder cuestiones tales como:
¿Qué servicios debemos ofrecer?
¿Cuál es su valor? ¿Cuáles son nuestros clientes potenciales?
¿Cuáles son los resultados esperados?
¿Qué servicios son prioritarios? v ¿Qué inversiones son necesarias?
¿Cuál es el retorno a la inversión o ROI?
¿Qué servicios existen ya en el mercado que puedan representar una
competencia directa?
¿Cómo podemos diferenciarnos de la competencia?
En nuestro caso el valor incluye algunos otros intangibles entre los que se incluye
la percepción del cliente.
La comunicación es un aspecto esencial pues
todos los agentes implicados deben comprender
fácilmente cual la perspectiva adoptada.

8. 3.5 Casos de estudio
Este caso práctico se refieren a una compañía (ficticia) dedicada al catering,
"Catering S.A.", que ha optado por introducir la metodología ITIL para la gestión de
sus servicios.
"Catering S.A."ofrece sus servicios de catering a un amplio abanico de clientes
que incluye:
•Servicios de comedor de grandes empresas.
•Servicios de catering para colegios.
•Servicios de catering para eventos (congresos, actos institucionales,…).
•Servicios de restauración para hoteles.
La logística del servicio es compleja y los niveles de servicio muy exigentes en lo
que respecta a la calidad y los plazos de entrega.
Para mejorar sus estándares de servicio "Catering S.A."ha implementado un
sofisticado sistema informático que le permite gestionar de una manera más ágil y
eficiente sus relaciones con los clientes así como sus procesos de producción y
distribución.
La dirección de "Catering S.A.", tras un concienzudo análisis de la situación, ha
decidido adoptar la metodología ITIL como la base de todos sus procesos y
servicios
Entre las decisiones adoptadas consecuentemente caben destacar:
•Creación de un Service Desk o Centro de Servicios que centralice todas las
relaciones con los clientes y el resto de la infraestructura TI.
•Organización de sus actividades en torno a los procesos.
•Designación de responsables o gestores para cada uno de los procesos críticos.
•Establecimiento de estrictos protocolos de monitorización de la calidad del
servicio
Service Desk
• El objetivo primordial, aunque no único, del Centro de Servicios es servir de
punto de contacto entre los los usuarios y la Gestión de Servicios TI.
• Un Centro de Servicios, en su concepción más moderna, debe funcionar
como centro neurálgico de todos los procesos de soporte al servicio:
• •Registrando y monitorizando incidentes.
•Aplicando soluciones temporales a errores conocidos en colaboración con
la Gestión de Problemas.

9. •Colaborando con la Gestión de Configuraciones para asegurar la
actualización de las bases de datos correspondientes.
•Gestionando cambios solicitados por los clientes mediante peticiones de
servicio en colaboración con la Gestión de Cambios y Versiones
• Pero también debe jugar un papel importante dando soporte al negocio
identificando nuevas oportunidades en sus contactos con usuarios y
clientes.
• Como paso imprescindible para la implantación de la metodología ITIL en la
empresa la dirección de "Catering S.A."ha decidido implantar un Service
Desk que centralice todos los contactos con clientes, proveedores y la
organización TI.
• Para ello se han adoptado las siguientes decisiones:
•Se ha nombrado un gestor responsable del Service Desk.
•Se han definido, tras un cuidadoso análisis de las necesidades de la
organización y los usuarios, las funciones principales del mismo:
- Gestionar la primera línea de soporte de la Gestión de Incidentes.
- Supervisar la calidad del servicio ofrecido respecto a los SLAs.
- Ofrecer información de carácter comercial sobre los servicios ofrecidos.
- Realizar encuestas periódicas sobre el grado de satisfacción del cliente.
- Elaboración de informes periódicos con la información recopilada.
•Realizar una pequeña promoción para presentar los nuevos servicios a los
clientes existentes y potenciales.
•Habilitar un espacio web para canalizar, en la medida de los posible, la
interacción con los usuarios a través de este medio:
- Formularios de consultas y alta de incidentes.
- Consulta remota, mediante los web services asociados, del estado de los
incidentes activos, históricos de incidencias y cumplimiento de los SLAs.
- FAQs actualizadas que permitan a los usuarios consultar directamente
sobre los servicios prestados, errores conocidos, etc.
•Desarrollar un "Manual de Atención al Cliente" en donde se detalle los
diferentes protocolos de interacción con los usuarios dependiendo de la
situación en cuestión.
•Elegir una herramienta de software que ayude a registrar y gestionar todo
el flujo de información del Service Desk.
•Impartir formación específica:
- Al personal encargado del trato directo con usuarios y clientes sobre la
aplicación del "Manual de Atención al Cliente".
- Sobre las herramientas de software utilizadas.
•Creación de un detallado plan de implantación progresiva del Service Desk

10. Gestión de Incidentes
La Gestión de Incidentes 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.
• El Service Desk de "Catering S.A."ha recibido una llamada del encargado
de suministros del comedor de uno de sus clientes.
• Dicho encargado informa de que a pesar de haber solicitado una nueva
partida de helados hace unos días a través de la web ésta aún no se ha
recibido y apenas quedan reservas en sus frigoríficos
• El operador del Service Desk busca en la base de datos de pedidos y
confirma que se realizo el pedido hace varios días pero también observa
que éste se ha guardado defectuosamente.
• El operador intenta desde su puesto repetir la orden pero el sistema sigue
fallando.
• El operador toma, basándose en los protocolos establecidos, las siguientes
decisiones:
• Evalúa la prioridad: aunque el impacto es bajo, el incidente es urgente
pues el cliente necesita rápidamente el suministro.
• Registra los datos del incidente.
• Consulta la Base de Conocimiento para investigar si el incidente es
consecuencia de un error conocido y cuales son las posibles soluciones
temporales
• Propone una solución temporal al cliente: indica una zona reservada de la
web desde la que se pueden realizar pedidos "urgentes" vía email.
• Contacta con el departamento de sistemas previendo que el incidente
pueda repetirse a lo largo de la mañana.
• Consulta, mediante la aplicación que monitoriza las existencias de
almacén, la disponibilidad de los helados solicitados.
• Tranquiliza al cliente asegurándole que mediante su servicio express
recibirá los helados solicitados antes del mediodía.
• Por otro lado el departamento de sistemas:
• Realiza una serie de pruebas y comprueba que, de manera general, el
sistema funciona correctamente.

11. • No consigue identificar la causa del incidente.
• Contacta con el Service Desk y propone que se eleve el problema a la
Gestión de Problemas pero pre-calificando su prioridad como baja.
El Service Desk recibe la información y determina que:
• Dado el bajo impacto del incidente y el hecho de que se haya
proporcionado al cliente una solución temporal satisfactoria no se requiere
un escalado superior.
• Registra la solución temporal del incidente junto a la información
proporcionada por el departamento de sistemas.
• Da por cerrado el incidente.
Gestión de Problemas
Las funciones principales de la Gestión de Problemas son:
• Investigar las causas subyacentes a toda alteración, real o potencial, del servicio
TI.
• Determinar posibles soluciones a las mismas.
• Proponer las peticiones de cambio (RFC) necesarias para restablecer la calidad
del servicio.
• Realizar Revisiones Post Implementación (PIR) para asegurar que los cambios
han surtido los efectos buscados sin crear problemas de carácter secundario.
• La Gestión de Problemas puede ser:
• Reactiva: Analiza los incidentes ocurridos para descubrir su causa y
propone soluciones a los mismos.
• Proactiva: Monitoriza la calidad de la infraestructura TI y analiza su
configuración con el objetivo de prevenir incidentes incluso antes de que
estos ocurran.
• El Service Desk de "Catering S.A."ha informado a la Gestión de Problemas
sobre una incidencia a la que no se le pudo asociar un error conocido y que
causo una interrupción de bajo impacto en el servicio.
La Gestión de Problemas decide analizar el problema utilizando el protocolo
establecido.
• • Identificación del problema.
• Clasificación del problema.
• Establecimiento de las posibles causas.
• Comprobación de la causa más probable.
• Verificación de la causa verdadera.

12. • Identificación: En nuestro caso el problema es sencillo de definir:
• La aplicación de pedidos online muestra, de forma no previsible, errores
en el registro de ciertos pedidos, sin que este error parezca tener
correlación con otros componentes de hardware / software.
• Clasificación: La clasificación se adaptaría a los siguientes parámetros:
• Identificación: Problemas en el registro de pedidos.
• Origen: Módulo de pedidos online.
• Frecuencia: el problema no es recurrente, es la primera vez que se
detecta.
• Impacto: leve. El incidente ha sido resuelto sin una interrupción grave del
servicio.
• Posibles causas: Entre las causas más probables figuran:
• Errores en la programación del lado cliente de la aplicación.
• Errores en los módulos de registro del servidor web.
• Errores de configuración de la base de datos.
Los analistas deciden que el origen más probable del problema esté en los
módulos de registro de la aplicación.
• Comprobación de la causa más probable: con la ayuda de la información
registrada por la Gestión de Incidentes:
• Se intenta reproducir el problema.
• Se comprueba que el error sólo se reproduce con una determinada marca
de helados.
• Se comprueba que dicha marca de helados tiene un apóstrofe en el
nombre y que eliminado éste se registra el pedido sin problemas.
• Verificación:
• Se crea un entorno de pruebas que reproduce el módulo de interés en el
entorno de producción.
• Se introducen las modificaciones necesarias en la programación.
• Se comprueba el correcto registro del pedido.
• El problema se ha convertido en un error conocido, es ahora tarea del
Control de Errores:
• Elevar una RFC con la solución propuesta.
• Llevar a cabo la revisión post-implementación en el caso de que la
Gestión de Cambios considere oportuno implementar la RFC.

13. Gestión del Nivel del Servicio
• El objetivo último de la Gestión de Niveles de Servicio es poner la
tecnología al servicio del cliente.
La tecnología, al menos en lo que respecta a la gestión de servicios TI, no
es un fin en sí misma sino un medio para aportar valor a los usuarios y
clientes.
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.
• La dirección de "Catering S.A."ha decidido implementar una Gestión de
Niveles de Servicio que adapte a las necesidades de su organización los
principios y recomendaciones de ITIL.

14. Para llevar a cabo esta tarea de la forma más eficiente posible se han
determinado una serie de acciones iniciales que se resumen en:
• Designación de un Gestor del proceso.
• Elaboración de un catálogo de servicios.
• Desarrollo de un Plan Integral de Calidad del Servicio.
• Creación de "plantillas" para la creación de SLAs asociados a sus
principales servicios.
Gestor de Niveles de Servicio.
La dirección ha encargado a uno de sus directivos con más amplia experiencia en
la relación con los clientes asumir el puesto de Gestor de Niveles de Servicio.
Su principal función es negociar y acordar, en representación de "Catering S.A.",
la provisión de servicios con los clientes.
Sus responsabilidades específicas incluyen:
• Elaborar y mantener actualizado un catálogo de los servicios ofrecidos por
"Catering S.A.".
• Determinar la estructura general de los SLAs, OLAs y UCs.
• Negociar los SLAs, OLAs y UCs con clientes y proveedores
• Supervisar el cumplimiento de los acuerdos de provisión del servicio con clientes
y proveedores.
• Mantener informados a la Dirección y la organización TI sobre el rendimiento de
todo el proceso.
• Determinar los Planes de Mejora del Servicio que solucionen las deficiencias en
la calidad de los servicios prestados y/o adapten estos servicios a las nuevas
necesidades de los clientes y a los últimos avances tecnológicos.
• Interactuar con los otros procesos TI para asegurar que todos ellos reciben y
aportan la información necesaria para el óptimo funcionamiento de la
organización.
Elaboración del Catálogo de Servicios.
Se ha decidido estructurar el Catálogo de Servicios en función de los diferentes
tipos de clientes que contratan los servicios de "Catering S.A.":
• Particulares.
• Pequeñas empresas.
• Grandes corporaciones e instituciones y organismos públicos.
El objetivo del catálogo no es sólo dar a conocer los diferentes servicios sino
mostrar claramente al (potencial) cliente cuales son las diferencias entre las
diferentes opciones de un mismo "servicio base".
Para ello se elabora un catálogo online que permite comparar las diferentes
"versiones" y realizar una estimación preliminar de los costes basándose en las
diferentes opciones seleccionadas.

15. La descripción de cada servicio incluye información adicional sobre:
• Plazos de entrega.
• Disponibilidad del servicio (festivos, horarios nocturnos, etc.).
• Servicios auxiliares.
• WebServices asociados.
• Disposiciones legales aplicables.
• Programas de fidelización.
• Soporte online.
Plan de Calidad del Servicio.
Para asegurar la calidad del servicio se desarrolla un SQP que determina:
• La responsabilidad de cada uno de los departamentos en el proceso de provisión
del servicio.
• Planes de contingencia en casos de deterioro grave de la calidad del servicio.
• Indicadores clave de rendimiento y satisfacción del cliente.
• Métodos de supervisión y seguimiento en tiempo real de los procesos
involucrados en la prestación del servicio, como, por ejemplo, el reparto y la
provisión de mercancía.
• Protocolos de interacción del Service Desk con los clientes y usuarios.
• Los niveles de seguridad, disponibilidad, capacidad y redundancia necesarios
para asegurar la correcta provisión del servicio en colaboración con los
responsables de dichos procesos.
SLAs prototipo
A fin de evitar que la elaboración de los SLAs se convierta en una tarea
excesivamente compleja y tediosa se desarrollan plantillas para los diferentes
tipos de servicios y clientes.
Cada SLA prototipo incluye:
• Descripción general y no técnica de los servicios acordados.
• Responsables del acuerdo tanto por el lado cliente como proveedor.
• Plazos para la provisión del servicio.
• Duración del acuerdo y condiciones para su renovación y/o rescisión.
• Condiciones de disponibilidad del servicio.
• Soporte y labores de mantenimiento asociadas.
• Tiempos de respuesta.
• Tiempos de recuperación en casos de incidentes.
• Planes de contingencia si son de aplicación.
• Métodos de facturación y cobro.
• Criterios de evaluación de la calidad del servicio.

16. Gestión de la Continuidad del Servicio
• La Gestión de la Continuidad del Servicio se preocupa de impedir que una
imprevista y grave interrupción de los servicios TI, debido a desastres
naturales u otras fuerzas de causa mayor, tenga consecuencias
catastróficas para el negocio.
• La estrategia de la Gestión de la Continuidad del Servicio (ITSCM) debe
combinar equilibradamente procedimientos:
• Proactivos: que buscan impedir o minimizar las consecuencias de una
grave interrupción del servicio.
• Reactivos: cuyo propósito es reanudar el servicio tan pronto como sea
posible (y recomendable) tras el desastre.
• La ITSCM requiere una implicación especial de los agentes involucrados
pues sus beneficios sólo se perciben a largo plazo, es costosa y carece de
rentabilidad directa. Implementar la ITSCM es como contratar un seguro
médico: cuesta dinero, parece inútil mientras uno está sano y desearíamos
nunca tener que utilizarlo, pero tarde o temprano nos alegramos de haber
sido previsores.
• La organización TI de "Catering S.A."carece de una Gestión de la
Continuidad del Servicio que merezca ese nombre.
La gestión de "Catering S.A."es consciente de la importancia que tienen en
la actualidad los servicios TI en toda su cadena de producción y distribución
y pretende corregir esa situación.
De entre todos los servicios TI, los asociados a la gestión de existencias,
por estar compuestas de productos perecederos, y los servicios online de
pedidos son considerados de importancia estratégica por la dirección de la
empresa. Por ello se decide que en primera instancia la ITSCM debe
garantizar la continuidad de dichos servicios en un plazo nunca superior a
las 8 horas mientras que se establecen objetivos menos ambiciosos para
otros servicios.
Se asigna a un ejecutivo senior del departamento TI el papel de gestor del
proceso y se le encarga coordinar todas las actividades con la Gestión de la
Continuidad del Negocio.