WhitePaper CMDB Con Deloitte

CMDB orientada a Servicios La clave de una Gestión Gesti ón de Activos TI orientada al Negocio

CMDB orientada a Servicios La clave de una Gestión de Activos TI orientada al Negocio

Índice A. Introducción

3

B. Antecedentes

3

C. Buenas Prácticas ITAM / CMDB

4

C.1. Alcance ITAM

4

C.2. Front-Offi ce: Capa de Presentación de Servicios TI

5

C.3. Back-Offi ce: Capa de Centro de Servicios TI

6

C.3.1. Arquitectura CMDB

6

C.3.2. ¿Activo TI o CI?

7

C.3.3. ¿Qué es un CI?

8

C.3.4. ¿Qué atributos CI?

9

C.3.5. Interoperabilidad ITIL / ITAM / ITPM

10

C.3.6. Ecosistemas TI en evolución

11

C.3.7. Orquestación de Procesos

12

C.3.8. Soporte a Operaciones TI

13

C.3.9. Costes de Servicio TI

14

D. Conclusiones

easyvista.com

15

2

deloitte.es


A. Introducción

Se requiere un diseño de procesos de gestión de activos y configuración que esté más focalizado al Negocio. Para ello, es de especial importancia iniciar esta fase de diseño con un catálogo de servicios TI consensuado con los requerimientos del Negocio. Esto aseguraría que la capa de infraestructura TI esté mejor alineada con los servicios TI activos, además de que facilitaría la trazabilidad de costes y parámetros de rendimiento que afecten a los servicios.

Hoy en día, diversas organizaciones apoyan su gestión de activos TI y configuración en una herramienta base: la Base de Datos para gestión de Configuración (CMDB, en adelante). Desafortunadamente, esta herramienta termina convirtiéndose, en ciertas ocasiones, en un “cajón de sastre” con elementos de bajo nivel (HW/SW) que no está 100% alineada con el catálogo de servicios TI para el Negocio.

En este documento se destacarán algunas buenas prácticas relacionadas con la Gestión de Activos TI (ITAM en adelante) y CMDB para cumplir con los objetivos antes planteados.

B. Antecedentes

Analizando la gestión de activos TI (ITAM por sus siglas en inglés) con un ojo crítico:

En esta primera sección se realizará un repaso rápido de algunos de los retos actuales detectados en la implantación de ITAM y CMDB.

•

Este proceso es inexistente en muchas organizaciones TI o quizá está diluido en diferentes personas

•

No se detectan casos en los que el foco de esta gestión de activos TI esté limitada a un inventario de carácter técnico, alimentado por herramientas de gestión de sistemas

•

Las fuentes de datos son diversas y no están integradas, se dispone de herramientas técnicas, ERP con información administrativa, etc

•

No existen procesos formales de gestión de ciclo de vida de los activos TI

Haciendo un poco de repaso sobre la problemática de varias organizaciones TI a la hora de implantar una CMDB, se presentan a continuación algunos puntos comentados con frecuencia: •

•

La CMDB termina convirtiéndose en un cajón de elementos poco organizados y a veces sin categorizar correctamente En numerosas ocasiones, se registra en ese repositorio de todo, con lo cual se hace innecesariamente complejo

•

No se identifican los atributos que aportan valor

•

No se implantan procesos eficientes que faciliten el mantenimiento de la CMDB, muchas veces no hay una gestión de cambios

•

Los mecanismos de reporting, si existen, están muy orientados a la operación de bajo nivel y no aportan métricas de consumo y coste de servicios, que le interesarían más al Negocio

¿Y qué ocurre con las iniciativas relacionadas con ITAM / CMDB? Siempre se tiene una visión inicial, unas ambiciones. Por ejemplo, se quiere adoptar ITIL, implantar ITAM de clase mundial, una CMDB potente y obtener certificaciones ISOxxxxx. Pero la realidad es que muchas organizaciones de TI se encuentran con que no hay presupuesto, especialmente en estos últimos tiempos; no se dispone de los recursos necesarios, lo que se quiere hacer no está alineado con el Negocio y, por tanto, no obtendrá la aprobación del Top Management. Al final, dichas organizaciones de TI se quedan en un plano más austero del que originalmente se había concebido.

3

EasyVista Deloitte


C. Buenas Prácticas ITAM / CMDB En esta sección se presentarán algunas pautas importantes a tomar en cuenta durante la concepción, diseño e implementación de procesos de gestión de activos y configuración.

C.1. Alcance ITAM Dentro del ciclo de vida de activos TI, hay cuatro aspectos básicos que se pueden considerar: el técnico, que esta fundamentado en el autodiscovery de HW y SW, el operacional que es el control de inventario, el contractual que es la gestión de contratos y licencias de SW; y finalmente el �nanciero, donde se lleva el controlling económico de los activos. En la siguiente tabla se muestran estos cuatro aspectos, junto con algunos de sus procesos destacados:

Aspectos Clave en ITAM

El aspecto operacional de ITAM, como es evidente, es muy amplio. Incluye no solo control de inventario sino también contempla aspectos de aprovisionamiento, almacén, proveedores, etc. Muchos de estos aspectos ya están de cierta forma cubiertos en un ERP, pero pueden estar bajo el control de TI en algunas organizaciones. A continuación se muestran algunos de sus procesos clave:

ITAM - Operacional

easyvista.com

4

deloitte.es


C.2. Front-Office: Capa de Presentación de Servicios TI Una iniciativa que podría ser estratégica para diversas organizaciones TI es la implementación de una plataforma de Servicios TI para todas las entidades de su Negocio. En ella se incluiría el catálogo de servicios TI y servicios departamentales, un IT store para descarga de herramientas de productividad y un panel de mis servicios, mis activos, mis contratos, base de conocimiento y dashboard(s) de servicios. Muchos de estos escaparates podrían ser perfectamente alimentados por una CMDB y por una base de Activos corporativos. Esta plataforma constituiría la capa de presentación de los servicios al Negocio, tal y como se muestra en el siguiente ejemplo:

Capa de Servicios TI para el Negocio

Una de las contribuciones principales de la CMDB y la base de activos TI serían las métricas sobre diferentes servicios a publicar en los dashboards de la capa de servicios TI mencionada anteriormente. Se pueden focalizar algunos de estos dashboards a determinados departamentos o unidades de negocio de la compañía. En el ejemplo se muestra KPIs del servicio correo electrónico gestionado en CMDB. Dashboard para Servicio TI - Email

En términos generales, esta plataforma de servicios TI representa una gran oportunidad para que las organizaciones TI:

5

•

Promocionen el catálogo de servicios TI a sus respectivas audiencias

•

Demuestren valor al negocio mediante la presentación de nuevas iniciativas

•

Fomenten la participación de usuarios: chat, social, foros de debate y buzón de sugerencias, entre otros

EasyVista Deloitte


C.3. Back-Offi ce: Capa de Centro de Servicios TI En el capítulo anterior se destacó la importancia que puede tener una capa de servicios para el Negocio. Dicha capa se puede alimentar de diversas fuentes de datos que aporten la información a presentar y, además, contengan toda la capa funcional necesaria para el cálculo de métricas o el control de procesos de soporte. Las capas de backoffi ce proporcionan estas capacidades de work�ow, reporting, analytics y gestión necesaria para dar soporte a los servicios TI. Se denominaría como Capa de Centro de Servicios TI y se focalizaría en gestión de servicios, activos, financiero y proyectos dentro del ámbito de la TI.

C.3.1. Arquitectura CMDB Como primer punto en este capítulo, se tratará el tema de arquitectura de una de las herramientas más importantes en la gestión de servicios: la CMDB. Se recomienda una visión Top-Down, desde el Negocio hacia las infraestructuras TI, para diseñar una CMDB. Siguiendo esta filosofía, es evidente que el punto de partida lógico es el catálogo de servicios TI. En esta fase se identificarían las diversas capas del mapa de servicios como los Business Services, IT services, Aplicaciones, Servidores e Infraestructura Red. Por otro lado, el recorrido inverso, Bottom-Up, se realizaría para calcular los costes asociados a los Servicios. Con estos dos enfoques de diseño, el ob jetivo primordial es agilizar la definición de la arquitectura de la CMDB, al mismo tiempo que se toman en cuenta los componentes financieros asociados a la entrega de servicios.

Capa de Servicios TI para el Negocio

Unos de los temas pendientes en muchas implantaciones de CMDB es el Precio del Servicio. Para ello, lo primero es identificar los costes unitarios por componente y almacenarlos en la CMDB. Posteriormente, se puede seguir un enfoque Bottom-up para calcular el coste de un servicio determinado y presentarlo a los usuarios finales mediante el catálogo de peticiones de servicio. Así, el departamento de TI logra una mayor transparencia de costes de entrega de servicio. McKinsey & Co1 realizó un estudio que sugiere cómo las funciones de infraestructura pueden contribuir en la reducción de costes y en la mejora de la entrega de servicios mediante una mejor gestión de la demanda. En este estudio se mencionan diversos atributos de una gestión efectiva de demanda y servicios, entre los que destaca un esquema detallado de precios (modelo Botton-Up) y mecanismos avanzados de asignación de costes que permitan a la TI presentar, de forma clara, datos sobre coste y consumo a los clientes implicados. 1

Managing Demand for IT Inf rastructure - McKinsey & Co. Business Technol ogy Office April 2014

easyvista.com

6

deloitte.es

CMDB orientada a Servicios La clave de una Gestión de Activos TI orientada al Negocio En el siguiente gráfico se muestra un ejemplo de agregación de costes asociado a los diversos componentes de un servicio. Esta información estaría disponible para los clientes en el catálogo de peticiones de servicio.

C.3.2. ¿Activo TI o CI?

activos TI que incluye equipos (HW), licencias (activos SW) y contratos.

Aunque ITIL® proponga una gestión de activos de servicio y configuración como un proceso “unificado”, es importante reconocer las diferencias entre ITAM y CMDB. Según el Libro ITIL® Service Transition, la Gestión de Activos se centra en el ciclo de vida de los activos de servicio, mientras que la Gestión de la Configuración se centra en la identificación, control y mantenimiento de componentes de servicio. Algunas organizaciones TI consideran ITAM como “la gestión técnica y administrativa” de

Dependiendo del Negocio de cada compañía, no todo activo TI es necesariamente un CI. A manera de ejemplo, para una empresa de Outsourcing, el mobiliario estándar de oficina se consideraría un activo pero no un CI. Algunos elementos, como los servidores o los componentes de red, se consideran activos de la compañía y además CI por ser componentes de servicio en CMDB.

El siguiente ejemplo gráfico nos muestra algunos criterios a tomar en cuenta en esta diferenciación entre Activo TI vs CI:

7

EasyVista Deloitte


C.3.3. ¿Qué es un CI? Siguiendo con las re�exiones de la sección anterior, es importante que la organización de TI establezca criterios claros para determinar qué componentes gestionar como CIs en una CMDB. Una regla que algunas organizaciones aplican es la de considerar como CI todo aquel elemento que sea hasta cierto punto “crítico” para el buen funcionamiento de un servicio TI y que pueda estar sujeto al control de cambios y versiones. No solo se trata de considerar al elemento de forma aislada, también es importante entender sus interacciones con otros elementos del mapa de servicios y así poder aplicar diversos tipos de análisis de impacto sobre el servicio afectado por dichos elementos. En numerosos casos, los elementos de una CMDB suelen ser componentes tangibles de un Centro de Datos, como Servidores y Electrónica de Red, o intangibles, como los clusters de HW o cualquier agrupación lógica de CI que cumplen una función específica. En otras compañías, especialmente del sector industria, se pueden considerar dispositivos y mobiliario que son críticos para prestar servicios a los clientes. Es decir, que un CI no tiene por qué ser estrictamente un activo TI.

Después de estos criterios generales, es recomendable identificar tipologías de CI para facilitar los mecanismos de suministro de información detallada sobre estos CIs. Algunos ejemplos de tipologías o familias podrían ser:

A continuación se muestran algunos criterios de ejemplo para diferenciar CIs:

easyvista.com

8

•

Servidores

•

Infraestructura de Red

•

Unidades de Almacenamiento

•

Aplicaciones Corporativas

•

Sistemas Base

•

Entidades Lógicas

•

Business Services

•

IT Services

•

Instancias de BBDD

deloitte.es


C.3.4. ¿Qué atributos CI? Una vez que se tiene un criterio de selección de CIs, el siguiente paso sería identificar aquellos atributos de clase que sean fundamentales para lograr una mayor efectividad en la Gestión de la Configuración. Dentro de esta actividad, se recomienda establecer criterios de agrupación de atributos que sean comunes entre sí o que afecten de manera colectiva a un componente de servicio determinado. Algunas agrupaciones sugeridas serían: •

Identificación de configuración: Atributos para identificar de forma diferenciada cada CI

•

Control de configuración: Atributos necesarios para gestionar el ciclo de vida del CI

•

Parámetros de servicio: características diferenciales para que el CI preste el servicio requerido. Se suele asociar con cumplimiento de servicio

•

Parámetros operativos: características de ámbito funcional / técnico necesarias para el correcto funcionamiento del CI

•

Parámetros financieros: información clave para el ámbito administrativo del CI, tal y como puede ser la contabilidad de costes y control presupuestario

Como parte de esta actividad de categorización, es fundamental tener en cuenta las posibles fuentes de datos de cada uno de los atributos identificados anteriormente. Sin una estrategia clara de integración de datos de sistemas locales / externos con ITSM, es muy probable que el éxito del proyecto CMDB de una organización TI se vea seriamente comprometido incluso antes de su puesta en marcha.

9

EasyVista Deloitte


C.3.5. Interoperabilidad ITIL / ITAM / ITPM Uno de los factores que impactan negativamente en implantaciones de CMDB es el considerar esta herramienta como una simple base de datos estática con información técnica. Muchos proyectos fallidos han iniciado con una mentalidad de “todo cabe y debe ir” a la CMDB, sin determinar claramente los criterios de categorización de los CIs, de sus atributos, de sus relaciones entre sí y de sus relaciones con otros procesos de gestión TI. Algunos denominan a la CMDB como un “punto de encuentro” entre procesos de soporte al servicio.

En general, se habla de interoperabilidad ITIL – CMDB cuando un CI se puede relacionar con los siguientes procesos o elementos: •

•

IT Asset Management -

Contratos de diversa índole (mantenimiento, servicio, etc) asociados a CI

-

Licencias: Activos SW asociados a CI

-

Otros Activos: Activos tangibles necesarios para un CI determinado como parte de un “kit” de servicio

IT Service Management -

-

Incidentes: Degradaciones o Indisponibilidades de servicio vinculable a CI Solicitud: Peticiones de servicio sobre CIs •

-

Cambio: Modificaciones de CI existentes o Despliegue de nuevos CIs

-

Problema: Identificar causas de incidentes en CIs

-

Release: Proyecto de Entrega de Versión del CI (Release Record)

-

Evento: Eventos de monitorización de infraestructuras que impactan a un CI

-

Knowledge: Registros de conocimiento (KDB) vinculables a CI

-

Service Level: Niveles de servicio vinculados al CI

-

Continuity: Planes de Continuidad de Negocio asociados a un CI

easyvista.com

IT Project Management: Proyectos de TI que requieren uno o varios CIs

Se muestra un ejemplo que resume todas estas interacciones para un servicio Cloud:

Relaciones de un CI con otros procesos

10

deloitte.es


C.3.6. Ecosistemas TI en evolución En una estrategia de ITAM/CMDB, es importante tomar en cuenta el ecosistema TIC en el que se encuentra la organización de servicios TI. Dicho ecosistema es cada vez más complejo, como resultado de los constantes cambios organizativos en los diferentes sectores de actividad, de la creciente tendencia a externalizar servicios TI, de los cambios tecnológicos (Cloud Computing y Big Data, entre otros) y de las exigencias de los consumidores de servicios TI en todos sus ámbitos. En un entorno multisourcing en la nube, se deben considerar aspectos sobre la gestión de los proveedores externos de infraestructura y hosting, plataformas cliente, aspectos de seguridad y aspectos de continuidad de Negocio, entre otros.

En el diagrama se muestra una capa superior de servicios de valor añadido que utilizan la CMDB como herramienta base. En este modelo de CMDB se pueden incluir elementos internos y externos con sus respectivos niveles de detalle identificados durante la fase de diseño de la CMDB.

11

EasyVista Deloitte


C.3.7. Orquestación de Procesos

Algunas recomendaciones prácticas en este apartado serían:

Dentro de la capa backoffi ce, denominada anteriormente como Capa de Centro de Servicios TI , existe un factor crítico de éxito para su óptimo funcionamiento: la orquestación de procesos. La interoperabilidad de la CMDB con otros procesos de soporte al servicio depende en gran medida de la capacidad de la plataforma ITSM para crear y mantener work�ow para el control del ciclo de vida de estos procesos.

•

Un entorno gráfico para el diseño y mantenimiento de work�ow facilita enormemente la visualización del �ujo y sus posteriores optimizaciones

•

El motor de work�ow debería de dar soporte a la gestión de incidentes, peticiones de servicio, cambios, entregas y despliegues, proyectos, eventos y problemas

•

Facilidad para asociar el CI(s) afectado(s) al ticket para agilizar la entrega y control de configuración

Se destaca la definición de roles dentro del work�ow como factor diferencial que aporta mayor �exibilidad a la orquestación de procesos de soporte al servicio. El mejor escenario sería establecer roles CI que permitan canalizar acciones al grupo correspondiente al CI afectado, tal y como se muestra a continuación:

Uso de roles para agilizar orquestación de procesos

Siguiendo el ejemplo anterior, se puede configurar un work�ow de control de cambios cuya fase de aceptación de la entrega puede ser canalizada a un grupo de calidad TI, si el CI afectado es una aplicación corporativa, o a un grupo de operaciones TI, si el CI es un servidor Linux. Esta definición de roles como atributos CI permite la industrialización de procesos y facilita su evolución a futuro.

easyvista.com

12

deloitte.es


C.3.8. Soporte a Operaciones TI La gestión de operaciones TI requiere acceso rápido a información fiable sobre activos y CIs. La CMDB es una herramienta clave para agilizar las actividades de monitorización de infraestructuras, redes y rendimiento de aplicaciones, entre otros. Con la información almacenada en la CMDB se pueden preparar métricas, actualizar planes de capacidad, realizar seguimiento a eventos de red o de seguridad informática.

Una funcionalidad clave para la Gestión de Operaciones es el análisis de impacto en los diversos componentes de la cadena de valor de un servicio ante diversos tipos de situaciones, como por ejemplo: •

•

•

A manera de ejemplo, se pueden citar estas situaciones: •

Análisis de impacto al Negocio (BIA, por sus siglas en inglés) para dar soporte al proceso de Gestión de Disponibilidad propuesto por ITIL®

Paradas de servicio totales o parciales por motivo de incidentes en uno o varios componentes de un servicio (CIs)

•

Análisis de Costes de Servicio mediante una iteración Bottom-up (desde componentes infraestructura hacia servicios al negocio)

Paradas planificadas de servicio por motivo de una petición de cambio (RFC) que afecta a uno o varios CIs

•

Análisis de riesgos en diversos servicios mediante la identificación de posibles puntos “vulnerables” donde se puede revelar, almacenar o actualizar información sensible para el Negocio

Degradaciones de servicio reportadas por sistemas de monitorización de aplicaciones o infraestructura de red

Es aquí donde los CIs y las relaciones entre ellos juegan un papel fundamental. Este análisis de impacto se puede realizar mediante inspección visual, utilizando visores gráficos interactivos, o mediante la explotación del árbol de dependencias con la ayuda de herramientas de work�ow y reporting. El escenario ideal es que las plataformas de gestión ITSM incorporen herramientas nativas, como asistentes o vistas, que faciliten este análisis a los grupos de operaciones TI y soporte a usuarios. Además, estas capacidades de explotación de un árbol de dependencias entre componentes de servicio pueden dar soporte a otros tipos de análisis más allá del impacto de un incidente o cambio.

13

EasyVista Deloitte


C.3.9. Costes de Servicio TI Muchas de las implantaciones de herramientas para ITAM / CMDB se quedan en un plano meramente técnico. Se entrega un repositorio de activos y/o CI con información técnica vital para la Gestión de Operaciones y Servicios, pero con escasa información de carácter administrativo. Ante este escenario, no es de extrañar que la TI sea incapaz de mostrar, de una manera efectiva, el modelo de costes de provisión de servicios TI al Negocio. Los clientes no tienen forma de entender los elementos de coste de los servicios que ellos consumen y, por lo tanto, no pueden realizar previsiones presupuestarias sobre servicios tecnológicos contratados.

•

Repercutir costes a BU’s mediante mecanismos de “Charge-back” -

•

Informar a las BU’s de los costes mediante “Showback” -

La recomendación es comenzar con un catálogo de peticiones con servicios bien definidos donde se re�eje claramente una política de precios de provisión de los respectivos servicios (BASELINE) y, además, tarificación por tiempo de servicio (costes horarios-service value potential). Por otro lado, los activos y CI deberán de re�ejar costes unitarios de componentes suministrados, contratos de servicio y otros costes directos o indirectos para facilitar los cálculos de los costes totales de servicio.

Charge back de una parte o la totalidad de los costes

Show-back de Demanda y Coste

En el siguiente ejemplo se muestra un esquema de reparto ponderado de costes mensuales de servicio a diversos centros de coste por entidad organizativa

Algunos de los puntos a considerar en el ámbito financiero serían: •

Política de asignación de costes de servicios

•

Gestión de costes de servicios compartidos (CPD, Red, …)

•

Costes asociados a capacidad infrautilizada

•

Política de precios en demanda de infraestructuras

Reparto de Costes entre entidades organizativas

-

¿“Tarifa plana” anual?

-

¿Variación de precios según costes actuales?

easyvista.com

14

deloitte.es


D. Conclusiones Tres re�exiones importantes que resumen las claves del presente documento: 1. CMDB orientada a Servicios: Antes de iniciar una implementación de CMDB, se recomienda disponer de un catálogo de servicios consensuado con el Negocio que permita realizar el mapa de servicios y su respectiva demanda de infraestructura TI 2. Gestión Integral de Activos y Con�guración: La definición de una estrategia de gestión unificada de activos corporativos y configuración es un paso importante para mejorar el coste y entrega de servicios TI 3. ITAM y CMDB requieren más agilidad: Aunque estén en repositorios separados, los activos y los CI están interrelacionados y son parte integral de una amplia cadena de suministro de Servicios TI donde la agilidad y �exibilidad son fundamentales

Deloitte se refiere a Deloitte Touche Tohmatsu Limited, (private company limited by guarantee, de acuerdo con la legislación del Reino Unido) y a su red de firmas miembro, cada una de las cuales es una entidad independiente. En HYPERLINK “http://www.deloitte.com/about” www.deloitte.com/about se ofrece una descripción detallada de la estructura legal de Deloitte Touche Tohmatsu Limited y sus firmas miembro. Deloitte presta servicios de auditoría, asesoramiento fiscal y legal, consultoría y asesoramiento en transacciones corporativas a entidades que operan en un elevado número de sectores de actividad. Con una red de firmas miembro interconectadas a escala global que se extiende por más de 150 países, Deloitte aporta las mejores capacidades y un servicio de máxima calidad a sus clientes, ofreciéndoles la información que necesitan para abordar los complejos desafíos a los que se enfrentan. Deloitte cuenta en la región con más de 200.000 profesionales, que han asumido el compromiso de convertirse en modelo de excelencia. Esta publicación contiene exclusivamente información de carácter general, y Deloitte Touche Tohmatsu Limited, Deloitte Global Services Limited, Deloitte Global Services Holdings Limited, la Verein Deloitte To uche Tohmatsu, así como sus firmas miembro y las empresas asociadas de l as firmas mencionadas (conjuntamente, la “Red Deloitte”), no pretenden, por medio de esta publicación, prestar servicios o asesoramiento en materia contable, de negocios, financiera, de inversiones, legal, fiscal u otro tipo de servicio o asesoramiento profesional. Esta publicación no podrá sustituir a dicho asesoramiento o servicios profesionales, ni será utilizada como base para tomar decisiones o adoptar medidas que puedan afectar a su situación financiera o a su negocio. Antes de tomar cualquier decisión o adoptar cualquier medida que pueda afectar a su situación financiera o a su negocio, debe consultar con un asesor profesional cualificado. Ninguna entidad de la Red Deloitte se hace responsable de las pérdidas sufridas por cualquier persona que actúe basándose en esta publicación. © 2015 Deloitte, S.L.

15

EasyVista Deloitte

WhitePaper CMDB Con Deloitte

Recommend Documents