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.

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:

• 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.

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?).

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:

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.

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.

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.

•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

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.

• 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.

• 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.

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.

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.

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.

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.