whitepaper cmdb con deloitte

8/20/2019 WhitePaper CMDB Con Deloitte

http://slidepdf.com/reader/full/whitepaper-cmdb-con-deloitte 1/15

CMDB orientada a Servicios

La clave de una Gestión de Activos TI

orientada al Negocio


http://slidepdf.com/reader/full/whitepaper-cmdb-con-deloitte 2/152easyvista.com deloitte.es

CMDB orientada a ServiciosLa clave de una Gestión de Activos TI


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 5C.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 15

Índice



EasyVistaDeloitte



A. IntroducciónHoy en día, diversas organizaciones apoyan su gestiónde activos TI y conguración en una herramienta base: laBase de Datos para gestión de Conguración (CMDB, enadelante). Desafortunadamente, esta herramienta ter-mina convirtiéndose, en ciertas ocasiones, en un “cajónde sastre” con elementos de bajo nivel (HW/SW) que noestá 100% alineada con el catálogo de servicios TI parael Negocio.

Se requiere un diseño de procesos de gestión de activosy conguración que esté más focalizado al Negocio. Para

ello, es de especial importancia iniciar esta fase de diseñocon un catálogo de servicios TI consensuado con los re-querimientos del Negocio. Esto aseguraría que la capa deinfraestructura TI esté mejor alineada con los servicios TIactivos, además de que facilitaría la trazabilidad de costesy parámetros de rendimiento que afecten a los servicios.

En este documento se destacarán algunas buenas prác-ticas relacionadas con la Gestión de Activos TI (ITAM enadelante) y CMDB para cumplir con los objetivos antes

planteados.

B. AntecedentesEn esta primera sección se realizará un repaso rápido dealgunos de los retos actuales detectados en la implanta-ción de ITAM y CMDB.

Haciendo un poco de repaso sobre la problemáticade varias organizaciones TI a la hora de implantar unaCMDB, se presentan a continuación algunos puntos co-mentados con frecuencia:

• La CMDB termina convirtiéndose en un cajón de ele-mentos poco organizados y a veces sin categorizarcorrectamente

• En numerosas ocasiones, se registra en ese reposi-

torio de todo, con lo cual se hace innecesariamentecomplejo

• No se identican los atributos que aportan valor

• No se implantan procesos ecientes que faciliten elmantenimiento de la CMDB, muchas veces no hayuna gestión de cambios

• Los mecanismos de reporting, si existen, están muy

orientados a la operación de bajo nivel y no aportanmétricas de consumo y coste de servicios, que le in-teresarían más al Negocio

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

• Este proceso es inexistente en muchas organizacio-nes TI o quizá está diluido en diferentes personas

• No se detectan casos en los que el foco de esta ges-

tión de activos TI esté limitada a un inventario de ca-rácter técnico, alimentado por herramientas de ges-tión de sistemas

• Las fuentes de datos son diversas y no están integra-das, se dispone de herramientas técnicas, ERP coninformación administrativa, etc

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

¿Y qué ocurre con las iniciativas relacionadas con ITAM/ CMDB? Siempre se tiene una visión inicial, unas ambi-ciones. Por ejemplo, se quiere adoptar ITIL, implantarITAM de clase mundial, una CMDB potente y obtenercerticaciones ISOxxxxx. Pero la realidad es que muchasorganizaciones de TI se encuentran con que no hay pre-supuesto, especialmente en estos últimos tiempos; nose dispone de los recursos necesarios, lo que se quierehacer no está alineado con el Negocio y, por tanto, no

obtendrá la aprobación del Top Management. Al nal,dichas organizaciones de TI se quedan en un plano másaustero del que originalmente se había concebido.





C.1. Alcance ITAMDentro 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 ySW, eloperacional que es el control de inventario, elcontractual que es la gestión de contratos y licenciasde SW; y nalmente el nanciero , donde se lleva elcontrolling económico de los activos.

En la siguiente tabla se muestran estos cuatro aspectos, junto con algunos de sus procesos destacados:

El aspecto operacional de ITAM, como es evidente, esmuy amplio. Incluye no solo control de inventario sinotambién contempla aspectos de aprovisionamiento,almacén, proveedores, etc. Muchos de estos aspectos yaestán de cierta forma cubiertos en un ERP, pero puedenestar bajo el control de TI en algunas organizaciones.A continuación se muestran algunos de sus procesosclave:

Aspectos Clave en ITAM

ITAM - Operacional

C. Buenas Prácticas ITAM / CMDBEn esta sección se presentarán algunas pautas importantes a tomar en cuenta durante la concepción, diseño e implementa-ción de procesos de gestión de activos y conguración.



EasyVistaDeloitte



Una iniciativa que podría ser estratégica para diversasorganizaciones TI es la implementación de una plata-forma de Servicios TI para todas las entidades de suNegocio. En ella se incluiría el catálogo de servicios TI yservicios departamentales, un IT store para descarga deherramientas de productividad y un panel de mis ser-vicios, mis activos, mis contratos , base de conocimientoy dashboard(s) de servicios. Muchos de estos escapa-rates podrían ser perfectamente alimentados por unaCMDB y por una base de Activos corporativos. Esta pla-taforma constituiría la capa de presentación de los ser-vicios al Negocio, tal y como se muestra en el siguienteejemplo:

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

Dashboard para Servicio TI - Email

Capa de Servicios TI para el Negocio

Una de las contribuciones principales de la CMDB y labase de activos TI serían las métricas sobre diferentesservicios a publicar en los dashboards de la capa de ser-vicios TI mencionada anteriormente.

Se pueden focalizar algunos de estos dashboards a de-terminados departamentos o unidades de negocio dela compañía. En el ejemplo se muestra KPIs del serviciocorreo electrónico gestionado en CMDB.

En términos generales, esta plataforma de servicios TIrepresenta una gran oportunidad para que las organi-zaciones TI:

• Promocionen el catálogo de servicios TI a sus res-pectivas audiencias

• Demuestren valor al negocio mediante la presenta-ción de nuevas iniciativas

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





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

Capa de Servicios TI para el Negocio

1

Managing Demand for IT Infrastructure - McKinsey & Co. Business Technology Offi ce April 2014

C.3.1. Arquitectura CMDB

Como primer punto en este capítulo, se tratará eltema de arquitectura de una de las herramientasmás importantes en la gestión de servicios: la CMDB.Se recomienda una visión Top-Down , desde el Ne-gocio hacia las infraestructuras TI, para diseñar unaCMDB. Siguiendo esta losofía, es evidente que elpunto de partida lógico es el catálogo de serviciosTI. En esta fase se identicarían las diversas capasdel mapa de servicios como los Business Services, IT

services, Aplicaciones, Servidores e InfraestructuraRed. Por otro lado, el recorrido inverso,Bottom-Up ,se realizaría para calcular los costes asociados a losServicios. Con estos dos enfoques de diseño, el ob- jetivo primordial es agilizar la denición de la arqui-tectura de la CMDB, al mismo tiempo que se tomanen cuenta los componentes nancieros asociados ala entrega de servicios.

Unos de los temas pendientes en muchas implantaciones de CMDB es elPrecio del Servicio . Para ello, lo primero es identi-

car los costes unitarios por componente y almacenarlos en la CMDB. Posteriormente, se puede seguir un enfoque Bottom-uppara calcular el coste de un servicio determinado y presentarlo a los usuarios nales mediante el catálogo de peticiones deservicio. 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 decostes y en la mejora de la entrega de servicios mediante una mejor gestión de la demanda. En este estudio se mencionandiversos 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, datossobre coste y consumo a los clientes implicados.



EasyVistaDeloitte



C.3.2. ¿Activo TI o CI?

Aunque ITIL® proponga una gestión de activos de servi-

cio y conguración como un proceso “unicado”, es im-portante reconocer las diferencias entre ITAM y CMDB.Según el Libro ITIL® Service Transition, la Gestión de Acti-vos se centra en el ciclo de vida de los activos de servicio,mientras que la Gestión de la Conguración se centra enla identicación, control y mantenimiento de compo-nentes de servicio. Algunas organizaciones TI conside-ran ITAM como “la gestión técnica y administrativa” de

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

Dependiendo del Negocio de cada compañía, no todoactivo TI es necesariamente un CI. A manera de ejemplo,para una empresa de Outsourcing, el mobiliario están-dar de ocina se consideraría un activo pero no un CI.Algunos elementos, como los servidores o los compo-nentes de red, se consideran activos de la compañía yademás CI por ser componentes de servicio en CMDB.

En el siguiente gráco 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.

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





C.3.3. ¿Qué es un CI?

Siguiendo con las re exiones de la sección anterior, esimportante que la organización de TI establezca crite-rios claros para determinar qué componentes gestionarcomo CIs en una CMDB. Una regla que algunas organi-zaciones aplican es la de considerar como CI todo aquelelemento que sea hasta cierto punto “crítico” para elbuen funcionamiento de un servicio TI y que pueda es-tar sujeto al control de cambios y versiones. No solo setrata de considerar al elemento de forma aislada, tam-bién es importante entender sus interacciones con otros

elementos del mapa de servicios y así poder aplicar di-versos tipos de análisis de impacto sobre el servicio afec-tado por dichos elementos.

En numerosos casos, los elementos de una CMDB suelenser componentes tangibles de un Centro de Datos, comoServidores y Electrónica de Red, o intangibles, como losclusters de HW o cualquier agrupación lógica de CI quecumplen una función especíca. En otras compañías, es-pecialmente del sector industria, se pueden considerar

dispositivos y mobiliario que son críticos para prestarservicios a los clientes. Es decir, que un CI no tiene porqué ser estrictamente un activo TI.

A continuación se muestran algunos criterios de ejem-plo para diferenciar CIs:

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

• Servidores

• Infraestructura de Red

• Unidades de Almacenamiento

• Aplicaciones Corporativas

• Sistemas Base

• Entidades Lógicas

• Business Services

• IT Services

• Instancias de BBDD



EasyVistaDeloitte



C.3.4. ¿Qué atributos CI?

Una vez que se tiene un criterio de selección de CIs, el siguiente paso sería identicar aquellos atributos de clase que seanfundamentales para lograr una mayor efectividad en la Gestión de la Conguración. Dentro de esta actividad, se recomiendaestablecer criterios de agrupación de atributos que sean comunes entre sí o que afecten de manera colectiva a un compo-nente de servicio determinado. Algunas agrupaciones sugeridas serían:

• Identicación de conguración: Atributos para iden-ticar de forma diferenciada cada CI

• Control de conguración: Atributos necesarios paragestionar el ciclo de vida del CI

• Parámetros de servicio: características diferencialespara que el CI preste el servicio requerido. Se sueleasociar con cumplimiento de servicio

• Parámetros operativos: características de ámbitofuncional / técnico necesarias para el correcto fun-cionamiento del CI

• Parámetros nancieros: información clave para el

ámbito administrativo del CI, tal y como puede ser lacontabilidad de costes y control presupuestario

Como parte de esta actividad de categorización, es fun-damental tener en cuenta las posibles fuentes de datosde cada uno de los atributos identicados anteriormen-te. Sin una estrategia clara de integración de datos desistemas locales / externos con ITSM, es muy probableque el éxito del proyecto CMDB de una organización TIse vea seriamente comprometido incluso antes de supuesta en marcha.





C.3.5. Interoperabilidad ITIL / ITAM / ITPM

Uno de los factores que impactan negativamente en implantaciones de CMDB es el considerar esta herramienta como unasimple base de datos estática con información técnica. Muchos proyectos fallidos han iniciado con una mentalidad de “todocabe y debe ir” a la CMDB, sin determinar claramente los criterios de categorización de los CIs, de sus atributos, de sus re-laciones entre sí y de sus relaciones con otros procesos de gestión TI. Algunos denominan a la CMDB como un “punto deencuentro” entre procesos de soporte al servicio.

En general, se habla de interoperabilidad ITIL – CMDBcuando un CI se puede relacionar con los siguientes pro-

cesos o elementos:

• IT Service Management

- Incidentes: Degradaciones o Indisponibilidadesde servicio vinculable a CI

- Solicitud: Peticiones de servicio sobre CIs

- Cambio: Modicaciones de CI existentes o Des-

pliegue de nuevos CIs

- Problema: Identicar causas de incidentes en CIs

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

- Evento: Eventos de monitorización de infraes-tructuras que impactan a un CI

- Knowledge: Registros de conocimiento (KDB) vin-culables a CI

- Service Level: Niveles de servicio vinculados al CI

- Continuity: Planes de Continuidad de Negocioasociados a un CI Relaciones de un CI con otros procesos

• IT Asset Management

- Contratos de diversa índole (mantenimiento, ser-vicio, etc) asociados a CI

- Licencias: Activos SW asociados a CI

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

• IT Project Management: Proyectos de TI que requie-ren uno o varios CIs

Se muestra un ejemplo que resume todas estas interac-ciones para un servicio Cloud:



EasyVistaDeloitte



C.3.6. Ecosistemas TI en evolución

En una estrategia de ITAM/CMDB, es importante tomaren cuenta el ecosistema TIC en el que se encuentra laorganización de servicios TI. Dicho ecosistema es cadavez más complejo, como resultado de los constantescambios organizativos en los diferentes sectores de ac-tividad, de la creciente tendencia a externalizar serviciosTI, de los cambios tecnológicos (Cloud Computing y BigData, entre otros) y de las exigencias de los consumido-res de servicios TI en todos sus ámbitos.

En un entorno multisourcing en la nube, se deben con-siderar aspectos sobre la gestión de los proveedores ex-ternos de infraestructura y hosting, plataformas cliente,aspectos de seguridad y aspectos de continuidad de Ne-gocio, 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 identicadosdurante la fase de diseño de la CMDB.





Uso de roles para agilizar orquestación de procesos

C.3.7. Orquestación de Procesos

Dentro de la capa backoffi ce, denominada anterior-mente como Capa de Centro de Servicios TI , existe unfactor crítico de éxito para su óptimo funcionamiento:la orquestación de procesos. La interoperabilidad dela CMDB con otros procesos de soporte al servicio de-pende en gran medida de la capacidad de la plataformaITSM para crear y mantener work ow para el control delciclo de vida de estos procesos.

Algunas recomendaciones prácticas en este apartadoserían:

• Un entorno gráco para el diseño y mantenimientode work ow facilita enormemente la visualizacióndel ujo y sus posteriores optimizaciones

• El motor de work ow debería de dar soporte a la ges-tión de incidentes, peticiones de servicio, cambios,entregas y despliegues, proyectos, eventos y proble-mas

• Facilidad para asociar el CI(s) afectado(s) al ticketpara agilizar la entrega y control de conguración

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

Siguiendo el ejemplo anterior, se puede congurar un work ow de control de cambios cuya fase de aceptación de la entregapuede ser canalizada a un grupo de calidad TI, si el CI afectado es una aplicación corporativa, o a un grupo de operacionesTI, si el CI es un servidor Linux. Esta denición de roles como atributos CI permite la industrialización de procesos y facilitasu evolución a futuro.



EasyVistaDeloitte



C.3.8. Soporte a Operaciones TI

La gestión de operaciones TI requiere acceso rápido ainformación able sobre activos y CIs. La CMDB es unaherramienta clave para agilizar las actividades de moni-torización de infraestructuras, redes y rendimiento deaplicaciones, entre otros. Con la información almacena-da en la CMDB se pueden preparar métricas, actualizarplanes de capacidad, realizar seguimiento a eventos dered o de seguridad informática.

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

• Paradas de servicio totales o parciales por motivo deincidentes en uno o varios componentes de un servi-cio (CIs)

• Paradas planicadas de servicio por motivo de unapetición de cambio (RFC) que afecta a uno o variosCIs

• Degradaciones de servicio reportadas por sistemasde monitorización de aplicaciones o infraestructurade red

Es aquí donde los CIs y las relaciones entre ellos juegan

un papel fundamental. Este análisis de impacto se pue-de realizar mediante inspección visual, utilizando visoresgrácos interactivos, o mediante la explotación del árbolde dependencias con la ayuda de herramientas de wor-k ow y reporting. El escenario ideal es que las platafor-mas de gestión ITSM incorporen herramientas nativas,como asistentes o vistas, que faciliten este análisis a losgrupos de operaciones TI y soporte a usuarios. Además,estas capacidades de explotación de un árbol de depen-dencias entre componentes de servicio pueden dar so-

porte a otros tipos de análisis más allá del impacto de unincidente o cambio.

A manera de ejemplo, se pueden citar estas situaciones:

• Análisis de impacto al Negocio (BIA, por sus siglas eninglés) para dar soporte al proceso de Gestión de Dis-ponibilidad propuesto por ITIL®

• Análisis de Costes de Servicio mediante una iteraciónBottom-up (desde componentes infraestructura ha-

cia servicios al negocio)

• Análisis de riesgos en diversos servicios mediante laidenticación de posibles puntos “vulnerables” don-de se puede revelar, almacenar o actualizar informa-ción sensible para el Negocio





C.3.9. Costes de Servicio TI

Muchas de las implantaciones de herramientas paraITAM / CMDB se quedan en un plano meramente téc-nico. Se entrega un repositorio de activos y/o CI con in-formación técnica vital para la Gestión de Operacionesy Servicios, pero con escasa información de carácter ad-ministrativo. Ante este escenario, no es de extrañar quela TI sea incapaz de mostrar, de una manera efectiva, elmodelo de costes de provisión de servicios TI al Negocio.Los clientes no tienen forma de entender los elementosde coste de los servicios que ellos consumen y, por lo

tanto, no pueden realizar previsiones presupuestariassobre servicios tecnológicos contratados.

La recomendación es comenzar con un catálogo de pe-ticiones con servicios bien denidos donde se re ejeclaramente una política de precios de provisión de losrespectivos servicios (BASELINE) y, además, taricaciónpor tiempo de servicio (costes horarios-service value po-tential). Por otro lado, los activos y CI deberán de re ejarcostes unitarios de componentes suministrados, contra-

tos de servicio y otros costes directos o indirectos parafacilitar los cálculos de los costes totales de servicio.

Algunos de los puntos a considerar en el ámbito nan-ciero 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

- ¿“Tarifa plana” anual?

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

Reparto de Costes entre entidades organizativas

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

- Charge back de una parte o la totalidad de loscostes

• Informar a las BU’s de los costes mediante “Show-back”

- Show-back de Demanda y Coste

En el siguiente ejemplo se muestra un esquema de re-parto ponderado de costes mensuales de servicio a di-versos centros de coste por entidad organizativa



EasyVista



Deloitte se reere a Deloitte Touche Tohmatsu Limited, (private company limited by guarantee, de acuerdo con la legislación del Reino Unido) y a su red de rmasmiembro, cada una de las cuales es una entidad independiente. En HYPERLINK “http://www.deloitte.com/about” www.deloitte.com/about se ofrece una descripcióndetallada de la estructura legal de Deloitte Touche Tohmatsu Limited y sus rmas miembro.

Deloitte presta servicios de auditoría, asesoramiento scal y legal, consultoría y asesoramiento en transacciones corporativas a entidades que operan en un elevadonúmero de sectores de actividad. Con una red de rmas miembro interconectadas a escala global que se extiende por más de 150 países, Deloitte aporta las mejorescapacidades 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 GlobalServices Holdings Limited, la Verein Deloitte Touche Tohmatsu, así como sus rmas miembro y las empresas asociadas de las rmas mencionadas (conjuntamente,la “Red Deloitte”), no pretenden, por medio de esta publicación, prestar servicios o asesoramiento en materia contable, de negocios, nanciera, de inversiones, legal,scal u otro tipo de servicio o asesoramiento profesional. Esta publicación no podrá sustituir a dicho asesoramiento o servicios profesionales, ni será utilizada comobase para tomar decisiones o adoptar medidas que puedan afectar a su situación nanciera o a su negocio. Antes de tomar cualquier decisión o adoptar cualquiermedida que pueda afectar a su situación nanciera o a su negocio, debe consultar con un asesor profesional cualicado. Ninguna entidad de la Red Deloitte se haceresponsable de las pérdidas sufridas por cualquier persona que actúe basándose en esta publicación.

© 2015 Deloitte, S.L.

D. ConclusionesTres re exiones importantes que resumen las claves delpresente documento:

1. CMDB orientada a Servicios: Antes de iniciar unaimplementación de CMDB, se recomienda disponerde un catálogo de servicios consensuado con el Ne-gocio que permita realizar el mapa de servicios y surespectiva demanda de infraestructura TI

2. Gestión Integral de Activos y Con guración: La de-nición de una estrategia de gestión unicada de ac-tivos corporativos y conguración es un paso impor-tante para mejorar el coste y entrega de servicios TI

3. ITAM y CMDB requieren más agilidad: Aunque es-tén en repositorios separados, los activos y los CIestán interrelacionados y son parte integral de unaamplia cadena de suministro de Servicios TI donde la

agilidad y exibilidad son fundamentales

whitepaper cmdb con deloitte

Documents