4. Operacion de Los Servicios TI ITIL

8/16/2019 4. Operacion de Los Servicios TI ITIL

1/35

ITIL V3. Operación de los servicios TI


2/35

Contenidos1Definición y objetivos ....................................................................................... 4

2Procesos .......................................................................................................... 42.1Gestión de Eventos ....................................................................................... 52.1.1Procesos ..................................................................................................... 5

2.1.1.1Aparición de eventos ............................................................................... 62.1.1.2Notificación de eventos ............................................................................ 62.1.1.3Detección y filtrado de eventos ................................................................ 62.1.1.4Clasificación de eventos .......................................................................... 62.1.1.5Correlación ............................................................................................. 72.1.1.6Disparadores ........................................................................................... 72.1.1.7Opciones de respuesta ........................................................................... 72.1.1.8Revisión de acciones y cierre ................................................................. 8

2.1.2Control del proceso .................................................................................... 82.2Gestión de Incidencias .................................................................................. 8

2.2.1Procesos ..................................................................................................... 82.2.1.1Registro y Clasificación ........................................................................... 82.2.1.2Análisis, Resolución y Cierre .................................................................. 9

2.2.2Control del proceso .................................................................................. 102.3Gestión de Peticiones ................................................................................. 11

2.3.1Procesos ................................................................................................... 112.3.1.1Selección de peticiones de un menú ..................................................... 112.3.1.2Aprobación financiera de la petición ...................................................... 112.3.1.3Tramitación y cierre .............................................................................. 11

2.3.2Control del proceso .................................................................................. 122.4Gestión de Problemas ................................................................................. 12

2.4.1Procesos ................................................................................................... 132.4.1.1Control de Problemas ........................................................................... 132.4.1.2Control de Errores ................................................................................. 14

2.4.2Control del proceso .................................................................................. 152.5Gestión de Acceso a los Servicios ............................................................... 15

2.5.1Procesos ................................................................................................... 162.5.1.1Petición de acceso ................................................................................ 162.5.1.2Verificación ............................................................................................ 16

2.5.1.3Monitorización de identidad .................................................................. 162.5.1.4Registro y monitorización de accesos.................................................... 172.5.1.5Eliminación y restricción de derechos ................................................... 17

2.5.2Control del proceso .................................................................................. 173Funciones ....................................................................................................... 18

3.1Centro de Servicios ..................................................................................... 183.1.1Implementación ........................................................................................ 193.1.2Estructura ................................................................................................. 193.1.3Funciones ................................................................................................ 203.1.4Control de la unidad .................................................................................. 20

3.2Gestión de Operaciones TI ......................................................................... 21

3.2.1Implementación ........................................................................................ 22


3/35

3.2.2Estructura ................................................................................................. 223.2.3Funciones ................................................................................................ 23

3.2.4Control de la unidad .................................................................................. 233.3Gestión Técnica ........................................................................................... 243.3.1Implementación ........................................................................................ 253.3.2Estructura ................................................................................................. 253.3.3Funciones ................................................................................................. 263.3.4Control de la unidad ................................................................................. 27

3.4Gestión de Aplicaciones .............................................................................. 283.4.1Implementación ........................................................................................ 293.4.2Estructura ................................................................................................. 293.4.3Funciones ................................................................................................. 303.4.4Control de la unidad .................................................................................. 31

4Puesta en marcha ......................................................................................... 334.1Monitorización y Control .............................................................................. 334.2Factores de éxito y riesgos ......................................................................... 34

5Glosario .......................................................................................................... 356Referencias ................................................................................................... 35


4/35


5/35

ITIL V3. Operación de los Servicios TI

ITIL V3 Operación de los Servicios TI - 5 -

Una vez que el servicio está operando es necesario monitorizar todos los eventosimportantes que se produzcan para poder anticiparse a los problemas, resolverlos oincluso prevenirlos.

Se denomina evento a todo suceso detectable asociado a la prestación de unservicio. No tiene porqué ser un indicador de problemas.

La herramienta esencial de Gestión de Eventos es el sistema de monitorización.Puede ser de dos tipos:

• Sistema de monitorización activa. Se comprueban los CIs uno a uno paraverificar su estado y disponibilidad. Si detecta excepciones, la herramienta demonitorización genera una alerta y la envía al equipo o mecanismo de controlasignado.

• Sistema de monitorización pasiva. Detectan y correlacionan alertasoperacionales generadas por los propios CIs.

Los eventos no tienen por qué ser siempre negativos, también pueden ser rutinarios, lonosmal es que se clasifiquen los eventos por su impacto:

• Eventos que indican que el servicio opera con normalidad.• Eventos que indican una operación inusual pero no excepcional, deberemos

incrementar el nivel de monitorización.• Eventos que indican una excepción.

Las tareas habituales de Gestión de Eventos son: detectar el evento, analizar su

impacto, documentarlo y notificarlo al proceso encargado de su resolución:

• A Gestión de Incidencias, si el evento supone una interrupción del servicio.• A Gestión de Problemas, si el evento se repite a menudo y es preciso analizar

las causas del mismo.

2.1.1 Procesos

Las actividades de la Gestión de Eventos son:

• Aparición de eventos. Aparece un evento en el sistema.• Notificación de eventos. Se notifica al gestor.• Detección y filtrado de eventos. La notificación llega al gestor (persona o

software), quien evalúa si el evento está asociado a una operación normal,inusual o excepcional.

• Clasificación de eventos. Si el evento implica una operación inusual oexcepcional, se le asigna una categoría y una prioridad.

• Correlación. Se analiza si existen eventos similares, así como la importanciadel evento en sí mismo y se decide si es necesario tomar medidas.

• Disparadores. Se ponen en marcha los mecanismos necesarios para darrespuesta al evento.

• Opciones de respuesta. Se eligen las soluciones a adoptar.


6/35



• Revisión de acciones y cierre. Se revisan los eventos importantes paradeterminar si se han tratado correctamente. Se cierra el proceso de Gestión deEventos.

2.1.1.1 Aparición de eventos

El flujo de trabajo del proceso de Gestión de Eventos se inicia cuando aparece unevento. Los eventos ocurren continuamente, pero no todos son detectados oregistrados. Es importante analizar en profundidad qué eventos se deben registrar.

2.1.1.2 Notificación de eventos

Casi todos los CIs informan sobre su estado de una de las siguientes maneras:

•

El CI genera una notificación ante determinadas situaciones preconfiguradas.• Una herramienta de gestión solicita periódicamente al CI una notificación decontrol.

Las notificaciones asociadas a los eventos deben:

• Ser estandarizadas, casi todos los eventos se comunican en formato estándarSNMP(Simple Network Management Protocol ).• Contener la mayor cantidad de información posible sobre el evento.• Enviarse al destinatario adecuado, un receptor inadecuado puede no saberinterpretar lo que ha sucedido.

2.1.1.3 Detección y filtrado de eventos

Cuando la notificación llega a su destino, que puede ser una persona o unaherramienta de gestión, se procede al filtrado del mismo.

El filtrado consiste en decidir si el suceso merece una consideración en profundidadpor parte de otra unidad de gestión o si por el contrario, una vez leído puede serignorado.

2.1.1.4 Clasificación de eventos

Cuando un evento llega a éste proceso es porque ha sucedido algo inesperado y se

deberá evaluar en qué medida afecta al servicio.

Los eventos se clasifican según el impacto que pueda suponer al servicio. Cadaorganización define sus propios niveles de impacto, pero en todas las organizacionesnos encontramos con al menos tres niveles típicos:

• Informativo. Nivel asignado a eventos que no implican ninguna excepción. Enprincipio no habrá ninguna respuesta.

• Alerta. Nivel asignado a eventos que indican que el servicio se aproxima a unumbral. La respuesta es avisar a las personas, herramientas o procesosapropiados para que tomen las medidas necesarias que eviten futurasexcepciones.


7/35



• Excepción. Nivel asignado a eventos que implican incumplimento de SLAs yOLAs. Las excepciones pueden representar un fallo total, un cese en unafuncionalidad o una disminución del rendimiento. Sin embargo, no tienen porqué ser errores.

2.1.1.5 Correlación

La Correlación consiste en dimensionar la importancia del evento, establecerconexiones con otros eventos y decidir si debe darse una respuesta.

La importancia del evento depende de los siguientes factores:

• Categoría asignada al evento.• Prioridad asignada al evento.•

Número de eventos similares registrados anteriormente.• Si existe alguna acción asociada al evento.• Si se requieren datos adicionales para investigar el evento con posterioridad o

incluso datos procedentes de otros sistemas de información.

2.1.1.6 Disparadores

Llamamos disparadores a las respuestas asociadas a los eventos. Sólo hay respuestasi Correlación lo determina oportuno tras evaluar el evento. Existen varios tipos dedisparadores:

• Disparador de Incidentes. Se crean un registro en el Sistema de Gestión de

Incidencias.• Disparador de Cambios. Se genera y envía una RFC para Gestión de

Cambios.• Disparadores procedentes de una RFC aprobada o desautorizada. Se

envía toda la información relacionada para que la Gestión de Cambiosinvestigue lo ocurrido.

• Disparadores de Script. Se lanza un script corrector, por ejemplo reiniciar unequipo.

• Disparadores de teléfono móvil. Se comunica algo a algún responsable.• Disparadores de base de datos. Se ajusta algo en BBDD, por ejemplo se

ajusta algún permiso.

2.1.1.7 Opciones de respuesta

Existen muchos tipos de respuestas a los eventos, las más comunes son:

• Registro de eventos. Se documenta lo ocurrido.• Respuesta automática. Se aplican a eventos conocidos.• Alerta e intervención humana. Se avisa a alquien para que desempeñe una

acción específica.• Emisión de RFC. Se genera y envía un solicitud de cambio.• Apertura de un registro de incidencia. Se registra la incidencia.• Apertura de un vínculo a un registro de problema. Se registra el problema.


8/35



Ante un suceso no tiene porqué darse un único tipo de respuesta, lo habitual es unacombinación de varias.

2.1.1.8 Revisión de acciones y cierre

Antes de dar por terminado el proceso de Gestión de Eventos, es preciso revisartodas las excepciones o eventos importantes para garantizar que se han tratadocorrectamente.

2.1.2 Control del proceso

A la hora de evaluar la eficiencia y efectividad del proceso de Gestión de Eventos deben generarse estadísticas del número de eventos por categoría, importancia y tipode respuesta.

2.2 Gestión de Incidencias

Una incidencia es cualquier evento que no forma parte de la operación estándarde un servicio y que causa, o puede causar, una interrupción o una reducción decalidad del mismo.

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

• Registro y clasificación de la incidencia.• Restaurar el servicio según el SLA, de la manera más rápida y eficaz posible.

2.2.1 Procesos

2.2.1.1 Registro y Clasificación

Registro

El registro de la incidencia es el primer paso para una correcta gestión del mismo.Debe realizarse inmediatamente, pues resulta mucho más costoso hacerloposteriormente y se corre el riesgo de que la aparición de nuevas incidencias demoreindefinidamente el proceso.

El registro implica los sigueintes pasos:

• Admisión a trámite del incidente. El Centro de Servicios evalúa si el serviciorequerido (por el cliente) está incluído en el SLA y en caso contrario reenviarloa una autoridad competente.

• Comprobación de que ese incidente aún no ha sido registrado. Es muyhabitual que más de un usuario notifique la misma incidencia y por lo tanto hande evitarse duplicaciones innecesarias.

• Asignación de referencia. Se asigna un identificador unívoco al incidente queserá la referencia tanto en procesos internos como en las comunicaciones conel cliente.


9/35



• Registro inicial. Se introduce en BBDD la información básica asociada alincidente: hora, descripción del incidente, sistemas afectados...

• Información de apoyo. Se introducirá en BBDD cualquier información

adicional que puede ser solicitada al cliente a través de un formularioespecífico, o que puede ser obtenida de la propia CMDB.

• Notificación del incidente. Cuando el incidente pueda afectar a otrosusuarios, éstos deben ser notificados para que conozcan cómo esta incidenciapuede afectar su flujo habitual de trabajo.

Clasificación

Es frecuente que existan múltiples incidencias concurrentes, por lo que es necesariodeterminar un nivel de prioridad para la resolución de las mismas.

La prioridad del incidente puede cambiar durante su ciclo de vida. Por ejemplo, sepueden encontrar soluciones temporales que restauren aceptablemente los niveles deservicio y que permitan retrasar el cierre del incidente sin graves repercusiones.

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

• Categorización. Se asigna una categoría dependiendo del tipo de incidente odel grupo de trabajo responsable de su resolución. Se identifican los serviciosafectados por el incidente.

• Establecimiento del nivel de prioridad. Dependerá del impacto y la urgencia.El impacto depende de cómo el incidente afecta a los procesos de negocio y/odel número de usuarios afectados. La urgencia viene determinada por el tiempo

máximo de demora que acepte el cliente para la resolución de la incidencia y/oel nivel de servicio acordado en el SLA.• Asignación de recursos. Si el Centro de Servicios no puede resolver el

incidente en primera instancia, designará al personal de soporte técnicoresponsable de su resolución.

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

2.2.1.2 Análisis, Resolución y Cierre

En primer lugar se analiza si tenemos un incidente similar en la KB, en caso afirmativose aplica el procedimiento registrado.

Si el Centro de Servicios no es capaz de resolver el incidente, debe recurrirse a unespecialista o a algún superior jeraŕquico que tome una dec isión. A este proceso se ledenomina escalado.

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


10/35



Si fuera necesario, paralelamente a la resolución de la incidencia se puede emitir unaPetición de Cambio (RFC) que se enviaría a la Gestión de Peticiones. Por otro lado,si la incidencia fuera recurrente y no se encontrase una solución definitiva, se deberáinformar a la Gestión de Problemas para el estudio detallado de las causassubyacentes.

Cuando se soluciona un incidente se deben realizar las siguientes tareas:

• Confirmar con los usuarios que la solución es la solución satisfactoria.• Incorporar el proceso de resolución al Sistema de gestión del conocimiento del

servicio (SKMS).• Reclasificar el incidente si fuera necesario.• Actualizar la información en la Base de datos de la gestión de configuraciones

(CMDB) sobre los elementos de configuración (CIs) implicados en el incidente.•

Cierra el incidente.2.2.2 Control del proceso

Una correcta Gestión de Incidencias requiere de una infraestructura que facilite sucorrecta implementación. Entre ellos cabe destacar:

• Un sistema automático de registro de incidentes y relación con los clientes.• Un SKMS que permita comparar nuevos incidentes con incidentes ya

registrados y resueltos.• Una CMDB que permita conocer todas las configuraciones actuales y el

impacto que éstas puedan tener en la resolución del incidente.

Es indispensable la utilización de métricas que permitan evaluar de la forma másobjetiva posible el funcionamiento del servicio. Algunos de los aspectos clave aconsiderar son:

• Número de incidentes clasificados temporalmente y por prioridades.• Tiempos de resolución clasificados en función del impacto y la urgencia de los

incidentes.• Nivel de cumplimiento del SLA.• Costes asociados.• Uso de los recursos disponibles en el Centro de Servicios.• Porcentaje de incidentes, clasificados por prioridades, resueltos en primera

instancia por el Centro de Servicios.• Grado de satisfacción del cliente.

El proceso de Gestión de Incidencias deberá generar diversos tipos de informes:

• Informes para los clientes con información sobre el cumplimiento de los SLA.• Informes sobre el grado de satisfacción de los clientes con el servicio de

resolución de incidencias.• Disponer de Información Estadística sobre los tipos de incidentes, su gravedad,

su prioridad, los tiempos de respuesta, los recursos, costes, etc.


11/35



2.3 Gestión de Peticiones

Gestión de Peticiones se encarga de:

• Información a posibles clientes sobre los servicios existentes.• Atender las quejas, dudas y problemas de los clientes con los servicios

contratados.• Atender las peticiones de nuevos servicios, planteadas por los clientes.• Atender las peticiones de cambio (RFC), planteadas por los clientes.

Para realizar su trabajo, Gestión de Peticiones parte de las siguientes entradas:

• Descripción detallada del servicio, proporcionada por el Portfolio de Servicios.• Políticas de Seguridad, de la Gestión de Seguridad.

2.3.1 Procesos

Las actividades incluidas en el proceso de Gestión de Peticiones son:

• Selección de peticiones de un menú.• Aprobación financiera de la petición.• Tramitación y cierre.

2.3.1.1 Selección de peticiones de un menú

La Gestión de Peticiones ofrece a los usuarios un interfaz web donde registrar suspeticiones, gracias a ésta herramienta, el cliente puede canalizar sus peticiones conagilidad y la organización tiene las peticiones catalogadas por tipos, con lo que puederemitirlas al equipo de respuesta más adecuado.

2.3.1.2 Aprobación financiera de la petición

La mayoría de las peticiones conllevan un gasto. Por eso, antes de autorizar unapetición es principal determinar primero los costes que ésta acarreará de ser cursada.

Se pueden definir, para determinadas peticiones estándares, unos precios fijos queayuden a gestionar con rapidez aquellos casos más frecuentes.

2.3.1.3 Tramitación y cierre

Esta actividad consiste en cursar la petición. Las acciones a desempeñar dependeránde la naturaleza de la misma.

El Centro de Servicios puede encargarse de las más simples, mientras que otrasprecisarán de una intervención especializada.

Una vez resuelta la petición, se notifica al Centro de Servicios para que compruebe siel usuario está satisfecho con el resultado y proceda a su cierre.


12/35




El control del proceso de Gestión de Peticiones se lleva a cabo mediante informesperiódicos, que deben aportar los siguientes datos:

• Número total de peticiones.• Tiempo medio de duración de la gestión de cada tipo de petición.• Número y porcentaje de peticiones completadas en los tiempos acordados.• Coste medio de cada tipo de petición.• Nivel de satisfacción del cliente con la gestión de las peticiones.

2.4 Gestión de Problemas

Las funciones principales de la Gestión de Problemas son:

• Investigar las causas de toda alteración del servicio.• Determinar posibles soluciones a las mismas.• Proponer RFCs para restablecer la calidad del servicio.• Realizar Revisiones Post-Implementación (PIR) para asegurar que los

cambios han surtido efecto sin producir nuevos problemas.

Gestión de Problemas puede trabajar de dos formas:

• Reactiva. Analiza los incidentes ocurridos para descubrir su causa y proponesoluciones a los mismos.

• Proactiva. Monitoriza la calidad de la infraestructura y analiza su configuracióncon el objetivo de prevenir incidentes antes de que éstos ocurran.

Las diferencias entre Gestión de Incidencias y Gestión de Problemas son:

• Gestión de Incidencias. Tiene como objetivo el restablecer rápidamente lacalidad del servicio, no determinar las causas de las incidencias.• Gestión de Problemas. Es quien debe determinar las causas y proponer lassoluciones a incidentes recurrentes o incidentes con un fuerte impacto en lainfraestructura de la organización.

Cabe diferenciar entre:

• Incidente. Es cualquier situación atípica en el servicio.• Problema. Es el factor desconocido que está originando incidentes.• Error conocido. Es el factor conocido que está originando incidentes.

2.4.1 Procesos

Las principales actividades de la Gestión de Problemas son:

• Control de Problemas.• Control de Errores.


13/35



Y cuando la estructura de la organización lo permite, desarrollar una Gestión deProblemas Proactiva que ayude a detectar problemas incluso antes de que éstos semanifiesten provocando un deterioro en la calidad del servicio.

2.4.1.1 Control de Problemas

Control de Problemas se encarga de registrar y clasificar los problemas paradeterminar sus causas y convertirlos en errores conocidos, posteriormente Control deErrores pueda proponer las soluciones correspondientes.

Control de Problemas se compone de tres fases:

• Identificación del problema.• Clasificación del problema y Asignación de Recursos.•

Análisis y Diagnóstico del problema.Fase 1. Identificación del problema

En esta fase se identifican los problemas. Todas las áreas de la infraestructura debeninformar a Gestión de Problemas de cualquier síntoma que pueda ser señal de undeterioro en el servicio.

Las principales fuentes de información utilizadas son:

• Base de Datos de Incidencias. En principio, cualquier incidente del que no seconocen sus causas es un problema en potencia. Sin embargo, se debe

analizar si el incidente es aislado o su impacto en la estructura antes deelevarlo a la categoría de problema.• Análisis de la infraestructura. Gestión de Problemas debe analizar, en

colaboración con Gestión de Disponibilidad y de Gestión Capacidad, losdiferentes procesos y determinar en que aspectos se debe reforzar lossistemas y estructuras para evitar futuros problemas.

• Deterioro de los Niveles de Servicio. El descenso del rendimiento sueleindicar la existencia de problemas que no se han manifestado como incidentes.

Fase 2. Clasificación del problema y Asignación de Recursos

La clasificación de problemas es debe centrarse en la naturaleza y posible impacto de

los mismos. La clasificación debe manejar información sobre:

• Causas del problema y síntomas asociados.• Posibles soluciones temporales.• Servicios involucrados.• Nivele de prioridad e impacto.• Estado: activo, error conocido, cerrado.

Una vez clasificado el problema y determinada su prioridad, se deben asignar losrecursos necesarios para su solución. Estos recursos deben ser suficientes paraasegurar que los problemas asociados son tratados eficazmente y así minimizar suimpacto en la infraestructura.


14/35



Fase 3. Análisis y Diagnóstico del problema

Los objetivos principales del proceso de análisis son:

• Determinar las causas del problema.• Proporcionar soluciones temporales a Gestión de Incidencias para minimizar el

impacto del problema.

No todos los problemas son de hardware o software. Es frecuente que el problemaesté causado por errores de procedimiento, errores en la documentación, falta decoordinación entre diferentes aŕeas, un bug bien conocido de alguna de lasaplicaciones utilizadas, etc.

Una vez diagnosticadas las causas del problema, éste se convierte en un ErrorConocido y se remite a Control de Errores para su posterior procesamiento.

2.4.1.2 Control de Errores

Una vez que el Control de Problemas ha determinado las causas de un problema,es responsabilidad del Control de Errores el registro del mismo como errorconocido.

Control de Errores se compone de tres fases:

Fase 1. Registro de errores

Al registrar un error conocido se debe indicar siempre una solución temporal quepermita minimizar el impacto de los incidentes asociados. Éste registro es por tantouna herramienta de vital importancia para Gestión de Incidencias.

Fase 2. Análisis y Solución

Se deben investigar diferentes soluciones para cada error, evaluando en cadamomento:

• El impacto de cada solución en la infraestructura.• Los costes asociados a cada solución.• Las consecuencias de la solución sobre los SLAs.

Una vez determinada la solución óptima debemos registrarla.

Seguidamente deben valorarse las siguientes cuestiones:

• ¿Los beneficios justifican los costes asociados?• ¿Es la solución provisional aportada suficiente para mantener unos niveles de

calidad de servicios aceptable?• ¿Es conveniente demorar la solución?


15/35



Si se determina que el problema debe ser solucionado, se emite un RFC a Gestión deCambios, que es quien se encarga de implementar los cambios propuestos.

Fase 3. Revisión Post Implementación (PIR) y Cierre

Antes de cambiar el estado del problema a “cerrado” se debe realizar una PIR, quedetermine si los cambios realizados han cerrado todos los incidentes relacionados coneste problema. Si es así se cierra el problema, se emiten los informescorrespondientes y se actualiza la Base de Datos de Errores Conocidos (KEDB) parafuturas ocasiones.


Para evaluar el rendimiento de Gestión de Problemas se deben emitir informesperiódicos de varios tipos:

• Informes de Rendimiento de la Gestión de Problemas . Detallan el númerode errores resueltos, la eficacia de las soluciones propuestas, los tiempos derespuesta y el impacto en la Gestión de Incidencias.

• Informes de Gestión Proactiva. Detallan las acciones llevadas a cabo para laprevención de futuros problemas y los resultados de los análisis realizadossobre la adecuación de las estructuras a las necesidades de la empresa.

• Informes de Calidad de Productos y Servicios. Evalúan el impacto de losproductos contratados en la calidad del servicio, permitiendo decidir sobre elcambio de proveedores.

Una buena gestión de problemas debería traducirse en:

• Una disminución del número de incidentes.• Una resolución más rápida de los incidentes.• Mayor eficacia en la resolución de problemas.• Identificación proactiva de problemas.

2.5 Gestión de Acceso a los Servicios

Gestión de Acceso a los Servicios es el proceso encargado de otorgar permisos de

acceso a los servicios a aquellos usuarios autorizados e impedírselo a los usuarios noautorizados.

Gestión de Acceso a los Servicios recibe inputs de los siguientes procesos:

• Gestión de la Seguridad, que es quien establece las políticas de seguridadque deberá tener en cuenta Gestión de Acceso.

• Gestión del Catálogo del Servicio, que es quien aporta la documentaciónsobre los servicios cuyo acceso solicitan los usuarios.

• Gestión de Peticiones y Centro de Servicios, desde donde también llegansolicitudes de acceso a servicios.


16/35



Gestión de Acceso a los Servicios genera outputs para los siguientes procesos:

• Gestión de Incidencias, que se hará cargo de las peticiones de acceso que

representen una excepción.• Gestión Técnica y Gestión de Aplicaciones, que monitorizan los accesos y

comprueban si son autorizados o no.

2.5.1 Procesos

Las actividades de la Gestión de Acceso a los Servicios TI incluyen:

• Petición de acceso.• Verificación.• Monitorización de identidad.•

Registro y monitorización de accesos.• Eliminación y restricción de derechos.

2.5.1.1 Petición de acceso

Las reglas para establecer las peticiones de acceso normalmente están documentadasen el Catálogo de Servicios. Una petición de acceso puede llegar a través denumerosas vías:

• Desde RRHH. Por ejemplo, al contratar a una persona, al ascenderla,transferirla o cuando abandonan la empresa.

• Desde Gestión de Peticiones.• Etc.

2.5.1.2 Verificación

Gestión de Acceso, antes de autorizar el acceso al servicio debe verificar:

• La identidad del solicitante de acceso al servicio.• Que los motivos para acceder al acceso son pertinentes.

2.5.1.3 Monitorización de identidad

A medida que los usuarios trabajan en la organización, sus roles van cambiando y, con

ellos, sus necesidades de acceso a servicios. Algunos ejemplos de cambios incluyen:

• Cambio de tarea. En este caso, es muy posible el usuario necesite acceso anuevos servicios, o incluso a otros completamente diferentes.

• Ascensos. Lo más probable es que el usuario requiera niveles de permisossuperiores en los mismos servicios a los que ya tenía acceso.

• Dimisión o fallecimiento. Es preciso eliminar por completo el acceso paraevitar que la cuenta de usuario se convierta en un agujero de seguridad.

• Jubilación. En muchas organizaciones, los empleados ya retirados todavíaconservan el privilegio de acceder a ciertos servicios, como por ejemplodescuentos en sus compras en determinadas plataformas de e-commerce.


17/35



• Acción disciplinar . En algunos casos, es posible que la organización necesiterestringir el acceso durante un tiempo para evitar que el usuario acceda adeterminados servicios. Esta circunstancia debería estar prevista en el sistemade asignación de permisos, evitando así tener que eliminar los derechos yluego crearlos de nuevo.

• Despido. Cuando un empleado es despedido, o cuando se emprendenacciones legales contra un cliente, el acceso debe ser revocadoinmediatamente. Además, la Gestión de Accesos, en conjunto con la Gestiónde Seguridad, debe tomar medidas para prevenir, detectar y evitar ataquescontra la organización procedentes de ese usuario.

La Gestión de Accesos debe comprender en profundidad el ciclo de vida de cada tipode usuario y documentarlo. Esto puede servir para automatizar el proceso y ahorrartiempo.

2.5.1.4 Registro y monitorización de accesos

Gestión de Acceso es responsable de asegurar que los permisos que ha otorgado seestán usando apropiadamente. Por este motivo es necesario monitorizar los accesos atodos los servicios.

Si se detectan abusos se deben comunicar a Gestión de Incidencias para queproceda a su resolución.

2.5.1.5 Eliminación y restricción de derechos

Gestión de Acceso no sólo se encarga de otorgar permisos, sino también derevocarlos o limitarlos. Se suelen eliminar derechos de acceso por:

• Fallecimiento.• Dimisión.• Despido.• Cambio de rol dentro de la organización.


La eficacia del proceso de Gestión de Acceso a los Servicios puede controlarsemediante informes regulares sobre los siguientes datos:

• Número de peticiones de acceso.• Número de accesos garantizados, por servicio, usuario, departamento, etc.• Número de incidentes que implicaron revocación de permisos.• Número de incidentes causados por una configuración incorrecta de los

accesos.

3 Funciones

Una función es una unidad especializada en la realización de una cierta actividad y esla responsable de su resultado. Las funciones incorporan todos los recursos y

capacidades necesarias para el correcto desarrollo de dicha actividad.


18/35



En la fase de Operación del servicio participan cuatro unidades o funciones:

• Centro de Servicios.• Gestión de Operaciones TI.• Gestión Técnica.• Gestión de Aplicaciones.

3.1 Centro de Servicios

El objetivo primordial del Centro de Servicios es servir de punto de contacto entre losusuarios y la Gestión de Servicios.

El Centro de Servicios funciona hoy en día, de centro neurálgico del soporte alservicio, desempeñando las siguientes tareas:

• Registrando y monitorizando incidentes.• Aplicando soluciones temporales a errores conocidos en colaboración con la

Gestión de Problemas.• Colaborando con Gestión de Configuraciones para asegurar la actualización

de las bases de datos correspondientes.• Gestionando, en colaboración con la Gestión de Cambios y de Entregas y

Despliegues, las solicitudes de cambio de los clientes.

Otra de las facetas del centro de servicio que cada día cobra mayor protagonismo es

el soporte al negocio, el Centro de Servicios, por su contacto permanente con elcliente puede:

• Identificar nuevas oportunidades de negocio.• Ofrecer una atención personalizada y agil a los clientes.

• Resolver rápidamente las interrupciones del servicio.• Informarse sobre el cumplimiento de los SLA.

El mecanismo de contacto con el cliente puede tomar diversas formas:

• Call Center. Gestiona un alto volumen de llamadas y redirige a los clientes aotras instancias de soporte, excepto en los casos más triviales.

• Centro de Soporte (Help Desk). Ofrece una primera línea de soporte técnicopara resolver rápidamente las interrupciones del servicio.• Centro de Servicios (Service Desk). Representa la interfaz para clientes y

usuarios de todos los servicios ofrecidos por la organización, con un enfoquecentrado en los procesos de negocio.

Beneficios del Centro de Servicios:

• Reducción de costes.• Una mejor atención al cliente.• Apertura de nuevas oportunidades de negocio.• Soporte al servicio proactivo.


19/35



3.1.1 Implementación

Montar un Centro de Servicios requiere una meticulosa planificación que deberácontemplar al menos las siguientes cuestiones técnicas:

• Cuáles son las necesidades a cubrir.• Cuáles han de ser sus funciones.• Quiénes serán los responsables del mismo.• Qué cualificaciones profesionales poseerán sus integrantes.• Si se deben externalizar ciertos servicios como, por ejemplo, el soporte técnico

del hardware.• Qué estructura de Centro de Servicios (distribuido, central o virtual) se adapta

mejor a nuestras necesidades y las de nuestros clientes.• Qué herramientas tecnológicas necesitamos.•

Qué métricas determinarán el rendimiento del Centro de Servicios.

La planificación deberá considerar igualmente cuestiones relativas al factor humano,dado que son igualmente importantes:

• Establecer protocolos de interacción con el cliente.• Motivar al personal que interactúa con el cliente.• Informar a los clientes de los beneficios de este nuevo servicio de soporte.• Sondear a los clientes para conocer mejor sus expectativas y necesidades.

El objetivo del Centro de Servicios es mejorar la satisfacción de los clientes, optimizarla imagen de nuestra organización e identificar nuevas oportunidades de negocio.

3.1.2 Estructura

El Centro de Servicios es el punto de contacto de la organización con el cliente. Espor lo tanto imprescindible que:

• Sea fácilmente accesible.• Ofrezca un servicio de calidad.• Mantenga informados a los clientes y registre toda la interacción con ellos.• Sirva de soporte al negocio.

Para cumplir estos objetivos es necesario que los integrantes del Centro de Servicios:

• Conozcan los protocolos de interacción con el cliente: guiones, checklists… • Dispongan de software para registrar la interacción con los usuarios.• Sepan cuando escalar a instancias superiores discusiones sobre cumplimiento

de SLA.• Tengan acceso a las bases de conocimiento para ofrecer mejor servicio a los

usuarios.• Reciban formación sobre los productos y servicios de la empresa.

Estructura física

Existen distintas tipologías para un Centro de Servicios:


20/35



• Centro de Servicios Local. El centro de servicio está ubicado en el mismolugar donde están los usuarios a los que atiende. Es muy habitual recurrir a estemodelo cuando existen diferencias lingüísticas, políticas, etc.• Centro de Servicios Centralizado. Todos los centros de servicio locales seconcentran en un único lugar para ahorrar costes.• Centro de Servicios Virtual. En un mix entre las dos opciones anteriores quese basa en las facilidades ofrecidas por las redes de comunicación actuales.• Centro de Servicios 24/7. Consiste en ubicar una serie de Centros deServicios Locales en distintas zonas horarias con el fin de cubrir de forma conjunta las24 horas del día durante los 7 días de la semana.• Centros de Servicios Especializados. Consiste en especializar cada centrode servicios en cierto tipo de incidentes.

3.1.3 Funciones

La función principal del Centro de Servicios es gestionar la relación con los clientes yusuarios. Las actividades esenciales de un Centro de Servicios son:

• Gestión de Incidentes. El Centro de Servicios debe ofrecer una primera líneade soporte para la solución de todas las interrupciones de servicio y/o peticiones deservicio que puedan cursar los clientes y usuarios.• Centro de información. El Centro de Servicios debe informar a clientes yusuarios, sobre nuevos servicios, nuevas versiones para corregir errores, elcumplimento de SLAs.• Relaciones con los proveedores. El Centro de Servicios es responsable de la

relación con los proveedores.

3.1.4 Control de la unidad

La mejor medida del éxito de un Centro de Servicios es la satisfacción del cliente.

En los informes de control se deben considerar aspectos tales como:

• Tiempo medio de respuesta a solicitudes cursadas por correo electrónico yteléfono o fax.

• Porcentaje de incidentes que se cierran en primera línea de soporte.• Porcentaje de consultas respondidas en primera instancia.• Análisis estadísticos de los tiempos de resolución de incidentes organizados

según su urgencia e impacto.• Cumplimiento de los SLAs.• Número de llamadas gestionadas por cada miembro del personal del Centro de

Servicios.• Realizar encuestas entre los clientes para evaluar el grado de satisfacción

respecto a los servicios prestados. Ésta encuesta se puede realizar al cerraruna incidencia.

3.2 Gestión de Operaciones TI


21/35



La Gestión de Operaciones es la unidad responsable del mantenimiento y la gestióncontinua de la infraestructura de la organización TI, y se centra especialmente enasegurar que los servicios cumplen los niveles acordados.

En otras palabras, podríamos decir que la Gestión de Operaciones engloba todas lasactividades del día a día dedicadas al mantenimiento de la infraestructura y a asegurarque los servicios se están prestando con normalidad.

A continuación, resumiremos algunos aspectos clave de la Gestión de Operaciones:

• Trabaja para asegurar que un dispositivo, sistema o proceso está funcionando.• Lleva a cabo los planes.• Está enfocada a las actividades a corto plazo, aunque éstas generalmente se

repiten durante un largo periodo de tiempo.•

El equipo que ejecuta estas actividades ha de estar muy especializado, por loque a menudo requiere de una formación específica.• Hay una tendencia a establecer acciones repetitivas y fiables para asegurar el

éxito de la operación del servicio.• Es en la Gestión de Operaciones es donde el valor real de la organización se

mide y distribuye.• Depende directamente de las inversiones tanto en equipamiento como recursos

humanos.• El valor generado debe superar el coste de la inversión y otros gastos

indirectos.

Los objetivos de la Gestión de Operaciones TI consisten en:

• Mantenimiento del status quo de los procesos y actividades de la organizaciónpara alcanzar estabilidad en el día a día.

• Escrutinio regular y mejoras para alcanzar un servicio mejorado con costesreducidos, manteniendo la estabilidad.

• Aplicación rápida de habilidades operacionales para diagnosticar y resolvercualquier fallo que ocurra en las operaciones.


Esta labor se desarrolla de acuerdo a los estándares de rendimientos definidosdurante la fase de Diseño. Los requisitos generales para que la Gestión de

Operaciones desempeñe correctamente su trabajo son:

• Comprender en profundidad cómo se emplea la tecnología para prestarservicios.

• Comprender la importancia relativa y el impacto de esos servicios en elnegocio.

• Los procedimientos y manuales que delimitan los roles operacionales tanto enla gestión de la tecnología como en la prestación de servicios.

• Disponer de un conjunto de métricas claramente diferenciadas que informensobre la culminación de objetivos de servicio, y mantengan informados a losgestores TI sobre la eficiencia y efectividad de las Operaciones TI.


22/35



• Los equipos de operaciones TI deben comprender exactamente cómo afecta elrendimiento de la tecnología a la prestación de servicios.

• Una estrategia de gasto orientada a equilibrar los requisitos de las distintasunidades de negocio con los ahorros disponibles gracias a la optimización de latecnología existente o la inversión en nueva tecnología.

• Una estrategia de inversión basada en retorno del valor, más que retorno delgasto.

3.2.2 Estructura

En algunas organizaciones, un solo departamento se ocupa de desarrollar lasactividades de la Gestión de Operaciones TI, mientras que en otros algunasactividades se centralizan y otras las asumen otros departamentos especializados dela organización.

Las dos funciones de la Gestión de Operaciones, que trataremos en profundidad en elsiguiente apartado, suelen conformar estructuras organizacionales por sí mismas:

• Control de Operaciones, cuya plantilla generalmente se organiza en turnos deoperadores encargados de asegurar que las tareas rutinarias se llevan a cabo.El Control de Operaciones también desempeña tareas de monitorización ycontrol, para lo que a menudo recurre a unidades específicas como el Puentede Operaciones o un Centro de Operaciones en Red.

• Gestión de Instalaciones, encargada de supervisar el mantenimiento de todoel equipamiento físico. A menudo está ubicada junto a la Gestión Técnica y deAplicaciones en grandes centros de datos.

3.2.3 Funciones

Las actividades de la Gestión de Operaciones TI están íntimamente ligadas con lamonitorización y supervisión, al ser ésta la responsable de que la infraestructura de laorganización funcione, especialmente en lo que se refiere a la prestación de servicios.

A continuación, describimos algunas de las actividades que desarrolla la Gestión deOperaciones TI dentro de la organización:

Control de Operaciones

El objetivo de esta función consiste, como su propio nombre indica, en supervisar laejecución y monitorización de la prestación de servicios, así como de los eventosrelacionados con la infraestructura de la organización. En esta labor pueden colaborar,como ya se ha dicho, el Puente de Operaciones o el Centro de Operaciones en Red.

El Control de Operaciones desempeña las siguientes tareas:

• Gestión de Consolas, que define cómo se va a llevar a cabo la observacióncentral y evalúa la capacidad de monitorización. Con este fin, las consolas sonsometidas a ejercicios de monitorización y control de actividades.

• Programación de tareas, que gestiona los trabajos rutinarios o automáticos.


23/35



• Back-up y restauración de archivos en beneficio de los equipos de GestiónTécnica y de Aplicaciones, así como de los usuarios.

• Gestión de Impresión y salidas, para la recopilación y distribución dedocumentos impresos u otros entregables electrónicos.

• Actividades de rendimiento o mantenimiento en beneficio de los equipos deGestión Técnica o de Aplicaciones.

Gestión de Instalaciones

Esta función se ocupa de gestionar el entorno físico de la infraestructura TI: el centrode datos, los cuartos de ordenadores, todo el equipamiento energético y deenfriamiento de los mismos, etc.

La Gestión de Instalaciones también incluye la coordinación de proyectos de

consolidación a gran escala, ya que requieren del despliegue de una infraestructuraindependiente.

En algunos casos, esta función puede subcontratarse, especialmente la gestión delcentro de datos.


El rendimiento de la unidad puede monitorizarse mediante la comprobación periódicade los siguientes indicadores:

• Finalización con éxito de las tareas programadas.• Número de excepciones que se presentaron en las tareas y actividadesprogramadas.• Número de restauraciones del sistema o de datos requeridas.• Estadísticas de instalación de equipo, incluyendo el número de elementos

instalados por tipo, instalaciones exitosas, etc.• Métricas del proceso. La Gestión de Operaciones TI ejecuta muchas

actividades de otros procesos de la gestión de servicios. Su capacidad paradesempeñar este trabajo se cuantificará como parte de las métricas de losotros procesos:

• Tiempo de respuesta a eventos.• Tiempos de resolución de incidentes.• Número de incidentes relacionados con la seguridad.• Número de escalado de incidentes y razones.• Número de cambios implementados y retirados.• Número de cambios no autorizados que se detectaron.• Número de versiones desplegadas de forma total y exitosa.• Rastreo de SIPs.• Gasto por comparación al presupuesto.

• Si se delegaron tareas de mantenimiento, entonces las métricas relacionadascon estas actividades también deben reflejar:

• Rendimiento según planificación.


24/35



• Número de ventanas de mantenimiento superadas.• Objetivos de mantenimiento alcanzados (número y porcentaje).

• Las métricas relacionadas con el Mantenimiento de Instalaciones sonexhaustivas, y suelen incluir:

• Costes vs. presupuesto asociado al mantenimiento, construcción,seguridad, reparto, etc.

• Incidentes relacionados con el edificio (p.ej. Reparaciones).• Informes de acceso a las instalaciones.• Número de eventos e incidentes relacionados con la seguridad y cómo

se resolvieron.• Estadísticas de uso eléctrico, especialmente relacionado con cambios

en la distribución y las estrategias de responsabilidad ambiental.•

Eventos o incidentes relacionados con el reparto y la distribución.

3.3 Gestión Técnica

La Gestión Técnica aporta las habilidades técnicas y los recursos necesarios para darsoporte a la fase de Operación del servicio. La Gestión Técnica también toma parte enel diseño, pruebas, despliegue y mejora de los servicios TI.

El papel de la Gestión Técnica es doble:

• Es la responsable del conocimiento técnico y la experiencia relacionada con la

gestión de la infraestructura TI. Debe asegurarse de que el conocimientorequerido para diseñar, probar, gestionar y mejorar los servicios TI esidentificado, distribuido y perfeccionado.

• Proporciona los recursos reales destinados a dar soporte al ciclo de vida. Así,la Gestión Técnica debe encargarse no sólo de que esos recursos esténdisponibles en la fase de Operación, sino también de que tengan el niveladecuado y de que realmente se estén utilizando.

Para orientar su labor, la Gestión Técnica toma como base los requisitos definidos enla fase de Estrategia del Servicio, desarrollados en el Diseño del Servicio, validadosen la Transición y perfeccionados en la Mejora Continua.El objetivo principal de la Gestión Técnica consiste en ayudar en la planificación,

implementación y mantenimiento de una infraestructura técnica estable para apoyarlos procesos de negocio de la organización mediante:

• Una topología técnica bien diseñada, elástica y económica.• Uso de habilidades técnicas adecuadas para mantener la infraestructura

técnica en condiciones óptimas.• Uso ágil de habilidades técnicas para una diagnosis rápida y resolución de

cualquier error técnico que pueda ocurrir.



25/35



La Gestión Técnica debe procurar que exista un equilibrio entre el nivel de habilidad,la utilización y el coste de los recursos. Se trata de corregir situaciones como, porejemplo, que se contrate un recurso de alto nivel a un coste elevado y que despuéssólo se utilice un 10% de sus capacidades.

Algunas de las estrategias a emplear para equilibrar el gasto en recursos en GestiónTécnica son:

• Identificar cuándo se necesitan determinadas habilidades de alto nivel.• Contratar a terceros sólo en los momentos puntuales en que se necesitan sus

habilidades.• Montar un equipo táctico que, además de sus tareas propias, desempeñe

tareas que requieran habilidades específicas.

3.3.2 Estructura

La estructura de la Gestión Técnica depende de las dimensiones de la organizaciónTI. Si ésta es pequeña, a menudo se centralizan las actividades en un solodepartamento, mientras que en las de mayor tamaño se subdividen en variosdepartamentos especializados técnicamente. El criterio principal es, por lo tanto, laespecialialización: los trabajadores se agrupan de acuerdo a sus habilidades técnicas,que a su vez dependen de la tecnología que hay que gestionar.

Algunos ejemplos de equipos o departamentos de Gestión Técnica:

• Equipo/departamento central.• Equipo/departamento de servidor.• Equipo/departamento de almacenamiento de datos.• Equipo/departamento de soporte de redes.• Equipo/departamento de aplicaciones de escritorio.• Equipo/departamento de base de datos.• Equipo/departamento de software intermedio.• Equipo/departamento del directorio de servicios.• Equipo/departamento de web.• Equipo/departamento de telefonía basada en IP.

3.3.3 Funciones

Las actividades de la Gestión Técnica engloban:

• Identificar el conocimiento y experiencia necesarios para prestar servicios ygestionar la infraestructura TI:

• Documentando las habilidades que posee la organización.• Identificando las necesidades de formación.

• Diseñar y desarrollar (aunque no impartir) programas de formaciónrelacionados con los recursos técnicos:

•

Formación técnica de los usuarios.


26/35



• Formación técnica del Centro de Servicios.• Formación técnica de otros equipos del ciclo de vida.

• La Gestión Técnica a menudo participa en la contratación de:

• Recursos humanos, en caso de que no se puedan desarrollar lashabilidades requeridas (por falta de personal, de nivel mínimo).

• Vendedores, ya que a menudo los miembros del equipo de la GestiónTécnica son los únicos que saben exactamente los conocimientostécnicos que debe tener un comercial y cómo evaluarlos en loscandidatos.

• La Gestión Técnica también se encarga de definir estándares para:

•

Diseñar nuevas arquitecturas, participando además en la definición delas mismas durante las fases de Estrategia y Diseño.• Las herramientas de Gestión de Eventos y respuestas “modelo” a

ciertos tipos de eventos.• Estándares de rendimiento que luego serán utilizados por la Gestión de

la Disponibilidad y la de la Capacidad.

• La Gestión Técnica interviene en el diseño de:

• Nuevos servicios, participando sobre todo en la arquitectura técnica ylas actividades necesarias para gestionar la infraestructura.

• Tests de funcionalidad, rendimiento y manejabilidad de servicios.

• La Gestión Técnica, como guardiana de todo el conocimiento tecnológico de lainfraestructura de la organización TI, lo pone al servicio del resto de laorganización en:

• La Gestión Financiera, identificando el coste de la tecnología y losrecursos humanos que intervienen en la prestación de servicios.

• La Gestión de Problemas, ayudando a diagnosticarlos y resolverlos.También contribuye a validar y mantener el KEDB.

• La Gestión de Incidencias y la de Problemas, ayudando a definir lossistemas de codificación de los mismos.

• La Gestión de Incidencias, ya que a menudo los equipos de la Gestión

Técnica participan como línea de soporte especializado. Tambiéncolaboran en la definición de los casos de escalado.

• La Gestión de Cambios, para evaluar las RFCs, muchas de las cualesson ejecutadas a menudo por la Gestión Técnica.

• Asesoramiento sobre riesgos, identificando dependencias y definiendocontramedidas.

• La Gestión Técnica proporciona información al sistema de Gestión deConfiguraciones, y en colaboración con la Gestión de Aplicaciones seasegura de que se creen los atributos y relaciones correctas entre CIs,tanto en el despliegue como en el mantenimiento del ciclo de vida de losmismos.


27/35



• En la Mejora Continua, ayudando en la tarea de identificaroportunidades de mejora.

• La Gestión Técnica también colabora en la actualización de ladocumentación del sistema, garantizando que la información estáactualizada y es bien conocida por el personal.

• La Gestión Técnica, además, se ocupa de investigar y desarrollar solucionesque ayuden a expandir los servicios, o que simplifiquen los que ya se prestan(reduciendo costes, p.ej.).


La Gestión Técnica puede medirse a través de los siguientes indicadores:

•

Métricas de los entregables acordados. Esto puede incluir:

• Contribución a logros para el negocio.• Porcentajes de transacción y disponibilidad en transacciones de negocio

críticas.• Formación del Centro de Servicios. • Resolución de problemas de grabación en la KEDB.• Mediciones de la calidad de los entregables.• Instalación y configuración de componentes bajo su control.

• Mediciones de procesos. Los equipos de Gestión Técnica se ocupan deejecutar numerosas actividades de otros procesos de la gestión de servicios,

como por ejemplo:

• Tiempos de respuesta medios a eventos y porcentajes de completadode eventos.

• Tiempos de resolución de incidentes en segunda y tercera líneas desoporte.

• Estadísticas de resolución de problemas.• Número de incidentes escalados y razones para esos escalados.• Número de cambios implementados y retirados.• Número de cambios no autorizados detectados.

• Rendimiento de la tecnología.• Tiempo promedio entre incidencias de determinado equipamiento.• Medición de las actividades de mantenimiento.• Formación y desarrollo de habilidades.

3.4 Gestión de Aplicaciones

La Gestión de Aplicaciones es responsable del soporte y mantenimiento de lasaplicaciones que toman parte en la Operación del servicio. Al igual que ocurría con laGestión Técnica en relación a la infraestructura TI, la Gestión de Aplicaciones tambiéndesempeña un doble papel:

http://localhost/var/www/apps/conversion/tmp/itil.osiatis.es/ITILV3/itilv3.osiatis.es/operacion_servicios_TI/centro_servicios.htmlhttp://localhost/var/www/apps/conversion/tmp/itil.osiatis.es/ITILV3/itilv3.osiatis.es/operacion_servicios_TI/centro_servicios.html


28/35



• Es la responsable del conocimiento técnico y la experiencia relacionada con lasaplicaciones. Debe asegurarse de que el conocimiento requerido para diseñar,probar, gestionar y mejorar los servicios TI es identificado, distribuido yperfeccionado.

• Proporciona los recursos reales destinados a dar soporte al ciclo de vida. Así,la Gestión de Aplicaciones debe encargarse no sólo de que esos recursosestén disponibles en la fase de Operación, sino también de que tengan el niveladecuado y de que realmente se estén utilizando.

La Gestión de Aplicaciones participa, además, en las siguientes actividades del ciclode vida:

• Diseño, prueba y mejora de las aplicaciones.• La decisión de desarrollar una aplicación o comprársela a un tercero.•

Integrar la Gestión de Aplicaciones en el Ciclo de Vida.La Gestión de Aplicaciones tiene como principal objetivo identificar los requisitosfuncionales del software de aplicaciones, prestar apoyo en el diseño y desarrollo dedichas aplicaciones y colaborar en el soporte y mejora que siguen a su despliegue.

Para lograr este fin, se precisa:

• Aplicaciones bien diseñadas, elásticas y que optimicen costes.• Garantizar que la funcionalidad requerida está disponible para alcanzar los

resultados de negocio deseados.• Organizar las habilidades técnicas adecuadas para mantener aplicaciones

operacionales en condiciones óptimas.• Uso ligero de habilidades técnicas para una diagnosis rápida y la resolución de

cualquier fallo técnico que pueda presentarse.

La Gestión de Aplicaciones se encarga de que exista un equilibrio entre el nivel de losrecursos y su coste.


Es habitual en las organizaciones TI dividir la Gestión de Aplicaciones endepartamentos según el catálogo de aplicaciones. Esto permite una mayorespecialización y un soporte más centrado.

A pesar de que todos los equipos, departamentos o grupos de Gestión de Aplicacionesdesempeñan actividades similares, cada aplicación o conjunto de aplicaciones precisaun conjunto específico de requisitos de gestión y operación, en función de:

• El propósito de la aplicación. Los equipos deben tener en cuenta los objetivosde negocio.

• La funcionalidad de la aplicación.• La plataforma en la que corre la aplicación.• El tipo/marca de tecnología empleada.


29/35



3.4.2 Estructura

Los equipos y departamentos de Gestión de Aplicaciones suelen organizarse segúnlas distintas categorías de aplicaciones a las que dan soporte. Algunos ejemplostípicos son:

• Aplicaciones financieras.• Aplicaciones de mensajería y colaboración.• Aplicaciones de RRHH.• Aplicaciones de soporte industrial.• Aplicaciones de automatización de fuerza de ventas (CRM).• Aplicaciones de procesamiento de ventas.• Aplicaciones del centro de llamadas y marketing.• Aplicaciones específicas del negocio (sanidad, seguros, banca, etc.)•

Aplicaciones TI, como Centro de Servicios, Sistemas de Gestión de laEmpresa (, ), etc.• Portales web.• Tienda online.

3.4.3 Funciones

Mientras la mayoría de equipos/departamentos de Gestión de Aplicaciones sededican a aplicaciones específicas o conjuntos de ellas, existen ciertas actividadescomunes:

• Ayudar a la Gestión Técnica en la tarea de identificar el conocimiento y

experiencia necesarios para gestionar las aplicaciones a la hora de prestarservicios TI.

• Diseñar y desarrollar (aunque no impartir) programas de formación destinadosal usuario final. Aunque otros equipos o incluso terceros pueden ser quienes laimpartan finalmente, la Gestión de Aplicaciones es responsable de que éstasea adecuada.

• La Gestión de Aplicaciones también interviene en labores de contratación:

• En caso de que ciertas habilidades no se puedan desarrollar a nivelinterno (por falta de personal o de nivel), la Gestión de Aplicaciones esla encargada de seleccionar y contratar los recursos adecuados.

• Vendedores, ya que a menudo los miembros del equipo de la Gestiónde Aplicaciones son los únicos que saben exactamente losconocimientos técnicos que debe tener un comercial y cómo evaluarlosen los candidatos.

• La Gestión de Aplicaciones también se encarga de definir estándares para:

• Diseñar nuevas arquitecturas, participando además en la definición delas mismas durante las fases de Estrategia y Diseño.

• Las herramientas de Gestión de Eventos y respuestas “modelo” aciertos tipos de eventos.

• Estándares de rendimiento que luego serán utilizados por la Gestión de

la Disponibilidad y la de la Capacidad.


30/35



• La Gestión de Aplicaciones interviene en el diseño de:

• Nuevos servicios, contribuyendo a la definición de la arquitecturatécnica y rendimiento estándar, así como en la adecuación a los nivelesde servicio preestablecidos. Además, la Gestión de Aplicaciones esresponsable de especificar las actividades necesarias para mantenerdichas aplicaciones.

• Tests de funcionalidad, rendimiento y manejabilidad de servicios.

• La Gestión de Aplicaciones, como guardiana del conocimiento relacionado conlas aplicaciones, lo pone al servicio del resto de la organización en:

• La Gestión Financiera, identificando el coste de las aplicaciones queintervienen en la prestación de servicios.

• La Gestión de Problemas, ayudando a diagnosticar y resolver aquellosque guardan relación con las aplicaciones.

• La Gestión de Incidencias y la de Problemas, ayudando a definir lossistemas de codificación de los mismos.

• La Gestión de Incidencias, ya que a menudo los equipos de la GestiónTécnica participan como línea de soporte especializado. Tambiéncolaboran en la definición de los casos de escalado.

• La Gestión de Cambios, para evaluar las RFCs, muchas de las cualesson ejecutadas a menudo por la Gestión de Aplicaciones.

• Asesoramiento sobre riesgos, identificando dependencias y definiendocontramedidas.

• La Gestión de Aplicaciones es, a menudo, quien dirige el despliegue de

las nuevas versiones durante la fase de Transición.• La Gestión de Aplicaciones proporciona información al sistema de

Gestión de Configuraciones, y en colaboración con la Gestión Técnicase asegura de que se creen los atributos y relaciones correctas entreCIs, tanto en el despliegue como en el mantenimiento del ciclo de vidade los mismos.

• En la Mejora Continua, ayudando en la tarea de identificaroportunidades de mejora.

• Colaborar en la actualización de la documentación del sistema,garantizando que la información está actualizada y es bien conocida porel personal.

• Participar en las actividades operacionales que se llevan a cabo como

parte de la Gestión de Operaciones.• La Gestión de Aplicaciones también contribuye a mantener actualizadas

las políticas de configuración de software.

• Investigación y desarrollo de soluciones que ayuden a expandir el Portfolio deServicios o al menos a mejorar la prestación de los mismos.

• Proporcionar asesoramiento en riesgos, identificando servicios críticos ydependencias de sistema y definiendo e implementando contramedidas.



31/35



Las métricas que reflejan el rendimiento de la Gestión de Aplicaciones dependen delas aplicaciones que se estén gestionando, pero las más típicas son:

• Métricas de los entregables acordados. Esto puede incluir:

• Capacidad de los usuarios para acceder a la aplicación y susfuncionalidades.

• Reportes y archivos enviados a los usuarios.• Porcentajes de éxito y disponibilidad para determinadas transacciones

críticas para el negocio.• Formación del Centro de Servicios. • Registro de resolución de problemas en el sistema de Gestión del

Conocimiento.• Percepción que los usuarios tienen de la calidad, en comparación con

los requisitos definidos en los SLAs.• Métricas de procesos:

• Tiempo de respuesta a eventos y porcentajes de finalización.• Tiempos de resolución de incidentes en la segunda y tercera líneas de

soporte.• Estadísticas de resolución de problemas.• Número de incidencias escaladas y razones que motivaron su escalado• Número de cambios implementados y revertidos.• Número de cambios no autorizados que se detectaron.• Número de versiones desplegadas (total y exitosas)•

Problemas de seguridad detectados y resueltos.• Utilización real del sistema comparada con las previsiones del Plan de

Capacidad.• Seguimiento de sesiones.• Gasto en comparación con el presupuesto.

• Rendimiento de aplicaciones. Estas métricas se basan en las especificacionesde la fase de Diseño y el rendimiento técnico contenido en los OLAs. Suelenincluir:

• Tiempos de respuesta.• Disponibilidad de la aplicación.• Integridad de los datos e informes.

• Métricas de las actividades de mantenimiento:

• Mantenimiento llevado a cabo según la planificación.• Número de ventanas de mantenimiento que se prolongaron.• Objetivos de mantenimiento alcanzados (número y porcentaje).

• Probabilidad de la colaboración entre los equipos de Gestión de Aplicaciones ylos equipos de Desarrollo de Aplicaciones en proyectos. Métricas de:

• Tiempo invertido en proyectos.

http://localhost/var/www/apps/conversion/tmp/itil.osiatis.es/ITILV3/itilv3.osiatis.es/operacion_servicios_TI/centro_servicios.htmlhttp://localhost/var/www/apps/conversion/tmp/itil.osiatis.es/ITILV3/itilv3.osiatis.es/operacion_servicios_TI/centro_servicios.html


32/35



• Satisfacción del cliente y el usuario con el entregable del proyecto.• Costes de involucrarse en el proyecto.

• Formación y desarrollo de habilidades. Estas métricas garantizan que laplantilla tiene las habilidades y formación necesarias para gestionar latecnología de la que son responsables, además de identificar áreas en las quese requiere formación adicional.

4 Puesta en marcha

Uno de las principales dificultades para la correcta puesta en marcha de la fase deOperación del Servicio reside en el “abismo” existente entre teoría y práctica.

Las fases previas del ciclo de vida de los servicios se han preocupado de diseñar,planificar y desplegar una serie de procesos y servicios que ahora han de ponerse enmarcha y es frecuente eso conlleve las habituales dificultades:

• Los responsables del diseño no conocen en detalle las complicacionesasociadas a las labores de mantenimiento y tareas recurrentes de la fase deoperación con las consiguientes consecuencias indeseables:

• Se toman “atajos” que rompen con las buenas prácticas de gestión. • Se crean resistencias a la aplicación de los protocolos diseñados.

• No se han asignado los recursos necesarios para implementar correctamente

la fase de operación y el personal la percibe como una nueva capa“burocrática” que sólo dificulta su trabajo.

• Las estructuras de gestión no son lo suficientemente flexibles y por tanto noson capaces de asimilar la complejidad de los nuevos procesos y actividades.

• Las métricas def inidas se centran en exceso en aspectos “internos” de laorganización TI y obvian importantes aspectos “externos” relativos a lapercepción de los clientes.

Para impedir que todo esto ocurra es imprescindible:

• Involucrar al personal de operación en el diseño de los servicios.• Asegurarse una rápida evaluación del impacto de todos los cambios en la fase

de operación.• Que el personal a cargo de la fase de operación disponga desde el primer

momento de todas las herramientas y tecnología necesarias para desempeñarcorrectamente su función según los protocolos preestablecidos.

4.1 Monitorización y Control

La monitorización consiste en la observación atenta de una determinada situacióncon el fin de detectar cambios a lo largo del tiempo. En el contexto de la fase deOperación del servicio, la monitorización implica:


33/35



• Monitorizar los CIs y actividades clave.• Asegurarse de que se cumplen las condiciones establecidas y, en caso

contrario, advertir al grupo adecuado.• Asegurar que el rendimiento y utilización de los componentes, sistemas, etc.

están dentro de un rango previsto.• Detectar niveles anormales de actividad en la infraestructura.• Detectar cambios no autorizados.• Asegurar el cumplimiento de las políticas de la empresa.• Rastrear las salidas al negocio y garantizar que casan con los requisitos de

calidad y rendimiento acordados.• Rastrear cualquier información empleada para medir los KPIs.

El modelo más extendido para definir el control es el Ciclo de Monitorización-Control. Este ciclo puede ser de dos tipos:

• Ciclo Abierto: se programan actividades específicas sin tener en cuenta lascondiciones del entorno. Un backup periódico, que se lanza con independenciade las circunstancias, es un buen ejemplo de control de ciclo abierto.

• Ciclo Cerrado: se monitoriza un entorno con el fin de responder sólo a loscambios que se produzcan. Un ejemplo de esto sería un balance de carga deuna red, en el que se ejercen tareas de control sólo si la monitorización indicaque se está sobrepasando el tráfico normal.

La monitorización tiene dos niveles de actuación:

• Monitorización y control interno, cuando desde un equipo o departamento se

controlan los elementos y actividades de esa misma unidad.• Monitorización y control exernos, cuando un equipo o departamento realiza

el control de elementos y actividades que dependen de otros grupos, procesoso funciones.

Podemos distinguir distintos tipos de monitorización según tres factores:

• Monitorización activa vs. pasiva. La monitorización activa consiste en haceruna comprobación directa del estado de un sistema o dispositivo. La pasiva, encambio, genera y transmite eventos a un agente de monitorización de formaautomática. La pasiva es más frecuente, reservándose la activa para ladiagnosis.

• Monitorización reactiva vs. preactiva. La primera está diseñada para ejecutaracciones al producirse cierto tipo de eventos o fallos. La monitorizaciónproactiva, por otro lado, se utiliza para detectar los patrones de eventos quepredicen el fallo de un dispositivo.

• Medición continuada vs. basada en excepciones. La medición continuaenfoca la monitorización como un registro del rendimiento en tiempo real,mientras que la medición basada en excepciones se limita a notificar lasinterrupciones.

4.2 Factores de éxito y riesgos


34/35



Entre los factores de éxito y retos a los que se debe confrontar la correctaimplementación de la Fase de Operación del Servicio se encuentran:

• Disponer de personal convenientemente formado sobre los procesos yactividades necesarias para una correcta gestión del servicio.

• Contar con el adecuado soporte tecnológico que facilite y automatice, cuandoesto sea posible, las actividades asociadas a la prestación y gestión delservicio.

• Contar con el apoyo necesario de los órganos de dirección de la organizaciónTI para disponer de los recursos y capacidades necesarias.

• Disponer de las métricas adecuadas para evaluar la calidad de la operación delservicio.

• Generar los informes y documentación necesarios para la futura mejora delservicio.

•

Trabajar en estrecha colaboración con las unidades de negocio para conocersus necesidades y garantizar que estas son cubiertas.

Los principales riesgos se resumen en:

• Diseños defectuosos del servicio que impiden una operación eficiente.• Recursos y capacidades insuficientes.• Falta de soporte de la organización TI.

5 Glosario

CI Elemento de configuración

CMDB Base de datos de la gestión de configuraciones

CMS Sistema de gestión de la configuración

CRM

FAQ Preguntas frecuentes

KB Base de conocimiento

KEDB Base de datos de errores conocidos

KPI Indicadores críticos de rendimiento

OLA Acuerdo de nivel de operaciónPIR Revisión post-implantación

RFC Petición de cambio

SKMS Sistema de gestión del conocimiento del servicio

SLA Acuerdo de nivel de servicio

6 Referencias

En la elaboración de éste resumen se han utilizado las siguientes fuentes:


35/35


• http://itilv3.osiatis.es• ITIL V3 Fundamentos
http://itilv3.osiatis.es/http://books.google.es/books?id=QHYs9yWDRsQC&pg=PA28&lpg=PA28&dq=tipo+I+tipo+II+tipo+III+proveedores+servicio+itil&source=bl&ots=z6LsXiHQLZ&sig=rGkNwrdUgS3xLFfcCnpTjW8aNq0&hl=es&sa=X&ei=HovdUayEKoi3hQequYGYBA&ved=0CDkQ6AEwAQ#v=onepage&q=tipo%20I%20tipo%20II%20tipo%20III%20proveedores%20servicio%20itil&f=falsehttp://books.google.es/books?id=QHYs9yWDRsQC&pg=PA28&lpg=PA28&dq=tipo+I+tipo+II+tipo+III+proveedores+servicio+itil&source=bl&ots=z6LsXiHQLZ&sig=rGkNwrdUgS3xLFfcCnpTjW8aNq0&hl=es&sa=X&ei=HovdUayEKoi3hQequYGYBA&ved=0CDkQ6AEwAQ#v=onepage&q=tipo%20I%20tipo%20II%20tipo%20III%20proveedores%20servicio%20itil&f=falsehttp://itilv3.osiatis.es/

4. Operacion de Los Servicios TI ITIL

Documents

Transcript of 4. Operacion de Los Servicios TI ITIL