ITIL: FASE OPERACIÓN DEL SERVICIO (SEGUNDA PARTE)

5. Gestión de Acceso

El objetivo de la Gestión de Acceso a los Servicios TI es otorgar permisos de acceso a los servicios a aquellos usuarios autorizados e impedírselo a los usuarios no autorizados.

En una palabra, es la puesta en práctica de las políticas y acciones definidas en la Gestión de la Seguridad y la Gestión de la Disponibilidad.

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

  • Petición de acceso, que puede llegar por distintas vías como el departamento de RRHH, una solicitud de cambio, una instrucción autorizada…
  • Verificación. Se comprueba la identidad del usuario que solicita el acceso, así como de aquellos que lo autorizan. También se examina si los motivos para otorgar el acceso son pertinentes.
  • Monitorización de identidad. Los cambios en la asignación de permisos suelen estar asociados a un cambio de estatus dentro de la organización: ascensos, despidos, jubilaciones…
  • Registro y monitorización de accesos. La Gestión de Accesos es responsable de asegurar que los permisos que ha otorgado se están usando apropiadamente.
  • Eliminación y restricción de derechos. En algunos casos, los derechos pueden ser eliminados por completo: fallecimiento, dimisión, despido, traslados…

Control del proceso

La eficacia del proceso de Gestión de Acceso a los Servicios TI puede controlarse mediante los siguientes indicadores:

  • Número de peticiones de acceso.
  • Instancias de acceso garantizado, por servicio, usuario, departamento, etc.
  • Instancias de acceso garantizado por derechos de acceso de departamento o individuo.
  • Número de incidentes que requirieron la revocación de los permisos de acceso.
  • Número de incidentes causados por una configuración incorrecta de los accesos.

6. FUNCIONES

Las funciones involucradas en la fase de Operación del servicio son las responsables de que los servicios cumplan los objetivos solicitados por los clientes y de gestionar toda la tecnología necesaria para la prestación de dichos servicios:

  • Centro de Servicios: responsable de todos los procesos de interacción con los usuarios de los servicios TI.
  • Gestión de Operaciones TI: responsable de la operación diaria del servicio.
  • Gestión Técnica: es una unidad funcional que incluye a todos los equipos, grupos y departamentos involucrados en la gestión y soporte de la infraestructura TI.
  • Gestión de Aplicaciones: esta unidad funcional es la responsable de la gestión del ciclo de vida de la aplicaciones TI

Centro de Servicios

  • Call Center: Su objetivo es gestionar un alto volumen de llamadas y redirigir a los usuarios, excepto en los casos más triviales, a otras instancias de soporte y/o comerciales.
  • Centro de Soporte (HelpDesk): Su principal objetivo es ofrecer una primera línea de soporte técnico que permita resolver en el menor tiempo las interrupciones del servicio.
  • Centro de Servicios (ServiceDesk): representa la interfaz para clientes y usuarios de todos los servicios TI ofrecidos por la organización, con un enfoque centrado en los procesos de negocio. Aparte de ofrecer los servicios citados anteriormente, ofrece servicios adicionales a clientes, usuarios y la propia organización TI tales como:
    • Supervisión de los contratos de mantenimiento y niveles de servicio.
    • Canalización de las Peticiones de Servicio de los clientes.
    • Gestión de las licencias de software.
    • Centralización de todos los procesos asociados a la Gestión TI.

La implementación de un Centro de Servicios requiere una meticulosa planificación. En primera instancia deben establecerse los siguientes puntos:

  • Cuáles son las necesidades.
  • 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.

Gestión de Operaciones

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

  • Mantenimiento del status quo de los procesos y actividades de la organización para alcanzar estabilidad en el día a día.
  • Escrutinio regular y mejoras para alcanzar un servicio mejorado con costes reducidos, manteniendo la estabilidad.
  • Aplicación rápida de habilidades operacionales para diagnosticar y resolver cualquier fallo que ocurra en las operaciones

Implementación

  • Comprender en profundidad cómo se emplea la tecnología para prestar servicios.
  • Comprender la importancia relativa y el impacto de esos servicios en el negocio.
  • Los procedimientos y manuales que delimitan los roles operacionales tanto en la gestión de la tecnología como en la prestación de servicios.
  • Disponer de un conjunto de métricas claramente diferenciadas que informen sobre la culminación de objetivos de servicio, y mantengan informados a los gestores TI sobre la eficiencia y efectividad de las Operaciones TI.
  • Los equipos de operaciones TI deben comprender exactamente cómo afecta el rendimiento de la tecnología a la prestación de servicios.
  • Una estrategia de gasto orientada a equilibrar los requisitos de las distintas unidades de negocio con los ahorros disponibles gracias a la optimización de la tecnología existente o la inversión en nueva tecnología.
  • Una estrategia de inversión basada en retorno del valor, más que retorno del gasto

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

  • Control de Operaciones, cuya plantilla generalmente se organiza en turnos de operadores encargados de asegurar que las tareas rutinarias se llevan a cabo. El Control de Operaciones también desempeña tareas de monitorización y control, para lo que a menudo recurre a unidades específicas como el Puente de Operaciones o un Centro de Operaciones en Red.
  • Gestión de Instalaciones, encargada de supervisar el mantenimiento de todo el equipamiento físico. A menudo está ubicada junto a la Gestión Técnica y de Aplicaciones en grandes centros de datos

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ón central y evalúa la capacidad de monitorización. Con este fin, las consolas son sometidas a ejercicios de monitorización y control de actividades.
  • Programación de tareas, que gestiona los trabajos rutinarios o automáticos.
  • Back-up y restauración de archivos en beneficio de los equipos de Gestión Técnica y de Aplicaciones, así como de los usuarios.
  • Gestión de Impresión y salidas, para la recopilación y distribución de documentos impresos u otros entregables electrónicos.
  • Actividades de rendimiento o mantenimiento en beneficio de los equipos de Gestión Técnica o de Aplicaciones

Gestión Técnica

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 apoyar los 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

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

  • Identificar el conocimiento y experiencia necesarios para prestar servicios y gestionar 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ón relacionados con los recursos técnicos.
  • Formación técnica de los usuarios.
  • Formación técnica del Centro de Servicios
  • Formación técnica de otros equipos del ciclo de vida.

Las actividades de la Gestión Técnica engloban

  • La Gestión Técnica a menudo participa en la contratación de:
  • Recursos humanos, en caso de que no se puedan desarrollar las habilidades requeridas (por falta de personal, de nivel mínimo).
  • Vendedores, ya que a menudo los miembros del equipo de la Gestión Técnica son los únicos que saben exactamente los conocimientos técnicos que debe tener un comercial y cómo evaluarlos en los candidatos.
  • 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 de las 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 puede medirse a través de los siguientes indicadores:

  • Métricas de los entregables acordados.
  • Mediciones de procesos.
  • 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

Gestión Aplicaciones

La Gestión de Aplicaciones tiene como principal objetivo identificar los requisitos funcionales del software de aplicaciones, prestar apoyo en el diseño y desarrollo de dichas 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

Estructura

Un ejemplo típico es:

  • 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 la Empresa (SKMS, CMS), etc.
  • Portales web.
  • Tienda online

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

  • Capacidad de los usuarios para acceder a la aplicación y sus funcionalidades.
  • 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 especificaciones de la fase de Diseño y el rendimiento técnico contenido en los OLAs. Suelen incluir:
  • 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 y los equipos de Desarrollo de Aplicaciones en proyectos. Métricas de:
  • Tiempo invertido en proyectos.
  • 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 la plantilla tiene las habilidades y formación necesarias para gestionar la tecnología de la que son responsables, además de identificar áreas en las que se requiere formación adicional

ITIL: Fase Operación del Servicio (Primera Parte)

Los principales objetivos de la fase de Operación del Servicio incluyen:

  • Coordinar e implementar todos los procesos, actividades y funciones necesarias para la prestación de los servicios acordados con los niveles de calidad aprobados.
  • Dar soporte a todos los usuarios del servicio.
  • Gestionar la infraestructura tecnológica necesaria para la prestación del servicio

Los principales procesos asociados directamente a la Fase de Operación del Servicio son:

  • Gestión de Eventos
  • Gestión de Incidencias
  • Petición de Servicios TI
  • Gestión de Problemas
  • Gestión de Acceso a los Servicios TI
  1. Gestión de Eventos

El principal objetivo de la Gestión de Eventos, en su función de monitorizar todos los sucesos importantes, consiste en detectar y escalar condiciones de excepción para así contribuir a una operación normal del servicio:

  • Proporcionando puntos de entrada para varios procesos de la fase de Operación (p. ej. Gestión de Incidencias).
  • Posibilitando la comparación entre el rendimiento real del servicio con los estándares de diseño y los SLAs.
  • Contribuyendo a la Mejora Continua del Servicio mediante informes de mejora

Las actividades de la Gestión de Eventos son:

  • Aparición de eventos. El proceso se inicia cuando ocurre el suceso, ya sea detectado o no.
  • Notificación de eventos. El evento es notificado al equipo o responsable de gestión.
  • Detección y filtrado de eventos. La notificación llega a un agente o herramienta de gestión que la lee e interpreta el suceso con el fin de determinar si merece mayor atención o no.
  • Clasificación de eventos. Se le asigna una categoría y un nivel de prioridad.
  • Correlación. Se analiza si existen eventos similares, así como la importancia del evento en sí mismo y se decide si es necesario tomar medidas.
  • Disparadores. Se ponen en marcha los mecanismos necesarios para dar respuesta al evento.
  • Opciones de respuesta. Se eligen las soluciones a adoptar.
  • Revisión de acciones y cierre. Se revisan las excepciones o eventos importantes para determinar si se han tratado correctamente. Se cierra el proceso de Gestión de Eventos

A la hora de evaluar la eficiencia y efectividad del proceso de Gestión de Eventos deben verificarse los siguientes indicadores:

  • Número de eventos, por categorías.
  • Número de eventos, por importancia.
  • Número y porcentaje de eventos que requirieron de intervención humana y cómo fue esa intervención.
  • Número y porcentaje de eventos que desembocaron en el registro de una nueva incidencia o solicitud de cambio.
  • Número y porcentaje de eventos ocasionados por problemas ya existentes o errores conocidos.
  • Número y porcentaje de eventos repetidos o duplicados. Esto es relevante para optimizar la función de Correlación.
  • Número y porcentaje de eventos relacionados con problemas de rendimiento.
  • Número y porcentaje de eventos que indican futuros problemas de disponibilidad.
  • Número y porcentaje de cada tipo de evento, por plataforma o aplicación.
  • Número y ratio de eventos por comparación al número de incidentes.

2. Gestión de Incidencias

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

La Gestión de Incidencias 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.

Procesos dentro de Gestión de Incidencias:

  • Registro y Clasificación
  • Clasificación
  • Análisis y Asignación
  • Cierre

La correcta elaboración de informes forma parte esencial en el proceso de Gestión de Incidencias. Considere los siguientes aspectos:

  • La Gestión de Niveles de Servicio: es esencial que los clientes dispongan de información puntual sobre los niveles de cumplimiento de los SLAs y que se adopten medidas correctivas en caso de incumplimiento.
  • Monitorizar el rendimiento del Centro de Servicios: conocer el grado de satisfacción del cliente por el servicio prestado y supervisar el correcto funcionamiento de la primera línea de soporte y atención al cliente.
  • Optimizar la asignación de recursos: los gestores deben conocer si el proceso de escalado ha sido fiel a los protocolos preestablecidos y si se han evitado duplicidades en el proceso de gestión.
  • Identificar errores: puede ocurrir que los protocolos especificados no se adecuen a la estructura de la organización o las necesidades del cliente, por lo que se deberán tomar medidas correctivas.
  • Disponer de Información Estadística: que puede ser utilizada para hacer proyecciones futuras sobre asignación de recursos, costes asociados al servicio, etc.

3. Gestión de Peticiones

  • Proporcionar un canal de comunicación a través del cual los usuarios puedan solicitar y recibir servicios estándar para los que existe una aprobación previa.
  • Proporcionar información a los usuarios y clientes sobre la disponibilidad de los servicios y el procedimiento para obtenerlos.
  • Localizar y distribuir los componentes de servicios estándar solicitados.
  • Ayudar a resolver quejas o comentarios ofreciendo información general.

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

  • Selección de peticiones. Los usuarios, a través de las herramientas destinadas a tal fin por la Gestión de Peticiones, emiten sus peticiones conforme a una serie de tipologías predefinidas.
  • Aprobación financiera de la petición. Dado que la mayoría de peticiones tienen implicaciones financieras, se considera su coste y se decide si tramitar la petición o no.
  • Tramitación. La petición es cursada por la persona o personas adecuadas según cada caso.
  • Cierre. Tras notificar al Centro de Servicios y comprobar desde aquél que el usuario ha quedado conforme con la gestión se procede a cerrarla.

Control del proceso

  • Número total de peticiones de servicio.
  • Ruptura de peticiones de servicio en cada etapa.
  • Tamaño de la copia de seguridad de las peticiones más destacadas.
  • Tiempo medio que dura la gestión de cada tipo de petición de servicio.
  • Número y porcentaje de peticiones de servicio completadas en los tiempos acordados.
  • Coste medio de cada tipo de petición de servicio.
  • Nivel de satisfacción del cliente con la gestión de las peticiones de servicio

4. Gestión de Problemas

Cuando algún tipo de incidente se convierte en recurrente o tiene un fuerte impacto en la infraestructura TI, es la función de la Gestión de Problemas el determinar sus causas y encontrar posibles soluciones.

Cabe diferenciar entre:

Problema: causa subyacente, aún no identificada, de una serie de incidentes o un incidente aislado de importancia significativa.

Error conocido: Un problema se transforma en un error conocido cuando se han determinado sus causas

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

  • Control de Problemas: se encarga de registrar y clasificar los problemas para determinar sus causas y convertirlos en errores conocidos.
  • Control de Errores: registra los errores conocidos y propone soluciones a los mismos mediante RFCs que son enviadas a la Gestión de Cambios. Asimismo efectúa la Revisión Post Implementación de los mismos en estrecha colaboración con la Gestión de Cambios.

Entre la documentación generada cabría destacar:

  • Informes de Rendimiento de la Gestión de Problemas: donde se detalle el número de errores resueltos, la eficacia de las soluciones propuestas, los tiempos de respuesta y el impacto en la Gestión de Incidencias
  • Informes de Gestión Proactiva: donde se especifiquen las acciones ejercidas para la prevención de nuevos problemas y los resultados de los análisis realizados sobre la adecuación de las estructuras TI a las necesidades de la empresa.
  • Informes de Calidad de Productos y Servicios: donde se evalúe el impacto en la calidad del servicio de los productos y servicios contratados y que eventualmente pueda permitir adoptar decisiones informadas sobre cambios de proveedores, etc.

ITIL Diseño del Servicio (segunda parte)

Gestión del Riesgo

Identificar, evaluar y controlar riesgos. Esto incluye el análisis del valor de los activos de la empresa, la identificación de amenazas a dichos activos y la evaluación de su vulnerabilidad ante esas amenazas.

Términos ITIL para Gestión del Riesgo

Análisis del Impacto y Riesgo al Negocio: El Análisis de Impacto Empresarial (Business Impact Analysis, BIA) identifica las Funciones Empresariales Vitales (Vital Business Functions, VBF) y sus dependencias. Estas dependencias pueden incluir Proveedores, individuos, otros procesos de negocio, servicios, etc. El Análisis del Riesgo identifica las amenazas y vulnerabilidades de los activos de la empresa e indica el nivel de vulnerabilidad de cada activo ante determinadas amenazas.

Valoración de Procesos y Activos: Es el estimado del valor que un proceso u otro activo representa para la empresa. Este valor es importante para el Análisis del Riesgo.

Registro de Riesgos: Es una herramienta usada en el proceso de Gestión del Riesgo para tener una idea general de ciertos riesgos y sus respectivas contramedidas.

Subproceso_riesgo

Gestión de la Capacidad

Sistema de Información de Gestión de la Capacidad (CMIS) es un depósito virtual de todos los datos de Gestión de la Capacidad, usualmente almacenados en varias localidades físicas.

Plan de Capacidad Se usa para gestionar los recursos requeridos para prestar los servicios de TI requeridos. Contiene escenarios de posibilidades según distintas predicciones de demanda de servicios, así como opciones y sus costos para cumplir con los niveles de servicio acordados.

Informe de la Capacidad Provee información relacionada con factores de uso y desempeño a otros procesos de Gestión de Servicios y la dirección de TI.

Sugerencia para Influir en la Demanda de Servicios Se trata de una sugerencia para influir en la demanda de capacidad de servicios. Usualmente la propone el Gestor de la Capacidad y se lleva a cabo durante la revisión del servicio.

Gestion_capacidad

Gestión de la Disponibilidad

Gestion_Disponibilidad1

Gestion_Disponibilidad2

Gestion_continuidad

Gestion_continuidad2

Gestión de la Seguridad de la Información

Gestion_seguridad.png

Gestion_seguridad2

Términos ITIL para Gestión de la Seguridad

Política de Seguridad de TI Establece reglas vinculantes para el uso de servicios y de sistemas con miras a mejorar la seguridad de TI.

Informe de Seguridad de TI  Provee información sobre asuntos de Seguridad de TI a los procesos de Gestión de Servicios y la dirección de TI.

Estrategia de Seguridad de TI  Contiene una guía de acercamiento para procurar la seguridad de los sistemas y servicios de TI. Incluye una lista de riesgos de seguridad y de Controles de Seguridad existentes o planificados para el manejo de riesgos.

Advertencias de Seguridad Es una lista de vulnerabilidades de seguridad conocidas y compiladas gracias a la aportación de proveedores de productos externos. La lista contiene instrucciones para medidas preventivas y para el manejo de infracciones de seguridad una vez ocurran

Alerta de Seguridad Se trata de una advertencia producida por la Gestión de la Seguridad de TI que generalmente se hace pública cuando se prevé el surgimiento de infracciones de seguridad o cuando ya están ocurriendo. Se busca asegurar que los usuarios y el personal de TI sean capaces de identificar cualquier ataque y de tomar medidas de precaución.

Sistema de Información de Gestión de la Seguridad (SMIS) Es un depósito virtual de todos los datos de Gestión de la Seguridad de TI, generalmente almacenados en varias localidades físicas.

Gestión de Proveedores (Suministradores)

Gestion_Proveedores1.png

Gestion_Proveedores2.png

Términos ITIL para Gestión de Proveedores

Orden de Compra Es una orden para comprarle artículos a algún suministrador. Si se trata de un pedido para un Servicio de Soporte cuyas provisiones son de origen externo, la orden de compra debe estar acompañada de un Contrato de Apoyo (UC) en el que se definan los niveles de servicio propuestos.

Requisición de Compra Es un pedido para la compra de un producto o de un servicio a un suministrador externo. Puede ser emitido, por ejemplo, por Gestión de Ediciones durante la Construcción de Servicios. El procesamiento de una Requisición de Compra por lo general se lleva a cabo sólo si el solicitante cuenta con una partida presupuestaria aprobada para la compra.

Modificaciones Requeridas a los Contratos de Apoyo Es un pedido generado en algún proceso de Gestión de Servicios para hacer cambios a un Contrato de Apoyo (UC). Esta requisición casi siempre es enviada de la Gestión de Nivel de Servicio a la Gestión de Proveedores si se requiere un servicio nuevo o la modificación de Servicios de Soporte externos.

Términos y Condiciones Estándar Generalmente, este conjunto de términos y condiciones va unido a contratos y pedidos cuando se solicitan servicios o productos nuevos.

Base de Datos de Proveedores y Contratos (SCD) Es una base de datos o documento estructurado que se usa para gestionar contratos a proveedores a lo largo de su ciclo de vida. La Base de Datos de Proveedores y Contratos (Supplier and Contract Database, SCD) contiene atributos clave de todos los contratos y Proveedores, por lo que debe formar parte del Sistema de Gestión del Conocimiento en Servicios (SKMS).

Revisión de Proveedores y Contratos La revisión de Revisión de Proveedores y Contratos evalúa el rendimiento logrado vs. acordado por parte de los proveedores. También contiene deficiencias o problemas identificados en el suministrador, así como sugerencias para mejorar la situación.

Evaluación a Proveedores El documento resultante de la Evaluación a Proveedores describe detalladamente los criterios usados para la evaluación y selección de un proveedor adecuado.

Estrategia de Proveedores Establece guías para la obtención de bienes y servicios. Incluye criterios de selección de Proveedores adecuados y una lista de Proveedores preferidos.

Contrato de Apoyo (UC) Es un contrato entre el proveedor de servicios de TI y un tercero. El tercero brinda apoyo en los servicios ofrecidos a clientes. El Contrato de Apoyo (Underpinning Contract, UC) define objetivos y responsabilidades necesarias para cumplir con los niveles de servicio acordados en un Acuerdo de Nivel de Servicio.

 

ITIL FASE II: DISEÑO DEL SERVICIO (PRIMERA PARTE)

Metas y Objetivos:

Diseñar nuevos servicios de TI. Esto incluye el diseño de servicios nuevos, así como cambios y mejoras de los existentes

Valor para el Negocio:

  • Contribuir a los objetivos del negocio
  • Contribuir al ahorro de tiempo y dinero
  • Minimizar o prevenir riesgos
  • Contribuir a satisfacer necesidades presentes y futuras del mercado
  • Evaluar y mejorar la eficacia y eficiencia de los servicios de TI.
  • Apoyar el desarrollo de políticas y estándares para los servicios de TI
  • Contribuir a mejorar la calidad de los servicios de TI

Diseñar nuevos servicios de TI. Esto incluye el diseño de servicios nuevos, así como cambios y mejoras de los existentes . Que debemos resolver:

  1. ¿Cuáles son los requisitos y necesidades de nuestros clientes?
  2. ¿Cuáles son los recursos y capacidades necesarias para prestar los servicios propuestos?
  3. ¿Los servicios son seguros, ofrecen la disponibilidad necesaria y se garantiza la continuidad del servicio?
  4. ¿Son necesarias nuevas inversiones para prestar los servicios con los niveles de calidad propuestos?
  5. ¿Están todos los agentes involucrados correctamente informados sobre los objetivos y alcance de los nuevos servicios o de las modificaciones a realizar en los ya existentes?
  6. ¿Se necesita la colaboración de proveedores externos?

4p.png

A fin de garantizar e integrado entorno coherente en los procesos de TI y las actividades y, básicamente, en toda la organización un enfoque holístico debe ser desarrollada y aprobada en el servicio de diseño. Tal actitud se asegurará de alta calidad de los servicios prestados, así como a extremo de continuidad de negocio de gama.

Para asegurarse de que el diseño de servicios esté debidamente aprobada hay cuatro P que deben ser considerados cuando se trata de diseño de servicios:

La gente (People)tiene que tener las habilidades y competencias poper posee con el fin de participar en la prestación de servicios de TI

Productos (Products)que están en la gestión de los sistemas de tecnología utilizada en el proceso de prestación de servicios de TI

Procesos (Processes )de funciones y actividades tienen que estar en estrecha relación el uno al otro

Socios (Partners) que son los principales proveedores, 3 empresas de software, fabricantes, proveedores involucrados en la prestación de servicios de TI

diseño del servicio.png

Habíamos explicado en el post anterior sobre Service Strategy (Estrategia del Servicio) que se encargaba primordialmente de analizar lo que le vamos a brindar al cliente (Gestión del Portafolio del Servicio), cuanto demanda el servicio brindado (Gestión Financiera) y analizar a cuantos clientes se provee el servicio (Gestión de la demanda); pues bien después de haber analizado el rubro de la organización y de decidir ¿Cómo? le vamos a brindar el servicio ahora toca diseñar el servicio, es aquí donde entra en acción: Service Design (SD).

Definición

Service Design (SD) diseña los servicios de TI que se va a brindar, esto incluye: arquitecturas, procesos, políticas y documentación; para cubrir con el actual SLA y las futuras necesidades (Integración con el negocio), es decir y para entenderlo mas claro aun, lo que hace SD es trasladar los planes estratégicos y objetivos que se decidió en SS, hacia la creación de diseños y especificaciones (procesos y políticas) que luego serán ejecutados en las fases de Transición y Operaciones.

Vamos a poner un ejemplo : Una organización que necesita almacenar información de sus clientes y nosotros como expertos en TI mediante la Estrategia del Servicio hemos decidido brindar los siguientes servicios: un SGBD (Sist. Gestor de BD) y un sistema web en la nube; después de haber tomado esta decisión entra Diseño del Servicio y su trabajo es:

Crear políticas: Por ejemplo, el backup de la BD se hace al medio día y a la media noche y se almacena en un lugar externo al de la empresa (obviamente se deben crear mas políticas).

Diseño de arquitectura

Apoyar al diseño del portafolio: SD apoya a SS en la creación del portafolio, imagínense que el jefe de IT que esta negociando el servicio que va a brindar (SS) y el cliente solicita un servicio bajo Red Hat Linux para su BD y aplicación, entonces el jefe de IT acepta pero luego se da cuenta que ellos no cuentan con personas especialistas en Red Hat, es obvio que esto no puede pasar, por eso SD  apoya en el diseño del portafolio advirtiendo que no se puede brindar servicios de Linux debido a que no se cuenta con personal capacitado para esta actividad.

Tecnología efectiva: ¿Qué usamos? un switch CISCO o un switch no administrable.

Diseño de proceso y sus métricas: El proceso son los pasos detallados para implementar el servicio, por ejemplo:

Paso 1: Instalar el SO bajo ciertas caracterices

Paso 2: Instalar JAVA o PHP de la siguiente manera

Paso 3: Instalar la BD: MySQL o Oracle con los siguientes parámetros

Paso 4: ……..

¿Y todo esto para qué es necesario?

Obviamente tener todo organizado tiene sus ventajas económicas y esto se refleja en el TCO (Costo total de la propiedad), por ejemplo el TCO de una computadora es:

Hardware + Software + Servicio recibido.

Tener documentado paso por paso MEJORA LA CALIDAD DEL SERVICIO, MEJORA LA CONSISTENCIA DEL SERVICIO y MEJORA EL GOBIERNO CORPORATIVO.

Actividades de SD

Gestión del Portafolio del Servicio

Identificación de los requerimientos del negocio, definición y diseño del servicio

Diseño de la arquitectura tecnológica

Diseño del proceso

Diseño de las métricas

¿QUE VAMOS A GESTIONAR EN ESTA FASE?

DISEÑO2.png

DISEÑO3

Gestión del Portafolio del Servicio (SPM): El dueño de este proceso no es SD sino SS, es decir SS aprueba el portafolio de servicio que se va a brindar al cliente pero es obvio que necesita del apoyo de SD para conocer precios, fortalezas, oportunidades, debilidades y amenazas del servicio.

Identificación de los requerimientos del negocio, definición y diseño del servicio: Para poder apoyar a la SPM primero necesitamos saber que requiere el negocio con exactitud y recién sabiendo que quiere el cliente podemos diseñar el servicio, evaluar las alternativas de diseño y conocer los costos que este implica.

Diseño de la arquitectura tecnológica: Hace referencia al diseño arquitectónico y la arquitectura empresarial.

Diseño del proceso: El proceso responde a la pregunta: ¿Qué hago primero? ¿Qué hago en segundo lugar?, un proceso es conjunto estructurado de actividades para cumplir un objetivo. No olvidemos que un proceso incluye cosas muy importantes como: roles, responsabilidades, herramientas y el control del proceso.

Un proceso incluye no solo los pasos generales a seguir sino también las normas a seguir en caso de excepciones, además de dueños del proceso y salidas cuantificables. ITIL exige que todo resultado de un proceso sea medible para poder incluirlo en la mejora continua.

Diseño de las métricas: Si un proceso no puede ser medido no puede ser gestionado ni mejorado por lo que lo importante aquí no es el concepto de medición sino saber ¿Cómo medir? y no existe una respuesta exacta a esta pregunta porque saber como medir un proceso depende del servicio implementado y del rubro del negocio, es decir debe estar alienado con los objetivos del negocio.

DISEÑO4

DISEÑO5

DISEÑO6

DISEÑO7

DISEÑO8

Traducción de Microsoft Operations Framework 4.0 al español #MOF

Les recomiendo bajar el Marco de Referencia de Operaciones de Microsoft® Operations Framework (MOF) consta de la integración de mejores prácticas, principios y actividades que proporcionan guías para alcanzar la confiablidad de las soluciones y Servicios de TICs.

http://gallery.technet.microsoft.com/Traduccin-de-Operations-67defd3c/view/Discussions#content

Excelente aporte

 

Proceso 5: Administración de Niveles de Servicio (segunda parte) #MOF

Actividades: Administración de Niveles de Servicio

La siguiente Tabla enlista las Actividades involucradas en este proceso.   Estas Actividades incluyen:

  • Administrar las relaciones con la Organización.
  • Dar seguimiento a los cambios en las necesidades de la Organización.
  • Crear el Catálogo de Servicios.
  • Definir OLAs.
  • Definir UCs.
  • Definir SLAs.

Actividades y Consideraciones para la Administración de Niveles de Servicio

Actividades Consideraciones
Administrar las relaciones con la Organización Preguntas Clave:

  • ¿Qué temas clave y métricas de  Rendimiento se deben de Reportar? (como ejemplos se pueden incluir métricas de Confiabilidad, reportes financieros, reportes de Valor al Negocio o de las mejoras introducidas.)
  • ¿Qué tan seguido se deben de generar los Reportes? ¿Los Reportes pueden estar en Línea? ¿Cómo se puede asegurar el Área de TICs, de que la Organización esta revisando los Reportes?
  • ¿Qué tan seguido se deben de llevar a cabo las reuniones formales y las Revisiones Gerenciales?
  • ¿Cómo se deben de comunicar los issues urgentes?
  • ¿Qué fallas en los Servicios requieren de atención por parte de la Organización?

Entradas:

  • Reportes de Confiabilidad
  • Reportes de apego a las Políticas
  • Reportes Financieros
  • Nuevos requerimientos de la Organización
  • Nuevos requerimientos Regulatorios

Salidas:

  • Resultados de la Revisión Gerencial de Alineación del Servicio
  • Comunicación hacia la Organización

Mejores Prácticas:

  • Asignar a un Administrador de Cuenta, una persona responsable de estructurar la comunicación, los requerimientos para la Administración, issues en la escalación y de asegurar que las necesidades actuales de la Organización se están cubriendo.   Si la Organización es grande, se debe de considerar la posibilidad de asignar un recurso para cada una de la Unidades de la Organización.
Dar seguimiento a los cambios en las necesidades de la Organización Preguntas Clave:

  • ¿Cómo mantendrá la Organización informada al Área de TICs acerca de los cambios en la Estrategia de la Organización, en los Planes, en los requerimientos Regulatorios?
  • ¿Como debe la Organización solicitar  mejoras a los Servicios?

Entradas:

  • Procesos de la Administración del Cambio para los requerimientos de la Organización
  • Actualizaciones a los requerimientos de Gobernabilidad  y de Políticas

Salidas:

  • Solicitudes de Cambio por parte de la Organización

Mejores Prácticas:

  • Mantener el seguimiento del ritmo de las actividades de la Organización, para monitorear y entender tanto el aumento como la disminución de la demanda o la Confiabilidad.   Por ejemplo: durante las temporadas de vacaciones, un sistema de punto de venta puede tener una carga adicional.
Crear el Catálogo de Servicios Preguntas Clave:

  • ¿ Cuál es el público objetivo para el Catálogo? ¿Se debe elaborar el Catálogo únicamente para los usuarios finales y para los clientes internos en la Organización o se deben de incluir Servicios que se ofrecen a otros Grupos de TICs (por ejemplo, aquellos que requieren servidores nuevos, los que requieren consolidar servidores, o los que necesitan revisiones en temas de seguridad)?
  • ¿Qué Servicios de TICs necesitan los usuarios finales/clientes para hacer su trabajo?
  • ¿ Qué vistas del Catálogo pueden compartirse con cualquiera en la Organización? ¿Cuáles son exclusivas para un segmento dado de usuarios finales/clientes?¿Hay alguna aplicación Financiera aplicable sólo para el Área de Finanzas?¿Hay un Servicio para los escritorios de trabajo que esté disponible para todos en la Organización?
  • ¿Qué Servicios de TICs considera la Organización como escenciales?¿Cómo se llaman esos Servicios? (Ejemplos pueden incluir la configuración de equipos nuevos, limpieza de virus, reset de passwords, archivar los datos de los reportes financieros, arreglar los problemas de acceso a una aplicación, implementación de una Política de la Organización y la administración de Identidades.)

 

  • ¿Qué atributos debe tener el Catálogo? (Los ejemplos pueden incluir el Servicios de la Organización al que se apoya, el dueño del Servicio, la descripción del Servicio, la Política en que se apoya, el modelo para los cargos por el Servicio y/o las actualizaciones planeadas para el Servicio.) Para ver un ejemplo de Catálogo de Servicio se tiene el Apéndice “A”: “Ejemplo de Catálogo de Servicio para las estaciones de trabajo del Woodgrove Bank” al final de este documento.

Entradas:

  • Servicios en productivo que se muestran en el Portafolio
  • Mapas de Servicios
  • Vistas requeridas por los usuarios finales que describan los Servicios que pueden solicitar
  • Registros de solicitudes de Servicios
  • Vistas requeridas por el Área de TICs que describan los Servicios que dependen de TICs tales como aprovisionamiento de servidores, respaldos, actualizaciones y parches de software
  • Vistas requeridas por las Áreas de la Organización y los ejecutivos de TICs que muestren una mirada muy amplia con una integración de los Servicios de TICs definidos en el Catálogo

Salidas:

  • Una estructura del Catálogo de Servicios que apoye una clara comunicación de las ofertas del Área de TICs para la Organización y de unas Áreas de TICs a otras Áreas de TICs

Mejores Prácticas:

  • Tratar al Catálogo de Servicios como si fuese una decisión corporativa de la Organización que la lleva a definir un nuevo modelo y un nuevo estándar para la entrega de Servicios de TICs a la comunidad interna de la Organización.
  • Asegurar que representantes de los usuarios finales y de las Unidades de la Organización dirijan el proceso para definir los requerimientos de la estructura del Catálogo, su contenido y sobre todo la facilidad de uso.
  • Dejar saber a los usuarios del Catálogo de Servicios, que este crecerá en el tiempo conforme se vayan incorporando nuevos Servicios se vayan teniendo cambios en los Servicios existentes y también conforme el Área de TICs mejore su entendimiento de las necesidades de los usuarios.
  • Ofrecer un conjunto de Servicios básicos que abarquen al mayor número de usuarios, e ir creciéndolos poco a poco. Servicios a ser incluidos en un Piloto pueden ser el reset de passwords, conectividad de la telefonía móvil, la adquisición de PCs.
  • Organizar el Catálogo de Servicios en Servicios internos de TICs, Servicios a usuarios finales y Servicios a la Organización.
  • Ligar el Catálogo de Servicios con el sistema de solicitud de Servicios.
Definir los OLAs Preguntas Clave:

  • ¿Hay un Mapa de Servicio que incluya todos los Servicios de los que se depende y su relación con los Servicios de la Organización identificados en el Catálogo de Servicios?
  • ¿Qué servicios críticos de los que se depende requieren de contar con un OLA para asegurar que se pueda cumplir un SLA? ¿Cuáles de los Servicios de los que se depende forman parte de la infraestructura básica de la que dependen los Servicios de la Organización?Los ejemplos pueden incluir el Directorio Activo de Microsft ® y los Servicios de la Red de Datos.
  • ¿Quiénes son los dueños de los Servicios de los que se depende?

Entradas:

  • Mapas de Servicios
  • SLAs existentes

Salidas:

  • OLAs

Mejores Prácticas:

  • Las discusiones para los OLAs deben enfocarse en responsabilidad compartida que tienen todos en el Área de TICs para la entrega de Servicios de excelente calidad, que sean rentables y que ayuden a alcanzar las Metas y Objetivos de la Organización.   Al principio, quizá tenga sentido limitar el número de OLAs para tres o cuatro de los Servicios que sean más críticos para la infraestructura básica.  Tres de los Servicios candidatos para estar en la lista son:
  • El Grupo del Directorio Activo
  • El Grupo de Seguridad
  • El Grupo de Red de datos (Este puede involucrar múltiples OLAs debido a la amplitud de los Servicios que entregan la mayoría de los Grupos  de Redes – por ejemplo, DNS, DHCP, LAN, y WAN.)
Definir los UCs Preguntas Clave:

  • ¿La Organización tiene representantes legales y lineamientos de Gobernabilidad para definir y cerrar los UCs?¿De que forma el representante legal se puede involucrar al principio, de tal forma que los requerimientos legales sean parte de las conversaciones iniciales con el socio?
  • ¿Hay otros departamentos (tales como producción o finanzas) que tengan contratos similares  con sus socios?¿Cómo se puede beneficiar el Área de TICs de esa experiencia?
  • ¿Cómo se medirá y reportará el rendimiento del Contrato?
  • ¿Cuáles son las expectativas de la comunicación entre la Organización y el Socio?
  • ¿Quienes son los contactos principales tanto de la Organización como por parte del Socio?¿En caso de un incidente, cuál es la ruta de escalación?
  • ¿Quienes se deben de involucrar para definir los siguientes elementos que son clave para los UCs?¿Cuáles de los siguientes elementos deben ser parte del Contrato y cuáles   deben de estar en segundo plano?
    • Introducción
    • Descripción del Servicio
    • Horario de Servicio
    • Disponibilidad y Confiabilidad
    • Caminos para recibir Soporte
    • Tiempos de respuesta de las transacciones
    • Rendimiento
    • Expectativas para la Administración de Cambios
    • Administración de incidentes: registro, seguimiento, recursos y cierre
    • Administración de Problemas: registro, documentación, recursos y cierre
    • Expectativas de la participación del socio en las reuniones para la Administración de Problemas y reuniones del CAB
    • Expectativas del documento de alcance de los trabajos y de acta de proyecto
    • Procedimientos para la Liberación y para las Pruebas
    • Expectativas de la metodología para la Administración de Proyectos
    • Requerimientos o restricciones de las Herramientas
    • Continuidad y Seguridad del Servicio de TICs
    • La forma en que se realizan los cargos
    • Revisiones y Reportes del Servicio
    • Iniciativas de Rendimiento, métricas y penalizaciones
    • Obligaciones contractuales, cláusulas de resición y la forma en que se llevarán a cabo las litigaciones
    • Requerimientos de acuerdos de confidencialidad y acuerdos
    • Derechos para realizar Auditorías
    • Otros requerimientos de protección según lo requiera el departamento legal de la Organización (clausulas de indemnización, penalizaciones y deducciones, entre otros)

Entradas:

  • SLAs
  • OLAs
  • Listado de Socios preferidos

Salidas:

  • Contrato Sustentado (UC)

Mejores Prácticas:

  • Un componente importante de los UCs (al igual que con los SLAs y los OLAs) es la definición de lo que se considera su éxito y la forma de medirlo.   Ejemplos de esos criterios pueden incluir:
  • Porcentaje de los Sistemas que completaron de forma exitosa la Política de actualización sin fallas.
  • Número de problemas y errores conocidos.
  • Duración de la actualización.
  • Itinerarios de Notificación.
  • Horario de Disponibilidad.
Definir los SLAs Preguntas Clave:

  • ¿El Servicio tiene una especificación exacta? ¿El Servicio tiene objetivos (tales como Disponibilidad, Capacidad, y horas de Servicio) a los que se haya comprometido?
  • ¿Cómo se van a comunicar los Reportes? Para más información en relación a los Reportes, ver la Revisión Gerencial del Servicio de MOF.
  • ¿Se han identificado los OLAs y los UCs de los que depende el SLA? ¿Quiénes son sus dueños?
  • ¿Cómo se publicará el SLA? ¿Va a estar vinculada al Catálogo de Servicios?¿ Cómo se podrá saber si las personas lo utilizan?
  • ¿Cómo se medirá el rendimiento del SLA?¿Cómo se sabrá si se han tomado las medidas para mejorar el Rendimiento? ¿Habrá Revisiones periódicas?
  • ¿Quién es el dueño del SLA por parte del Área de TICS y quién por parte de la Organización?
  • ¿Cómo se estructurarán los SLAs? ¿Se organizarán por Servicio, por Cliente o de acuerdo a los Servicios de los que dependen?

Entradas:

  • OLA
  • UCs
  • Catálogo de Servicios

Salidas:

  • SLA con los siguientes componentes:
  • Información del Contacto de las dos partes
  • Descripción del Servicio
  • Duración del SLA
  • Roles y Responsabilidades de TICs
  • Horarios y excepciones para el Servicio
  • Objetivos de Disponibilidad
  • Objetivos de Confiabilidad
  • El proceso de Cumplimiento
  • Métricas:
  • Información del proceso de Cambio que atiende las siguientes preguntas:
  • ¿Como se manejarán los Cambios al SLA?
  • ¿Con cuanta anticipación se solicitan?
  • ¿A quién se le solicita?
  • ¿Quién puede aprobar?
  • ¿Quién puede solicitar?
  • Información sobre las interrupciones que responda a las siguientes preguntas:
  • ¿Como se manejan las interrupciones?
  • ¿Cuál es el tiempo esperado de recuperación, por tipo de severidad?
  • ¿Como se lleva a cabo la escalación y quién puede escalar?

Mejores Prácticas:

  • Asegurar que los Servicios de Infraestructura Básica como la red de datos, los sistemas operativos, las bases de datos y las herramientas de comunicación y de colaboración están diseñados para cumplir con los SLAs de la Organización.   Al mismo tiempo, cuando se ajusta o se crea un nuevo SLA, no se deben de comprometer Niveles de Servicio que no puedan ser apoyados por las capacidades de la infraestructura actual.
  • Asegurar que los SLAs estén escritos desde la perspectiva de la Organización.   Ejemplo: Utilizar las métricas de la Organización para definir el Cumplimiento, además de las métricas de TICs.   Un sistema de inventario en tiempo real se describe tal vez por “la precisión del inventario a mano” y por “la disponibilidad de los reportes  del inventario en tiempo real” así como por la disponibilidad del Servidor.
  • Evaluar las mediciones del SLA utilizando los siguientes criterios:
  • ¿Son compatibles con los objetivos de la Organización?
  • ¿Son específicos?
  • ¿Pueden ser medidos?
  • ¿Son alcanzables, aún y cuando se requiera un esfuerzo significativo por parte del Área de TICs?
  • ¿Son realistas en relación a los beneficios que traerán a la Organización?

Para ver un ejemplo de un Acuerdo de Nivel de Servicio, ver el Apéndice B: “Ejemplo de un SLA,” al final de este documento.

Proceso 5: Administración de Niveles de Servicio (primera parte) #MOF

Si la Estrategia de TICs va a estar totalmente Alineada con la Estrategia de la Organización, entonces el Área de TICs debe Administrar la entrega continua y las mejoras de sus Servicios, esta es la Meta de la Administración de los Niveles de Servicio. La Administración de los Niveles de Servicio asegura que los requerimientos para la continuidad, las comunicaciones y las espectativas de la Organización con respecto a las TICs se Gestionan de una manera proactiva.   La Administración de los Niveles de Servicio también se responsabiliza de asegurar que las espectativas internas del Área de TICs se alcancen.

El Catálogo de Servicios fija los estándares contra los que serán medidas las métricas de las espectativas, las mejoras y el rendimiento.   Los SLAs y los Acuerdos de Niveles de Operación (OLAs por sus siglas en inglés) aseguran que existen los acuerdos para poder cumplir con las ofertas en Catálogo de Servicios.

Catálogo de Servicios de TICs:

  • Comunica los Servicios de TICs estándar a los clientes en términos claros y familiares.
  • Proporciona un medio centralizado a través del cual los usuarios finales pueden solicitar paquetes de Servicios de TICs estandarizados.

Acuerdos de Niveles de Operación (OLAs):

  • Comunica y documenta las expectativas acordadas, de los servicios de TICs que dependen de un tercero.
  • Se acuerdan entre Grupos de TICs.

Acuerdos de Niveles de Servicio (SLAs):

  • Comunica y documenta las expectativas de los Servicios, acordadas entre la Organización y el Área de TICs.
  • Se acuerdan entre la Organización y los representantes de TICs.

Contrato Sustentado (UC):

  • Asegura que hay un Contrato entre los Proveedores, los Terceros y la Organización.
  • Comunica y documenta las expectativas acordadas entre los Proveedores, los Terceros y la Organización

La siguiente imagen representa la relación entre los clientes, los SLA, los OLA y los UC

 

La siguiente imagen  muestra de forma gráfica un conjunto de SLAs y de OLAs para el ficticio Woodgrove Bank. El SLA sirve para asegurar que el usuario final recibe un soporte de escritorio de forma rápida y precisa.   La usabilidad general del escritorio está garantizada a través de este SLA; sin embargo, el área de soporte del servicio sirve como un embudo para los OLAs que cubren los servicios al hardware del escritorio, el de mensajería, el directorio de infraestructura, las aplicaciones de acuerdo a la línea del negocio (LOB por sus siglas en inglés) y el de red de datos.

 

Proceso 4: Desarrollar y Evaluar un Portafolio de Servicios de TICs #MOF

Cuando la Organización ha finalizado con la Estrategia de Servicios de TICs, la Organización y el Área de TICs deben determinar cuáles Proyectos y Servicios apoyan en mayor medida dicha Estrategia.   El Portafolio de Servicios de TICs es una lista de esos Proyectos y Servicios.   El asegurar que los Servicios y proyectos correctos sean incluidos en el Portafolio, requiere de los siguientes elementos:

  • Los Proyectos propuestos están Alineados con las iniciativas de la Estrategia de TICs
  • Una lista de Proyectos en lista de espera, Servicios Implementados, y servicios previstos para ser dados de baja
  • Un proceso de priorización  y aprobación de los nuevos Proyectos
  • Un sistema de medición para poder determinar el valor de los Servicios en relación a las Metas del Negocio

El Portafolio de Servicios de TICs mueve la Alineación del consumo de los recursos de TICs, el presupuesto de operación, y las Estrategias de inversión que apoyan la Estrategia de los Servicios de TICs.   Los principales usuarios del Portafolio son los líderes de la Organización y de las TICs, responsables de la Realización del Valor al Negocio con base en las inversiones en TICs.

 Actividades: Portafolio de Servicios

La siguiente Tabla enlista las Actividades involucradas en este proceso.   Estas actividades incluyen:

  • Definir la estructura y composición del Portafolio de Servicios de TICs.
  • Medir el valor de los Servicios de TICs en relación con los resultados de la Organización.
  • Analizar y aprobar los nuevos conceptos de Proyecto.
  • Publicar el Portafolio.

Actividades y Consideraciones para Desarrollar y Administrar un Portafolio de Servicios de TICs

Actividades Consideraciones
Definir la estructura y composición del Portafolio de Servicios de TICs Preguntas Clave:

  • ¿Cómo se debería de Estructurar el Portafolio de Servicios? ¿Cómo se deberían de clasificar los activos de TICs (por ejemplo, servicios básicos que proporcionen una diferencia para la Organización tales como sistemas de para manufactura o de conocimiento de clientes y sistemas de la Organización como la nómina o un Portal de beneficios o sistemas para servicios de infraestructura como la red de datos o una granja de servidores?

Entradas:

  • Los Planes de la Organización y los modelos Financieros
  • Modelos o Estructuras de Inversión de la Organización

Salidas:

  • Definición de la Estructura y de la Subestructura del Portafolio de Servicios
  • Descripciones de los Servicios (qué es el Servicio, a que procesos de la Organización apoya, y cuales  son los componentes que los que depende el Servicio)
  • Categorías en el inventario para clasificar las inversiones en TICs, en el contexto de los Servicios de la Organización

Mejores Prácticas:

  • Considerar incluir los siguientes elementos en el portafolio de Servicios:
  • Nombre del Servicio: Explicar con detalle todos los servicios (incluidos los servicios de infraestructura) en términos que reconozca la Organización.
  • Funciones de la Organización a los que apoya el Servicio: Identificar las Funciones y Procesos de la Organización que se apoyan en el Servicio.
  • Contribución del Servicio a la Organización: Explicar en términos de reducción de costos, ventaja competitiva o de cumplimiento regulatorio.
  • El Patrocinador por parte de la Organización: Un Directivo de alto nivel en la Organización que apoya directamente el Servicio de TICs a través de compromisos financieros.
  • Administrador de la relación entre la Organización y el Área de TICs: La persona responsable de asegurar que exista una comunicación  y Alineación entre el Área de TICs y la Organización.
  • Hoja de Ruta: La información sobre la próxima actualización prevista o posible sustitución o baja del Servicio; es un plan para los próximos dos a tres años.
Medir el valor de los Servicios de TICs en relación con los resultados de la Organización Preguntas Clave:

  • ¿Qué constituye el Valor al Negocio y cómo se va a medir? ¿Qué hay acerca de la percepción del cliente y el impacto a la Organización? ¿Puede el Área de TICs medir el Valor al Negocio de igual forma en que lo hace la Organización mediante modelos de Retorno de la Inversión (ROI por sus siglas en inglés), valor presente neto (NPV por sus siglas en inglés), valor económico añadido (EVA por sus siglas en inglés)? (para más información.
  • ¿Qué criterios se necesitan para apoyar las decisiones con respecto a la inversión (valor, costo o tolerancia al Riesgo)?

Entradas:

  • Mejoras mediante adiciones o solo de forma, aprobadas a la Estrategia del Servicios de TICs, definidas en términos de oportunidades o requerimientos de la Organización
  • Mapas de Servicio que relacionen a los clientes, los procesos de la Organización, las aplicaciones, y los componentes de infraestructura de TICs

Salidas:

  • Declaración del Valor del Servicio donde se decribe como el Servicios de TICs apoyan la reducción de costos, proporcionan una ventaja estratégica o como apoyan el cumplimiento de las regulaciones

Mejores Prácticas:

  • Estar concientes de la forma en que se empaquetan los Servicios.   Con modelos de costo, mediante agrupación de componentes, fijando precios a los diferentes niveles del Servicio, agrupando opciones, ya que todo esto va a influir en la forma en que los usuarios consuman el Servicio.
Analizar y aprobar los nuevos conceptos de Proyecto Preguntas Clave:

  • ¿Cuál es el nivel de detalle, de los datos del Proyecto, que se requiere en este primer nivel de aprobación?
  • ¿Cómo debe de demostrar el Proyecto una clara conexión y apoyo a las Iniciativas definidas en la Estrategia de TICs?
  • ¿Como se va a llevar a cabo la priorización de los Proyectos?¿Cómo se va asegurar la consistencia durante el proceso de priorización?
  • ¿Quiénes deberían de estar en el Consejo de asesoría para la aprobación? ¿Cómo puede este Consejo de asesoría asegurar un enfoque de la Organización para este tipo de aprobación?  (para más información.

Entradas:

  • Propuestas de conceptos de Proyectos
  • Consejo de asesoría con autoridad aprobada
  • Método y proceso de Priorización

Salidas:

  • Conjunto de Proyectos aprobados y con un dueño asignado
  • Comunicación de los conceptos de Proyectos aprobados

Mejores Prácticas:

  • Cuando los conceptos de Proyecto reciban se aprueben, es importante definir un Equipo y comenzar con la Fase de entrega del ciclo de vida de los Servicios de TICs.   Esto comienza con el proceso de Conceptualización.
  • Asignar un Grupo de aprobación que tenga la autoridad sobre el presupuesto y a quién se le asigne la Rendición de Cuentas, para asegurar los resultados para la Organización y para la Gobernabilidad de las TICs.
Publicar el Portafolio Preguntas Clave:

  • ¿Cómo verán los usuarios el Portafolio?¿Quién necesita de una vista de cada uno de los Proyectos y a qué nivel y con que detalle?

Entradas:

  • Listado de los Proyectos aprobados

Salidas:

  • Portafolio actualizado y publicado

Mejores Prácticas:

  • Asegurar que cada Proyecto tiene la siguiente documentación:
  • Punto de contacto
  • Servicio Asociado y/o Grupo dentro de la Organización
  • Descripción y beneficios esperados
  • Una Cronología
  • Recursos
  • Riesgos, supuestos y posibles obstáculos
  • Categorizar los Proyectos del Portafolio utilizando las siguientes denominaciones:
  • Inversiones estratégicas iniciadas por las TICs
  • Inversiones estratégicas a instancias de la Organización
  • Proyecto requerido con base en el Cumplimiento o en las regulaciones
  • Proyecto para mantener o para mejorar
  • Proyecto Reactivo debido a un cambio en la tecnología o en la Organización

Proceso 3: Identificar la Demanda y Administrar las Solicitudes de la Organización #MOF

El Análisis de la Administración de la Demanda y de las Solicitudes es un proceso, donde se describe como se utilizan y se solicitan los Servicios de TICs, por la Organización y como las tendencias futuras pueden afectar los Servicios.   Los datos de la Administración de la demanda ayudan a los administradores a Planear los gastos en TICs y a Rendir Cuentas sobre los mismos, así como a entender los Servicios de TICs de la Organización que reciben a cambio del gasto efectuado, y finalmente a participar en la toma de decisiones acerca de futuros Proyectos y acerca de la asignación de recursos.

Un proceso ya maduro, para la Administración de la demanda y de las solicitudes debe asegurar que:

  • Hay un proceso predecible para la Administración de Solicitudes.
  • Hay un modelo consistente para medir la demanda actual.
  • Hay un método para analizar las solicitudes y la capacidad actual de los Servicios.

Actividades: Administración de la Demanda y de las Solicitudes

La siguiente Tabla enlista las Actividades involucradas en este proceso.   Estas actividades incluyen:

  • Administrar las nuevas Solicitudes.
  • Capturar el uso actual y la demanda de los Servicios.
  • Identificar y validar las tendencias futuras.
  • Analizar la demanda y las solicitudes.

Actividades y Consideraciones para las actividades de Administración de la Demanda y de las Solicitudes

Actividades Consideraciones
Administrar las nuevas Solicitudes Preguntas Clave:

  • ¿Que herramientas (además del Catálogo de Servicio) se utilizan para solicitar Servicios o Productos de TIC?
  • ¿ Las Solicitudes canalizadas a través de estos medios reflejan actividades planeadas o presupuestadas ya definidas en el Portafolio de Servicios? ¿Estas actividades han sido presupuestadas como parte del Plan de Operación de TICs aprobado?
  • ¿Las Solicitudes de Servicio reflejan una nueva oportunidad de negocio o una mejora de la operación de las TICs?
  • ¿Qué tipo de Sistema para la Administración del Cambio  se utilizará para registrar las Solicitudes? ¿Cómo se categorizarán y clasificarán las Solicitudes?¿Cómo se mapearán las Solicitudes contra los Servicios actuales?

Entradas:

  • Un Catálogo de Servicios capaz de rastrear todas las Solicitudes de Servicios de TICs
  • Solicitudes de cualquiera de las siguientes fuentes:
  • Otros Grupos de TICs internos con un canal establecido para el soporte
  • Proveedores externos y socios de negocio que sean parte de la cadena de valor de la Entrega de Servicio
  • Servicios Administrados de outsourcing
  • Sistema de seguimiento de Fallas
  • Herramientas para el Soporte a los escritorios de trabajo

Salidas:

  • Una vista organizada y consolidada de todas las Solicitudes realizadas a la organización de TICs

Mejores Prácticas:

  • Administrar las Solicitudes utlizando un proceso consistente, bien definido, que incluya los siguientes elementos:
  • Un formato de Solicitud de Cambio (RFC por sus siglas en inglés) donde se identifique los criterios clave para la aprobación del Cambio, incluyendo (pero no limitado a) el impacto a la Organización, el nombre del Servicio, el Riesgo de aceptar o no la Solicitud.   Debido a que muchas Solicitudes llegan por parte de Grupos que no pertenecen a las TICs, las RFCs iniciales quiza no incluyan información relevante de TICs.
  • Una minuciosa Clasificación y Categorización de las Solicitudes.   Considerar organizar las Solicitudes por su impacto al Servicio, como nuevo Servicio, por su Riesgo o por las necesidades iniciales de recursos.
  • Una base de datos dedicada a almacenar las Solicitudes.   Los dueños de los Servicios, los dueños del presupuesto y los Administradores de la relación con la Organización van a querer ver, cada uno de ellos, la información de las Solicitudes desde una perspectiva diferente.
  • Para más información acerca del proceso de Solicitudes de Cambio
Capturar el uso actual y la demanda de los Servicios Preguntas Clave:

  • ¿Cómo es el Rendimiento de los Servicios críticos para la Organización? ¿Se cumple con las metas de Disponibilidad y con los SLAs? ¿Si las metas no se cumplen, la Capacidad es un issue?
  • ¿Existen Servicios que no se estén utilizando?
  • ¿Hay Capacidad adicional que los Servicios no estén utilizando?¿Hay Capacidad adicional en almacenamiento, en ancho de banda o en servidores?
  • ¿Hay un número adecuado de licencias para el software instalado?

Entradas:

  • Reportes de Capacidad
  • Reportes de Disponibilidad
  • Reportes de Licenciamiento, incluyendo aquellos de la auditoría

Salidas:

  • Reporte de Demanda (organizado por el uso actual y por el crecimiento anticipado de uso, y con la demanda mapeada contra los Servicios y las unidades organizacionales)

 

Activities Considerations
Identificar y validar las tendencias futuras Preguntas Clave:

  • ¿Cuáles son los Servicios críticos para la Organización? ¿Cómo afectan los Planes de la Organización a ésos Servicios?
  • ¿El costo de cualquier recurso se está incrementando?¿Cómo afectaría un incremento en el costo de la energía eléctrica, la habilidad para entregar los Servicios a un costo razonable? ¿Algún Servicio está en Riesgo debido al incremento de los Costos?
  • ¿Cualquier tendencia en la tecnología actual, le da una oportunidad para mejorar los Servicios a la Organización?
  • ¿Puede alguna oferta de un tercero reducir la carga sobre la organización (por ejemplo, filtrado de mensajes, administración de redes o servicios de mesa de ayuda)?
  • ¿Alguno de los Servicios que se dan con recursos propios están disponibles como Servicios Online (por ejemplo, el hosting de Servicio de mensajería)?

Entradas:

  • Reportes de tecnología y específicos para la Organización de firmas como Forrester Research, Inc., IDC y Gartner, Inc.
  • Otras fuentes de información de tendencias tecnológicas

Salidas:

  • Plan de trabajo que identifica la integración de las tecnologías clave para apoyar los objetivos de la Organización
  • Análisis de Riesgo sobre las tendencias de la Industria específica y de la tecnología

Mejores Prácticas:

  • Asegurar que la Organización tiene un entendimiento del impacto que los Servicios de TICs tiene en su eficacia.   Por ejemplo, como la colaboración y la mensajeria proporcionan mayor productividad, las nuevas formas de trabajar o la habilidad de expandirse en el ámbito geográfico.
  • Conforme el Grupo identifica tendencias importantes, estar al tanto de cualquier cambio importante de paradigma -cambios en la tecnología o  actitudes en cuanto a la forma de utilizarla- que puedan afectar la Operación de las TICs.   Por ejemplo, a partir de los años 90´s, una explosión de Servicios Web tuvo un gran impacto en todas las TICs.  Se le debe prestar mucha atención a:
  • La Virtualización que maneja de forma dinámica los cambios de la demanda.
  • Herramientas de Colaboración que aumentan la eficacia de los Equipos de trabajo virtuales.
  • Trabajo a distancia.
  • El incremento en el uso de tecnología para el consumidor (por ejemplo, los dispositivos móbiles).

Estar conscientes de las expectativas de los usuarios finales “sobre el soporte en estas áreas: tener en mente que ellos van a querer un servicio de 24/7.  También, asegurar que se han tomado en cuenta las implicaciones en cuanto a la seguridad, que tienen todos los cambios requeridos.

Analizar la demanda y las solicitudes Preguntas Clave:

  • ¿Qué tan frecuente debe llevarse a cabo un análisis? ¿Cómo puede apoyar el análisis, al ritmo de la demanda de la Organización?
  • ¿ Cómo debe entregar el Análisis para asegurar que se comprende? ¿Cómo se transmiten los mensajes clave y las recomendaciones?¿Qué resultados espera el Área de TICs a partir del Análisis?
  • ¿ El negocio tiene algunas expectativas acerca del nivel de detalle de la información, en el Análisis? ¿De qué forma puede el Área de TICs, presentar su Análisis para poder demostrar la Alineación con el Negocio y la importancia de los Servicios que ofrece?

Entradas:

  • Vista consolidad de las Solicitudes
  • Análisis de la demanda de los Servicios
  • Hoja de Ruta de la Tecnología y de las tendencias de la Industria

Salidas:

  • Recomendaciones que sirven de entrada para el proceso de Administración del Portafolio (las Recomendaciones toman la forma de Proyectos propuestos, mejoras a los Servicios existentes, o la baja de los Servicios)

Mejores Prácticas:

  • Las Recomendaciones para pequeñas mejoras se pueden presentar en cualquier momento.   Generalmente, las Recomendaciones que requieren de recursos monetarios o un concepto para un nuevo Proyecto se presentan durante el proceso de Planeación de la Organización.

Proceso 2: Identificar y Mapear los Servicios #MOF

Los Mapas de Servicios se utilizan en toda la organización de TICs para dejar claras las dependencias entre los SLAs, los OLAs, las tecnologías, los Clientes y el impacto a la Entrega del Servicio.   Estos Mapas identifican: los recursos necesarios para la Entrega de los Servicios decritos en el Catálogo de Servicios; quién Entrega ese Servicio; y quiénes consumen el Servicio.

Un Mapa de Servicio representa al Servicio desde la perspectiva de la Organización y la del Usuario.   Se divide en cinco secciones:

  • Clientes. Un listado categorizado de individuos y grupos que utilizan el Servicio.
  • Hardware. Las plataformas de Hardware necesarias para la Entrega del Servicio.
  • Aplicaciones. El (los) Sistema(s) Operativo(s) y otra(s) Aplicación(es) que requiere el Servicio.
  • Configuraciones. Los parámetros de Configuración necesarios para que funciones el Servicio.
  • Servicios Internos/Externos. Los componentes que ayudan a asegurar la disponibilidad del Servicio.

Actividades: Identificar y Mapear Servicios

La siguiente Tabla enlista las Actividades involucradas en este proceso.   Estas actividades incluyen:

  • Identificar los Servicios y sus Dueños.
  • Identificar a los clientes y usuarios clave.
  • Revisar, clasificar y categorizar los grupos principales de componentes del Servicio y a los dueños del Servicio.
  • Publicar los Mapas de Servicios.

Actividades y Consideraciones para Identificar y Mapear los Servicios

Actividades Consideraciones
Identificar los Servicios y sus Dueños Key questions:

  • ¿Como nombra la Organización al Servicio?
  • ¿Quén del Área de TICs rinde cuentas por los Servicios a entregados a la Organización?¿Quén es el representante del Servicio por parte de la Organización?
  • ¿El representante del Servicio, del Área de TICs, conoce a los dueños de Servicios, del Área de TICs, que dependan de este Servicio?
  • ¿Cuáles son los Servicios principales de infraestructura de TICs y quienes son sus dueños? ¿La Organización entiende la importancia de los servicios de infraestructura principales como las Redes, el Hosting (el procesamiento), la Mensajeria, los Servicios de Colaboración, la Seguridad, el Aprovisionamiento y los Servicios Web?

Entradas:

  • Matrices de Responsabilidades existentes – por ejemplo matrices RACI Responsible(responsable del problema o del proyecto)/ Accountable (la persona a la que rinde cuentas el Responsable)/ Consulted (la persona que debe ser consultada porque tiene la información para hacer el trabajo)/ Informed (persona que debe ser informada pero no necesariamente consultada)
  • Listado de Servicios y Aplicaciones de la Organización
  • Listado de Servicios de infraestructura
  • Sistemas de Administración de la Configuración (CMS)
  • Portafolio de Servicios; Catálogo de Servicios

Salidas:

  • Listado de los Servicios y de los Dueños de los Servicios, incluyendo a los representantes tanto de la Organización como de la organización de TICs
  • Listado de todos los Dueños de los Servicios que dependen del Área de TICs
  • Matrices RACI

Mejores Prácticas:

  • Utilizar RACI, CMS, Planes de Continuidad del Negocio (BC por sus siglas en inglés) y Planes de Recuperación de Desastres(DR por sus siglas en inglés) para identificar Servicios y Dueños que de otra forma pudieran no identificarse.
Identificar a los clientes y usuarios clave Preguntas Clave:

  • ¿Quiénes son los usuarios principales de los Servicios?
  • ¿Hay algún ciclo natural para el uso del Servicio? Por ejemplo: el uso es intensivo durante algún evento o en algunas ocasiones  lo largo del año?
  • ¿Cuál es el contexto, en el que el Servicio se utiliza, dentro  de la Organización? Por ejemplo: se utiliza por parte del Área Legal, por Finanzas, por Ventas y Marketing, o por investigación y desarrollo?

Entradas:

  • Dueños de los Servicios
  • Datos del Servicio que se encuentren en la Mesa de Servicios y en la Administración de Incidentes, que muestren quién es el que utiliza el Servicio

Salidas:

  • Lista completa de los principales Clientes y Usuarios
Revisar, clasificar y categorizar los grupos principales de componentes del Servicio y a los dueños del Servicio Preguntas Clave:

  • ¿Cuáles son todos los Componentes del Servicio? ¡Quién es el Dueño de cada Componente?¿Cuáles son los Componentes de Software y de Hardware? ¿Existen Componentes externos ya sea que estén hosteados o que pertenezcan a un tercero fuera de la Organización?
  • ¿Qué nivel de detalle se requiere para que la información sea útil? ¿Cuántos y cuáles Componentes del Servicio deberían de ser Mapeados para los Servicios que se le presentan a los Usuarios?
  • ¿Cómo están clasificados los Componentes en el CMS?
  • ¿Cómo están actualmente clasificados los Componentes en el Sistema deAdministración de Incidentes?
  • ¿Los componentes están definidos como Servicios? Si no, ¿Se pueden identificar de ésta forma?

Entradas:

  • Sistema de Administración de la Configuración (CMS)
  • Administración de Incidentes
  • Catálogo de Servicios
  • Diagramas de Flujo

Salidas:

  • Listado de clasificaciones y categorias de los Componentes, que estén Alineadas con el Sistema de Administración de las Configuraciones y con la Administración de Incidentes
  • Versión inicial del diagrama de Mapeo del Servicio (por ejemplo: en Microsoft® Visio®)
  • Versión inicial de la Table de Mapeo de los Servicios (por ejemplo en: Microsoft Excel®)

Mejores Prácticas:

  • Crear una herramienta que haga un mapeo entre las descripciones que hacen los usuarios de los Incidentes y los Servicios de TICs que se hacen cargo de estos incidentes (la herramienta puede ser tan simple como un Glosarios en un documento de Microsoft Word compartido en un Servidor).
Publicar los Mapas de Servicios Preguntas Clave:

  • ¿Quén necesita utilizar el Mapa de Servicio? ¿Qué otros procesos son dependientes del Mapa de Servicio?(por ejemplo, administración de incidentes, administración de problemas, Monitoreo y Control del Servicio todos ellos requieren tener una visibilidad de principio a fin del Servicio, mientras que los usuarios finales sólo requieren entender el flujo del proceso a un nivel más alto)
  • ¿Cómo se mantendrá actualizado el Mapa de Servicio?

Entrada:

  • Catálogo de Servicios
  • Portafolio de Servicios

Salida:

  • Mapeo de Servicios, presentados de forma visual (ver la Figura 2)
  • Mapas de Servicios donde se identifican los dueños de cada Servicio, incluso de los Servicios dependientes

 

 Mejores Prácticas:

  • Crear un Mapa del Servicio de Infraestructura que muestre los Servicios básicos que soportan a los demás Servicios de TICs.   Los Servicios Técnicos deberían de incluir el directorio de infraestructura, mensajería y colaboración, administración de archivos y respaldos, redes de datos, impresión, equipos de escritorio y granjas de servidores.  Otros tipos de Servicios pueden incluir aprovisionamiento, soporte a los equipos de escritorio, actualizaciones de software, parches (actualizaciones) y Reportes de Cumplimiento.