1. La elección de cuántos CI de cada tipo y cuáles, es parte del Span
2. Se utiliza para indicar que grupos específicos van a ser rastreados en cada objeto definido en el alcance. (De una vasta lista de documentos, rastrear los más importantes)
3. Expandirse poco a poco
3.1. El alcance se debe gestionar como un proyecto, por etapas pequeñas para garantizar futuros resultados
4. Es la definición de límites sobre los CI que van a pertenecer a la CMDB
5. SIEMPRE se debe agregar aquella información que genere valor al proceso de gestión de configuración.
6. Alcance
6.1. Definir el alcance es tan sencillo como decidir que tipos de CI van a ser incluidos y qué relaciones serán seguidas
6.2. Indica los potenciales contenidos del CMDB, las categorías de objetos y las relaciones que se harán entre las relaciones
6.2.1. Hardware
6.3. Qué tipos de CI van a ser rastreados, NO cuales
6.4. Le brinda a la CMDB la forma
6.5. ¿Qué categorías se deben incluir?
6.5.1. Software
6.5.2. Servidores
6.5.3. Licencias
6.5.4. Documentación especifica de sistemas
6.6. Criterios usados para determinar el alcance
6.6.1. Empezar simple
6.6.1.1. Incluir aquellas categorías comunes que sean fáciles de mantener y rápidas de comprender
6.6.1.2. Hay que tener en cuenta que cada aplicación incluida, implica una serie de relaciones que deben ser creadas
6.6.2. Considerar el costo
6.6.2.1. Se debe determinar todo lo que esté dentro del alcance de ser gestionado y que debe ser dejado por fuera
6.6.3. Victorias fáciles
6.6.3.1. Los esfuerzos se deben concentrar en aquellos items que pueden ser rastreados con plena confianza y dejar aquellos que por alguna razón no pueden ser gestionados o no hay seguridad
6.6.3.2. Lo buscado es no incurrir en insertar datos que luego pueden convertirse en una bola de nieve
6.6.4. Mirar más allá
6.6.4.1. No es solo contemplar los CI actuales, sino más bien apoyar las miras a largo plazo que posee la organización
6.6.5. Reducir riesgos
6.6.5.1. Los fallos principales en la CMDB se dan por errores en la recopilación de datos. De esta premisa se deriva la necesidad de abordar cualquier cambio por medio de la gestión de cambios general de TI
7. Span
7.1. Criterios para definirlo
7.1.1. Span puede definir proyectos
7.1.1.1. Cada span se puede tratar como un proyecto para evitar riesgos en el CMDB
7.1.2. Las herramientas dictan el Span
7.1.2.1. Muchas veces la captura de datos que efectúan algunas aplicaciones especializadas, poseen fuertes (en SO, Server o Red), los cuales deben ser explotados para definir el Span al inicio
7.1.3. Seguir al líder
7.1.3.1. Span es quien define cuanta cantidad de datos necesita la organización que sea recabada, auditada y reportada en los CI
8. Relaciones entre CI
8.1. Buscan trazar cómo los CI se encuentran relacionados
9. Granularidad
9.1. Qué se va a conocer acerca de cada ítem de configuración o relación
9.1.1. Mientras el alcance define la amplitud, la granularidad define la profundidad
9.2. Fija o variable
9.2.1. Fija
9.2.1.1. Busca que bajo la categoría empleada, se establezcan los tipos de dato que van a ser recabados de dicha categoría.
9.2.1.2. Se busca simplificar el proceso y reducir los errores que pueden ser introducidos a la CMDB
9.2.1.3. Dada la búsqueda de estandarizar los atributos, para aquellos que no calzan y son muy específicos del CI, se utilizan variables para igual, documentar adecuadamente la información que el negocio cree pertinente y debe mantener almacenada en la CMDB
9.3. Variable
9.3.1. Son aquellos casos especiales
9.3.2. Cuando se hablan de componentes (Hardware, Software, Equipo activo de red) se globalizan los atributos y comparten características, pero cuando la CMDB debe ser cargada con documentos de procesos, políticas y hasta roles y responsabilidades, es donde esta agrupación de atributos no es factible y debe ser abordada de distinta forma
9.3.3. Es mejor mantener una granularidad variable dada la personalización de cada CI, pero su desventaja es el costo de mantener esta información actualizada, utilizable y consistente con cambios que se den en las operaciones
9.4. Criterios usados para definir la granularidad
9.4.1. Recabar lo esencial
9.4.1.1. Se debe tener completa certeza de mantener lo necesario y útil de cada CI, por ejemplo un ID, nombre, status, dueño, ubicación, categoría.
9.4.1.2. Lo buscado en este punto es determinar y almacenar aquella información que es crítica para la organización y sus objetivos
9.4.2. Entender la fuente
9.4.2.1. Si se tienen recursos con información de algunos CI, es un buen insumo para comenzar el desarrollo de la CMDB, siempre y cuando dichos datos se encuentren actualizados
9.4.2.2. Si no se puede tener claro como se va a obtener algún dato, lo mejor es dejarlo fuera del plan, se va a convertir en una posible amenaza a la integridad de aquellos datos que si se encuentran verificados.
9.4.3. Conocer las necesidades de la organización
9.4.3.1. La granularidad debe ser construida en función de las necesidades que posea la organización
9.4.3.2. Identificar aquellas lecciones aprendidas en proyectos pasados, que tal vez con un mejor conocimiento de capacidades técnicas organizacionales, pudieron salir mejor. Esto colabora también en la definición del detalle por cada atributo del CI
9.4.4. Balancear el conocimiento y el esfuerzo
9.4.4.1. Nunca se debe mantener dentro de la CMDB un control más costoso que lo que el CI costó en su momento.
9.4.4.2. Aunque hay procesos y CIs que dada su importancia, deben ser gestionados a como de lugar, de ahí la necesidad de discernir entre lo que podría ser bueno tener y lo imprescindible
9.4.5. Peso muerto
9.4.5.1. Además de ser una carga para la CMDB, mantener datos implica costo y tiempo, además de una posible vulnerabilidad en los datos que si cumplen una función y son necesarios