DAMA DMBOK v2 (394-628) .En - Es

Machine Translated by Google
390 • DMBOK2
Puesta en escena de datos Datos Acceso a los datos

Área Presentación Herramientas
Área
Operacional
Fuente
Sistemas
SERVICIOS:
Limpiar Combinar
Estandarizar
Extracto Carga Acceso AD HOC
Conformar Mercado de datos #1
CONSULTAS
Dimensiones
Dimens
confor
AUTOBÚS
DW Extracto
Extracto
SIN CONSULTAS
ALMACÉN DE DATOS:
Archivos planos
Tablas relacionales
Conjuntos de datos XML
Carga
Carga
Mercado de datos #2
Acceso
Acceso
INFORME
ESCRITORES
ANALÍTICO
APLICACIONES
MODELOS:
PROCESAMIENTO:
Mercado de datos #N Pronósticos Scoring
Extracto Carga Acceso
Clasificación
Minería de datos
Secuenciación
Figura 81 Almacén de datos de Kimball Piezas de ajedrez67
La Figura 82 también muestra aspectos del ciclo de vida de los datos. Los datos se mueven desde los sistemas de origen a un área
de preparación donde se pueden limpiar y enriquecer a medida que se integran y almacenan en el DW y/o un ODS. Desde el DW se
puede acceder a través de marts o cubos y se puede utilizar para varios tipos de informes. Big Data pasa por un proceso similar,
pero con una diferencia significativa: mientras que la mayoría de los almacenes integran los datos antes de colocarlos en las tablas,
las soluciones de Big Data ingieren los datos antes de integrarlos. Big Data BI puede incluir análisis predictivos y minería de datos,
así como formas más tradicionales de informes. (Consulte el Capítulo 14.)
1.3.7.1 Sistemas fuente
Los sistemas de origen, en el lado izquierdo de la Figura 82, incluyen los sistemas operativos y los datos externos que se incorporarán
al entorno DW/BI. Por lo general, estos incluyen sistemas operativos como CRM, contabilidad y aplicaciones de recursos humanos,
así como sistemas operativos que difieren según la industria. También se pueden incluir datos de proveedores y fuentes externas, al
igual que DaaS, contenido web y cualquier resultado de cómputo de Big Data.
1.3.7.2 Integración de datos
La integración de datos cubre Extraer, Transformar y Cargar (ETL), virtualización de datos y otras técnicas para obtener datos en una
forma y ubicación comunes. En un entorno SOA, las capas de servicios de datos forman parte de este componente. En la Figura 82,
todas las flechas representan procesos de integración de datos. (Consulte el Capítulo 8.)
67 Adaptado de Kimball y Ross (2002). Usado con permiso.
ALMACÉN DE DATOS E INTELIGENCIA EMPRESARIAL • 391
Arquitectura Conceptual DW/BI y Big Data
Fuentes Almacén de datos BI
Solicitud Dominio de datos
Operacional Intervención de calidad de datos
Informes Enriquecimiento y Aumento
Dependiente
Informes operativos
Área de ensayo
Evalu
Intera
Apre
Pred
Com
Infor DaaS
Operacional
Sistemas
Grandes datos
Resultados
MDM
Limpio
Integrar
Enriquecer
Estandarizar
Referencia &
Datos maestros
Conformado
Dimensiones
Almacén Central
Orientado al sujeto
No volátil
Variante de tiempo
Atómico
Información histórica
Almacenes de datos
SAO
Mercado de datos
Cubos
y análisis
Geoespacial y
Análisis demográfico
Actuación
Gestión
Visualización de datos
Minería de datos y texto
no estructurado
Analítica
Grandes datos
Email
Multimedia
© DATALEADERS.ORG
Sensores Análisis predictivo
Evaluar
IoT
Ingerir Lago de datos Integrar Explorar
Sociel Network Modelo
Web DaaS DW Aprendizaje automático
Figura 82 Arquitectura Conceptual DW/BI y Big Data
1.3.7.3 Áreas de almacenamiento de datos
El almacén dispone de un conjunto de zonas de almacenaje:
• Área de ensayo: un área de ensayo es un almacén de datos intermedio entre una fuente de datos original y el
repositorio centralizado de datos. Los datos se organizan para que se puedan transformar, integrar y preparar para cargarlos en el almacén.
• Dimensiones compatibles con los datos maestros y de referencia: los datos maestros y de referencia se pueden almacenar en
depósitos separados. El almacén de datos alimenta nuevos datos maestros y se alimenta de contenidos de dimensión conformados de los repositorios
separados.
• Almacén central: una vez transformados y preparados, los datos de DW generalmente persisten en el almacén central o
capa atómica. Esta capa mantiene todos los datos atómicos históricos, así como la última instancia de la ejecución por lotes. La estructura de datos
de esta área se desarrolla e influye en función de las necesidades de rendimiento y los patrones de uso. Se ponen en práctica varios elementos de
diseño:
o La relación entre la clave comercial y las claves sustitutas para el rendimiento o Creación de índices y claves externas
para admitir dimensiones o Técnicas de captura de datos modificados (CDC) que se utilizan para detectar, mantener y
almacenar el historial
392 • DMBOK2
• Almacén de datos operativos (ODS): El ODS es una versión de un almacén persistente central que admite latencias más bajas y,
por lo tanto, un uso operativo. Dado que el ODS contiene una ventana de tiempo de datos y no el historial, se puede actualizar
mucho más rápido que un almacén. A veces, los flujos en tiempo real se capturan a intervalos predefinidos en el ODS para
permitir informes y análisis integrados. Con el tiempo, con la frecuencia cada vez mayor de las actualizaciones impulsadas por
las necesidades comerciales y la creciente tecnología y técnicas para integrar datos en tiempo real en el DW, muchas
instalaciones han fusionado su ODS en la arquitectura DW o Data Mart existente.
• Data marts: un data mart es un tipo de almacén de datos que a menudo se usa para admitir capas de presentación de los datos.
entorno de almacén. También se utiliza para presentar un subconjunto departamental o funcional del DW para informes
integrados, consultas y análisis de información histórica. El data mart está orientado a un área temática específica, un solo
departamento o un solo proceso comercial. También puede formar la base de un almacén virtualizado donde los mercados
combinados constituyen la entidad de almacén resultante. Los procesos de integración de datos refrescarán, actualizarán o
ampliarán los contenidos de los diversos mercados de la capa de persistencia.
• Cubos: tres enfoques de implementación clásicos admiten el procesamiento analítico en línea (OLAP). Su
los nombres se relacionan con los tipos de bases de datos subyacentes, como relacional, multidimensional e híbrida.
1.3.8 Tipos de procesamiento de carga
El almacenamiento de datos implica dos tipos principales de procesos de integración de datos: cargas históricas y actualizaciones continuas.
Los datos históricos generalmente se cargan solo una vez, o unas pocas veces mientras se resuelven los problemas de datos, y nunca más.
Las actualizaciones continuas se programan y ejecutan constantemente para mantener actualizados los datos en el almacén.
1.3.8.1 Datos históricos
Una ventaja de un almacén de datos es que puede capturar un historial detallado de los datos que almacena. Existen diferentes métodos
para capturar este detalle. Una organización que quiera capturar la historia debe diseñar en función de los requisitos. Ser capaz de reproducir
instantáneas de un punto en el tiempo requiere un enfoque diferente al de simplemente presentar el estado actual.
El almacén de datos de Inmon sugiere que todos los datos se almacenen en una única capa de almacén de datos. Esta capa almacenará
datos de niveles atómicos limpios, estandarizados y gobernados. Una capa común de integración y transformación facilita la reutilización en
todas las implementaciones de entrega. Se requiere un modelo de datos empresariales para el éxito. Una vez validada, esta tienda única
está disponible para diferentes consumidores de datos a través de un data mart estructurado en estrella.
El almacén de datos de Kimball sugiere que el almacén de datos se compone de una combinación de data marts departamentales que
contienen datos limpios, estandarizados y gobernados. Los data marts almacenarán el historial a nivel atómico. Las dimensiones conformadas
y los hechos conformados brindarán información de nivel empresarial.
Otro enfoque, la Bóveda de datos, también limpia y estandariza como parte del proceso de preparación. La historia se almacena en una
estructura atómica normalizada, se definen claves sustitutas, primarias y alternativas dimensionales. Asegurarse de que la relación
comercial y clave sustituta permanezca intacta se convierte en el rol secundario de la bóveda: este es el historial del data mart. Los
hechos persistieron aquí como estructuras atómicas. Luego, la bóveda está disponible para una variedad de consumidores de datos a
través de data marts. Al retener el historial dentro de la bóveda, es posible volver a cargar datos cuando los incrementos posteriores
introducen cambios de grano. Es posible virtualizar la capa de presentación, lo que facilita la entrega incremental ágil y el desarrollo
colaborativo con la comunidad empresarial. Un proceso de materialización final puede implementar un data mart en estrella más
tradicional para el consumo del usuario final de producción.
1.3.8.2 Captura de datos de cambios por lotes
Los almacenes de datos a menudo se cargan a diario y reciben servicio por una ventana de lote nocturna. El proceso de carga puede
acomodar una variedad de detección de cambios, ya que cada sistema de origen puede requerir diferentes técnicas de captura de
cambios.
Las técnicas de registro de bases de datos son candidatas probables para aplicaciones desarrolladas internamente, ya que es poco probable
que las aplicaciones adquiridas por proveedores toleren modificaciones con disparadores o sobrecarga adicional. Las cargas de tablas de
registro o con marca de tiempo son las más comunes. Las cargas completas ocurren cuando se trata de sistemas heredados construidos sin
capacidades nativas de marca de tiempo (sí, hay aplicaciones sin bases de datos) o cuando se aplican ciertas condiciones de recuperación
por lotes.
La Tabla 28 resume la diferencia entre las técnicas de captura de datos modificados, incluidas su complejidad y velocidad relativas. La
columna de superposición identifica si puede haber duplicación de datos entre los cambios del sistema de origen y el entorno de destino.
Cuando Superposición es 'Sí', es posible que estos datos de cambio ya estén presentes. Cuando el indicador Eliminar se establece en
'Sí', el Método de cambio de datos rastreará las eliminaciones que se hayan producido en el sistema de origen, lo que resulta útil para
las dimensiones que caducan y que ya no se utilizan. Cuando el sistema de origen no rastrea las eliminaciones, se requieren esfuerzos
adicionales para determinar cuándo ocurren. (Consulte el Capítulo 8.)
Tabla 28 Comparación de técnicas de CDC
Método Complejidad de los requisitos del sistema de origen Hecho Dimensión Eliminaciones superpuestas
Carga Carga
Marca Los cambios en el sistema de origen
de tiempo se marcan con la fecha y la hora del Bajo Rápido Rápido Sí No
Carga delta sistema.
Tabla de registro Los cambios del sistema de origen se
Carga delta capturan y almacenan en tablas de registro. Medio Nominal Nominal Sí Sí
Base de datos La base de datos captura los cambios en el
Transacción registro de transacciones. Alto Nominal Nominal No Sí
Registro
Mensaje Los cambios en el sistema de
Delta origen se publican como mensajes Extremo Lento Lento No Sí
[casi] en tiempo real
Carga completa Sin indicador de cambio, tablas
extraídas en su totalidad y comparadas Simple Lento Nominal Sí Sí
para identificar el cambio
394 • DMBOK2
1.3.8.3 Casi en tiempo real y en tiempo real
Con el inicio de Operational BI (o Operational Analytics) que impulsaba una latencia más baja y una mayor integración de datos en tiempo
real o casi en tiempo real en el almacén de datos, surgieron nuevos enfoques arquitectónicos para lidiar con la inclusión de datos volátiles.
Por ejemplo, una aplicación común de BI operativa es el aprovisionamiento de datos de máquinas bancarias automatizadas. Al realizar una
transacción bancaria, los saldos históricos y los nuevos saldos resultantes de acciones bancarias inmediatas deben presentarse al cliente
bancario en tiempo real. Dos conceptos de diseño clave que se requieren para el aprovisionamiento de datos casi en tiempo real son el
aislamiento de cambios y las alternativas al procesamiento por lotes.
El impacto de los cambios de los nuevos datos volátiles debe aislarse de la mayor parte de los datos DW históricos no volátiles. Los
enfoques arquitectónicos típicos para el aislamiento incluyen una combinación de creación de particiones y el uso de consultas de unión
para las diferentes particiones. Las alternativas al procesamiento por lotes manejan los requisitos de latencia cada vez más cortos para la
disponibilidad de datos en el DW. Hay tres tipos principales: transmisiones lentas, mensajería y transmisión, que se diferencian por el lugar
donde se acumulan los datos mientras esperan ser procesados. (Consulte el Capítulo 8.)
• Feeds lentos (acumulación de fuente): en lugar de ejecutarse en un horario nocturno, los feeds lentos se ejecutan
cargas por lotes en un horario más frecuente (p. ej., cada hora, cada 5 minutos) o cuando se alcanza un umbral (p. ej., 300
transacciones, 1 G de datos). Esto permite que ocurra algo de procesamiento durante el día, pero no tan intensamente como
con un proceso por lotes nocturno dedicado. Es necesario tener cuidado para asegurarse de que si un lote de alimentación
lenta tarda más en completarse que el tiempo entre alimentaciones, la siguiente alimentación se retrasa para que los datos aún
se carguen en el orden correcto.
• Mensajería (acumulación de bus): la interacción de mensajes en tiempo real o casi en tiempo real es útil cuando se publican
paquetes de datos extremadamente pequeños (mensajes, eventos o transacciones) en un bus a medida que ocurren. Los
sistemas de destino se suscriben al bus y procesan gradualmente los paquetes en el almacén según sea necesario. Los
sistemas de origen y los sistemas de destino son independientes entre sí. Los datos como servicio (DaaS) utilizan con
frecuencia este método.
• Streaming (acumulación de destino): en lugar de esperar en un programa o umbral basado en la fuente, un sistema de destino
recopila datos a medida que se reciben en un área de búfer o cola y los procesa en orden. La interacción de resultados o algún
agregado puede aparecer más tarde como una fuente adicional para el almacén.
2. Actividades
2.1 Comprender los requisitos
Desarrollar un almacén de datos es diferente de desarrollar un sistema operativo. Los sistemas operativos dependen de requisitos precisos
y específicos. Los almacenes de datos reúnen datos que se utilizarán de diversas formas. Además, el uso evolucionará con el tiempo a
medida que los usuarios analicen y exploren los datos. Tómese su tiempo en las fases iniciales
para hacer preguntas relacionadas con las capacidades y las fuentes de datos para respaldar estas capacidades. Este tiempo de diseño vale la pena en
la reducción de los costos de reelaboración más adelante cuando el procesamiento de datos se prueba utilizando las fuentes de datos reales.
Al recopilar requisitos para proyectos DW/BI, comience con los objetivos y la estrategia comercial. Identifique y alcance las áreas comerciales, luego
identifique y entreviste a las personas de negocios apropiadas. Pregunte qué hacen y por qué. Capture las preguntas específicas que están haciendo
ahora y las que quieren hacer sobre los datos. Documente cómo distinguen y categorizan aspectos importantes de la información. Siempre que sea
posible, defina y capture métricas y cálculos de rendimiento clave. Estos pueden descubrir reglas comerciales que proporcionan la base para la
automatización de las expectativas de calidad de los datos.
Catalogue los requisitos y priorícelos en aquellos necesarios para la puesta en marcha de la producción y la adopción del almacén y aquellos que pueden
esperar. Busque elementos que sean simples y valiosos para impulsar la productividad del lanzamiento inicial del proyecto. La redacción de los requisitos
de un proyecto de DW/BI debe enmarcar todo el contexto de las áreas comerciales y/o procesos que están en el alcance.
2.2 Definir y mantener la arquitectura DW/BI
La arquitectura DW/BI debe describir de dónde provienen los datos, adónde van, cuándo van, por qué y cómo van a un almacén. El 'cómo' incluye los
detalles de hardware y software y el marco de organización para reunir todas las actividades. Los requisitos técnicos deben incluir las necesidades de
rendimiento, disponibilidad y tiempo. (Consulte los capítulos 4 y 8).
2.2.1 Definir la Arquitectura Técnica DW/BI
Las mejores arquitecturas DW/BI diseñarán un mecanismo para volver a conectarse a los informes de nivel transaccional y operativo en un DW atómico.
Este mecanismo protegerá al DW de tener que llevar todos los detalles transaccionales. Un ejemplo es proporcionar un mecanismo de visualización para
informes o formularios operativos clave basados en una clave transaccional, como el número de factura. Los clientes siempre querrán tener todos los
detalles disponibles, pero algunos de los datos operativos, como los campos de descripción larga, tienen valor solo en el contexto del informe original y
no proporcionan valor analítico.
Una arquitectura conceptual es un punto de partida. Muchas actividades son necesarias para alinear correctamente los requisitos no funcionales con las
necesidades del negocio. La creación de prototipos puede probar o refutar rápidamente puntos clave antes de hacer compromisos costosos con
tecnologías o arquitecturas. Además, empoderar a la comunidad empresarial con conocimientos y programas de adopción promovidos a través de un
equipo de gestión de cambios autorizado ayudará en la transición y el éxito operativo continuo.
Una extensión natural de este proceso de transformación es el mantenimiento, o al menos la validación, con el modelo de datos de la empresa. Dado que
el enfoque está en qué estructuras de datos están en uso por qué áreas organizacionales, verifique la implementación física contra el modelo lógico.
Realice cualquier actualización si surgen omisiones o errores.
396 • DMBOK2
2.2.2 Definir procesos de gestión de DW/BI
Aborde la gestión de producción con un proceso de mantenimiento coordinado e integrado, entregando versiones periódicas a la comunidad empresarial.
Es crucial establecer un plan de liberación estándar (consulte la Sección 2.6). Idealmente, el equipo del proyecto del almacén debe administrar cada
actualización del producto de datos implementado como una versión de software que proporciona funcionalidad adicional.
El establecimiento de un cronograma de lanzamientos permite un plan anual de demanda y recursos y un cronograma de entrega estándar. Use el
lanzamiento interno para modificar este cronograma estandarizado, las expectativas y la estimación de recursos
láminas derivadas para ello.
El establecimiento de un proceso de lanzamiento en funcionamiento garantiza que la administración entienda que se trata de un proceso proactivo
centrado en el producto de datos y no de un producto instalado que se aborda a través de la resolución reactiva de problemas. Es fundamental trabajar de
forma proactiva y colaborativa en un equipo multifuncional para crecer y mejorar las funciones de forma continua: los sistemas de soporte reactivos reducen
la adopción.
2.3 Desarrollar el Data Warehouse y Data Marts
Por lo general, los proyectos DW/BI tienen tres vías de desarrollo simultáneas:
• Datos: Los datos necesarios para soportar el análisis que el negocio quiere hacer. Esta pista implica identificar las mejores fuentes
para los datos y diseñar reglas sobre cómo se remedian, transforman, integran, almacenan y ponen a disposición los datos para
que los utilicen las aplicaciones. Este paso también incluye decidir cómo manejar los datos que no se ajustan a las expectativas.
• Tecnología: Los sistemas y procesos backend que soportan el almacenamiento y movimiento de datos.
La integración con la empresa existente es fundamental, ya que el almacén no es una isla en sí mismo.
Las Arquitecturas Empresariales, en concreto las especialidades de Tecnología y Aplicaciones, suelen gestionar esto
pista.
• Herramientas de Business Intelligence: el conjunto de aplicaciones necesarias para que los consumidores de datos obtengan
conocimiento de los productos de datos desplegados.
2.3.1 Asignar orígenes a destinos
El mapeo de fuente a destino establece reglas de transformación para entidades y elementos de datos de fuentes individuales a un sistema de destino.
Dicho mapeo también documenta el linaje de cada elemento de datos disponible en el entorno de BI hasta su(s) fuente(s) respectiva(s).
La parte más difícil de cualquier esfuerzo de mapeo es determinar enlaces válidos o equivalencias entre elementos de datos en múltiples sistemas.
Considere el esfuerzo de consolidar datos en un DW de múltiples facturas o pedidos
sistemas de gestión. Lo más probable es que las tablas y los campos que contienen datos equivalentes no tengan los mismos
nombres o estructuras.
Se necesita una taxonomía sólida para mapear elementos de datos en diferentes sistemas a una estructura consistente en el DW.
Muy a menudo, esta taxonomía es el modelo de datos lógicos. El proceso de mapeo también debe abordar si los datos en diferentes
estructuras se agregarán, cambiarán en su lugar o se insertarán.
2.3.2 Remediar y transformar datos
Las actividades de remediación o limpieza de datos hacen cumplir los estándares y corrigen y mejoran los valores de dominio de los
elementos de datos individuales. La remediación es particularmente necesaria para las cargas iniciales donde se involucra una historia
significativa. Para reducir la complejidad del sistema de destino, los sistemas de origen deben ser responsables de los datos.
remediación y corrección.
Desarrolle estrategias para las filas de datos que se cargan pero que son incorrectas. Una política para eliminar registros antiguos puede
causar algunos estragos con las tablas relacionadas y las claves sustitutas; hacer que caduque una fila y cargar los datos nuevos como
una fila completamente nueva puede ser una mejor opción.
Una estrategia de carga optimista puede incluir la creación de entradas de dimensión para acomodar datos de hechos. Tal proceso debe
dar cuenta de cómo actualizar y caducar dichas entradas. Las estrategias de carga pesimistas deben incluir un área de reciclaje para los
datos de hechos que no se pueden asociar con las claves de dimensión correspondientes. Estas entradas requieren notificaciones, alertas
e informes apropiados para garantizar que se rastreen y se vuelvan a cargar más tarde. Los trabajos de hechos deben considerar cargar
primero las entradas recicladas y luego procesar el contenido recién llegado.
La transformación de datos se centra en actividades que implementan reglas comerciales dentro de un sistema técnico. La transformación
de datos es esencial para la integración de datos. Definir las reglas correctas mediante las cuales integrar los datos a menudo requiere la
participación directa de los administradores de datos y otras pymes. Las reglas deben documentarse para que puedan ser gobernadas. Las
herramientas de integración de datos realizan estas tareas. (Consulte el Capítulo 8.)
2.4 Llene el almacén de datos
La mayor parte del trabajo en cualquier esfuerzo de DW/BI es la preparación y el procesamiento de los datos. Las decisiones de diseño y
los principios de qué detalle de datos contiene el DW son una prioridad de diseño clave para la arquitectura DW/BI.
Publicar reglas claras sobre qué datos estarán disponibles solo a través de informes operativos (como en no DW) es
crítico para el éxito de los esfuerzos de DW/BI.
Los factores clave que se deben tener en cuenta al definir un enfoque de población son la latencia requerida, la disponibilidad de las
fuentes, las ventanas de lote o los intervalos de carga, las bases de datos de destino, los aspectos dimensionales y la coherencia temporal
del almacén de datos y el data mart. El enfoque también debe abordar el procesamiento de la calidad de los datos, el tiempo para realizar
las transformaciones y las dimensiones que llegan tarde y los rechazos de datos.
398 • DMBOK2
Otro aspecto para definir un enfoque de población se centra en el proceso de captura de datos de cambio: detectar cambios en el sistema de
origen, integrar esos cambios y alinear los cambios a lo largo del tiempo. Varias bases de datos ahora proporcionan la funcionalidad de captura
de registros en la que las herramientas de integración de datos pueden operar directamente, por lo que la base de datos le dice al usuario qué
ha cambiado. Los procesos de secuencias de comandos se pueden escribir o generar donde esta función no está disponible. Hay varias
técnicas disponibles para los equipos de diseño y construcción para la integración y la alineación de la latencia en fuentes heterogéneas.
El primer incremento allana el camino para el desarrollo de capacidades adicionales y la incorporación de nuevas unidades de negocio.
Se necesitan muchas tecnologías, procesos y habilidades nuevas, así como una planificación cuidadosa y atención a los detalles.
Los incrementos posteriores deben construirse sobre este elemento fundamental, por lo que se recomiendan más inversiones para mantener
datos de alta calidad, arquitectura técnica y transición a producción. Cree procesos para facilitar y automatizar la identificación oportuna de
errores de datos con la integración del flujo de trabajo del usuario final.
2.5 Implementar el Portafolio de Business Intelligence
La implementación de la cartera de BI consiste en identificar las herramientas adecuadas para las comunidades de usuarios adecuadas dentro
o entre las unidades de negocio. Encuentre similitudes a través de la alineación de procesos comerciales comunes, análisis de rendimiento,
estilos de gestión y requisitos.
2.5.1 Agrupar Usuarios Según Necesidades
Al definir los grupos de usuarios objetivo, existe un espectro de necesidades de BI. Primero, conozca los grupos de usuarios y luego haga
coincidir la herramienta con los grupos de usuarios de la empresa. En un extremo del espectro están los desarrolladores de TI preocupados por
la extracción de datos, que se centran en la funcionalidad avanzada. Por otro lado, los consumidores de información pueden desear un acceso
rápido a informes desarrollados y ejecutados previamente. Es posible que estos consumidores deseen cierto grado de interactividad, como
explorar, filtrar, ordenar, o que solo deseen ver un informe estático.
Los usuarios pueden pasar de una clase a otra a medida que aumentan sus habilidades o realizan diferentes funciones. Un gerente de la
cadena de suministro, por ejemplo, puede querer ver un informe estático sobre finanzas pero un informe altamente interactivo para analizar el
inventario. Un analista financiero y un gerente de línea responsable de los gastos pueden ser usuarios avanzados al analizar los gastos totales,
pero están satisfechos con un informe estático de una factura telefónica. Los ejecutivos y gerentes utilizarán una combinación de informes fijos,
tableros y cuadros de mando. Los gerentes y los usuarios avanzados tienden a querer profundizar en estos informes, fragmentar y trocear los
datos para identificar las causas raíz de los problemas. Los clientes externos pueden utilizar cualquiera de estas herramientas como parte de
su experiencia.
2.5.2 Hacer coincidir las herramientas con los requisitos del usuario
El mercado ofrece una impresionante gama de herramientas de informes y análisis. Los principales proveedores de BI ofrecen capacidades
clásicas de informes con píxeles perfectos que alguna vez fueron el dominio de los informes de aplicaciones. Muchos proveedores de aplicaciones
ofrezca análisis integrados con contenido estándar extraído de cubos rellenados previamente o tablas agregadas.
La virtualización ha desdibujado las líneas entre las fuentes de datos locales y los datos abiertos o comprados externos y, en algunos
casos, proporciona una integración centrada en informes controlados por el usuario bajo demanda. En otras palabras, es prudente que
las empresas utilicen infraestructura y mecanismos de entrega comunes. Estos incluyen la web, el correo electrónico y las aplicaciones
para el envío de todo tipo de información e informes, de los cuales DW/BI es un subconjunto.
Muchos proveedores ahora combinan herramientas de BI relacionadas, a través de fusiones y adquisiciones o nuevos desarrollos netos,
y ofrecen suites de BI. Las suites son la opción principal en el nivel de arquitectura empresarial, pero dado que la mayoría de las
organizaciones ya compraron herramientas individuales o adoptaron herramientas de código abierto, es probable que surjan preguntas
sobre el reemplazo versus la coexistencia. Recuerde que cada herramienta de BI tiene un precio, que requiere recursos del sistema,
soporte, capacitación e integración arquitectónica.
2.6 Mantener productos de datos
Un almacén implementado y sus herramientas de BI orientadas al cliente es un producto de datos. Las mejoras (extensiones, aumentos
o modificaciones) a una plataforma DW existente deben implementarse de forma incremental.
Mantener el alcance de un incremento y ejecutar una ruta crítica para elementos de trabajo clave puede ser un desafío en un entorno de
trabajo dinámico. Establezca prioridades con los socios comerciales y centre el trabajo en las mejoras obligatorias.
2.6.1 Gestión de versiones
Release Management es fundamental para un proceso de desarrollo incremental que genera nuevas capacidades, mejora la
implementación de producción y garantiza la provisión de mantenimiento regular en todos los activos implementados. Este proceso
mantendrá el almacén actualizado, limpio y funcionando de la mejor manera. Sin embargo, este proceso requiere la misma alineación
entre TI y negocio que entre el modelo de almacenamiento de datos y las capacidades de BI. Es un esfuerzo de mejora continua.
La Figura 83 ilustra un proceso de lanzamiento de ejemplo, basado en un cronograma trimestral. A lo largo del año, hay tres versiones
impulsadas por el negocio y una versión basada en la tecnología (para abordar los requisitos internos del almacén).
El proceso debe permitir el desarrollo incremental del almacén y la gestión de la acumulación de requisitos.
2.6.2 Gestión del ciclo de vida de desarrollo de productos de datos
Si bien los consumidores de datos usan el DW existente, el equipo de DW se está preparando para la próxima iteración, con el
entendimiento de que no todos los elementos pasarán a producción. Alinee las iteraciones con los lanzamientos con una lista de trabajo
de pedidos pendientes priorizada por las unidades de negocio. Cada iteración extenderá un incremento existente o agregará una nueva
funcionalidad al incorporar una unidad de negocios. Los lanzamientos alinearán la funcionalidad con la unidad de negocios, mientras que
la iteración alineará la funcionalidad con la configuración en sí administrada por el gerente de producto.
400 • DMBOK2
• 3 lanzamientos trimestrales a las unidades de
Lanzamiento comercial +1 Lanzamiento comercial +2 Lanzamiento comercial +3
negocio, cada uno de los cuales proporciona
Entrega incremental Entrega incremental Entrega incremental capacidades incrementales • Alcance del
Plazo trimestral Plazo trimestral Plazo trimestral trabajo administrado con
Requisitos Congelados Requisitos Congelados Requisitos Congelados Lista de Moscú
Priorización del trabajo Priorización del trabajo Priorización del trabajo
• Tiempo gestionado con TimeBoxes
(Moscú) (Moscú) (Moscú)
DEBE
Debería
Podría
La cuarta versión es una
Entrega interna
BICC
Revisar
Versión interna 0 Plazo
Priorización del trabajo No Dealcance
trimestral 0.1 Entregables
de cosecha 0.2 Estimaciones
de actualización 0.3
Lecciones aprendidas 0.4
Gestión del conocimiento 0.5
Actualización de software/hardware
BICC 0.6 Capacitación/educación 0.7
Abordar soluciones alternativas
Implementación Mitigar
Priorización
Trabaja
Alrededor
Publicar
BICC
Defecto
Limitaciones
(Alrededores de trabajo)
Versión +4, 5, 6 Plan => De la admisión de trabajo
clasificada contra la lista MoSCoW de la versión 1, 2, 3 0.1
Método Entregables Actualización 0.2 Calculadora de
Defectos conocidos
Mitigar esfuerzo de trabajo Actualización 0.3 Mejores prácticas
Actualización 0.4 Conciencia Actualización 0.5 Capacidad de
software/hardware Horizonte Actualización 0.6 Certificación
de recursos Actualización 0.7 Actualización de alineación
táctica a estratégica
Figura 83 Ejemplo de proceso de liberación
Aquellos elementos que la empresa cree que están listos y factibles para una mayor investigación pueden revisarse, ajustarse si es
necesario y luego promoverse a un entorno piloto o de espacio aislado, donde los usuarios empresariales investigan nuevos
enfoques, experimentan con nuevas técnicas o desarrollan nuevos modelos o algoritmos de aprendizaje. Esta área puede tener
menos gobernanza y supervisión que otras áreas orientadas a los negocios, pero es necesario algún tipo de priorización de sandbox.
necesario.
De forma similar al entorno de prueba o garantía de calidad tradicional, examine los elementos en el área piloto para que encajen
en el mundo de la producción. El rendimiento de los elementos piloto determina sus próximos pasos. Tenga cuidado de no
promocionar a ciegas y sin tener en cuenta la calidad de los datos posteriores o los problemas de gobernanza. La vida útil en
producción es solo una medida existencial: debe ser de la más alta calidad práctica para estar en producción.
Los elementos que superan la prueba piloto y que los representantes comerciales y de TI consideran listos para la producción pueden
promoverse a la producción como nuevos productos de datos. Esto completa una iteración.
Los elementos que no pasan la prueba piloto pueden rechazarse por completo o devolverse al desarrollo para su ajuste. Tal vez se necesite
apoyo adicional del equipo de DW en este momento para avanzar el elemento en la próxima iteración de promoción.
2.6.3 Supervisar y ajustar los procesos de carga
Supervise el procesamiento de carga en todo el sistema en busca de cuellos de botella y dependencias. Emplee técnicas de ajuste de bases
de datos donde y cuando sea necesario, incluidas estrategias de particionamiento, copias de seguridad ajustadas y recuperación. El archivado
es un tema difícil en el almacenamiento de datos.
Los usuarios a menudo consideran el almacén de datos como un archivo activo debido a los largos historiales que se construyen y no están
dispuestos, especialmente si las fuentes de procesamiento analítico en línea (OLAP) han eliminado registros, para ver que el almacén de datos
participa en el archivo. (Consulte el Capítulo 6.)
2.6.4 Supervisar y ajustar la actividad y el rendimiento de BI
Una mejor práctica para el monitoreo y ajuste de BI es definir y mostrar un conjunto de métricas de satisfacción de cara al cliente. El tiempo
promedio de respuesta a consultas y la cantidad de usuarios por día, semana o mes son ejemplos de métricas útiles. Además de las medidas
estadísticas disponibles de los sistemas, es útil encuestar a los clientes de DW/BI con regularidad.
La revisión regular de las estadísticas y patrones de uso es esencial. Los informes que proporcionan la frecuencia y el uso de recursos de
datos, consultas e informes permiten una mejora prudente. Ajustar la actividad de BI es análogo al principio de crear perfiles de aplicaciones
para saber dónde están los cuellos de botella y dónde aplicar los esfuerzos de optimización. La creación de índices y agregaciones es más
efectiva cuando se realiza de acuerdo con los patrones de uso y las estadísticas.
Grandes mejoras en el rendimiento pueden provenir de soluciones simples, como publicar los resultados diarios completos en un informe que
se ejecuta cientos o miles de veces al día.
La transparencia y la visibilidad son los principios clave que deben impulsar el monitoreo de DW/BI. Cuanto más se puedan exponer los detalles
de las actividades de DW/BI, más consumidores de datos podrán ver y comprender lo que está sucediendo (y tener confianza en el BI), y se
requerirá menos soporte directo al cliente final. Proporcionar un tablero que exponga el estado de alto nivel de las actividades de entrega de
datos, con capacidad de desglose, es una mejor práctica que permite obtener información bajo demanda tanto por parte del personal de
soporte como de los clientes.
La adición de medidas de calidad de datos mejorará el valor de este tablero donde el rendimiento es más que solo velocidad y tiempo. Utilice
mapas de calor para visualizar la carga de trabajo en la infraestructura, el rendimiento de datos y el cumplimiento de los niveles de acuerdos
operativos.
402 • DMBOK2
3. Herramientas
Elegir el conjunto inicial de herramientas puede ser un proceso largo. Incluye intentar satisfacer los requisitos a corto plazo, las
especificaciones no funcionales y los requisitos de próxima generación que aún no se han creado. Los conjuntos de herramientas de
criterios de decisión, las herramientas de implementación de procesos y las ofertas de servicios profesionales pueden facilitar y
acelerar esta actividad. Es fundamental evaluar no solo las posiciones convencionales de creación o compra, sino también la opción
de alquiler aprovisionada como software como servicio. El alquiler de herramientas SaaS y la experiencia asociada se compara con el
costo de construir desde cero o implementar productos comprados a los proveedores. Considere también la actualización continua y
los posibles costos de reemplazo. La alineación con un OLA (Acuerdo de nivel operativo) establecido puede salvar los costos previstos
y proporcionar información para establecer tarifas y sanciones convincentes por violaciones de términos.
3.1 Repositorio de Metadatos
Las grandes organizaciones a menudo se encuentran con muchas herramientas de diferentes proveedores, cada una implementada
potencialmente en diferentes versiones. La clave de este esfuerzo es la capacidad de unir metadatos de una variedad de fuentes.
La automatización e integración de la población de este repositorio se puede lograr con una variedad de técnicas. (Consulte el Capítulo
13.)
3.1.1 Diccionario de datos / Glosario
Un diccionario de datos es necesario para soportar el uso de un DW. El diccionario describe los datos en términos comerciales e
incluye otra información necesaria para utilizar los datos (por ejemplo, tipos de datos, detalles de la estructura, restricciones de seguridad).
A menudo, el contenido del diccionario de datos proviene directamente del modelo de datos lógicos. Planifique metadatos de alta
calidad asegurándose de que los modeladores adopten un enfoque disciplinado para administrar las definiciones como parte del modelado
proceso.
En algunas organizaciones, los usuarios comerciales participan activamente en el desarrollo del diccionario de datos proporcionando,
definiendo y luego administrando las correcciones a las definiciones de los elementos de datos del área temática. Adopte esta actividad
a través de una herramienta de colaboración, supervise las actividades a través de un Centro de excelencia y asegúrese de que el
contenido creado a través de esta actividad se conserve en el modelo lógico. Garantizar la concordancia entre el contenido orientado
al negocio y el modelo de datos físicos orientados a la técnica reducirá el riesgo de errores posteriores y reelaboración. (Consulte el
Capítulo 13.)
3.1.2 Datos y linaje del modelo de datos
Muchas herramientas de integración de datos ofrecen análisis de linaje que considera tanto el código de población desarrollado como
el modelo de datos físicos y la base de datos. Algunos ofrecen interfaces web para monitorear y actualizar definiciones y otros
metadatos. El linaje de datos documentados sirve para muchos propósitos:
• Investigación de las causas raíz de los problemas de datos •
Análisis de impacto para cambios en el sistema o problemas de datos •
Capacidad para determinar la confiabilidad de los datos, en función de su origen
Busque implementar una herramienta integrada de impacto y linaje que pueda comprender todas las partes móviles involucradas en el proceso de carga,
así como los informes y análisis del usuario final. Los informes de análisis de impacto describirán qué componentes se ven afectados por un posible
cambio, acelerando y simplificando las tareas de estimación y mantenimiento.
Muchos procesos comerciales, relaciones y terminologías clave se capturan y explican durante el desarrollo del modelo de datos. El modelo de datos
lógicos contiene gran parte de esta información, que a menudo se pierde o se ignora durante el desarrollo o la implementación de producción. Es
fundamental garantizar que esta información no se descarte y que los modelos lógicos y físicos se actualicen después de la implementación y estén
sincronizados.
3.2 Herramientas de integración de datos
Las herramientas de integración de datos se utilizan para llenar un almacén de datos. Además de realizar el trabajo de integración de datos, permiten la
programación de trabajos de formas que dan cuenta de la entrega de datos complejos de múltiples fuentes. Al seleccionar una herramienta, también tenga
en cuenta estas características que permiten la gestión del sistema:
• Auditoría, control, reinicio y programación de procesos • La
capacidad de extraer elementos de datos de forma selectiva en el momento de la ejecución y pasar esa extracción a un proceso posterior
sistema con fines de auditoría
• Controlar qué operaciones pueden o no ejecutarse y reiniciar una ejecución fallida o abortada (consulte el Capítulo
8)
Una variedad de herramientas de integración de datos también ofrecen capacidades de integración con la cartera de BI, lo que admite la importación y
exportación de mensajes de flujo de trabajo, correo electrónico o incluso capas semánticas. La integración del flujo de trabajo puede impulsar los procesos
de identificación, resolución y escalamiento de defectos en la calidad de los datos. La mensajería a través de correo electrónico o el procesamiento de
alertas impulsado desde el correo electrónico es una práctica común, especialmente para dispositivos móviles. Además, la capacidad de aprovisionar un
objetivo de datos como una capa semántica puede ser un candidato de virtualización de datos para implementaciones ágiles.
3.3 Tipos de herramientas de inteligencia comercial
La madurez del mercado de BI y la amplia gama de herramientas de BI disponibles hacen que sea raro que las empresas construyan sus propias
herramientas de BI.68 El propósito de esta sección es presentar los tipos de herramientas disponibles en el mercado de BI y proporcionar una descripción
general de sus características principales con información para ayudar a hacer coincidir las herramientas con las adecuadas
68
El material de esta sección proviene principalmente de “The Business Intelligence Market” de Cindi Howson, BIScorecard®,
http://bit.ly/2tNirv5; usado con permiso, con cambios y adiciones menores.
404 • DMBOK2
capacidades a nivel del cliente. Las herramientas de BI están evolucionando rápidamente, lo que permite una transición de informes estandarizados y
dirigidos por TI a exploración de datos impulsada por el negocio y de autoservicio.69
• Los informes operativos son la aplicación de herramientas de BI para analizar las tendencias comerciales, tanto a corto plazo
(mes tras mes) y a más largo plazo (año tras año). Los informes operativos también pueden ayudar a descubrir tendencias y patrones.
Utilice BI táctico para respaldar las decisiones comerciales a corto plazo.
• La gestión del rendimiento empresarial (BPM) incluye la evaluación formal de métricas alineadas con los objetivos de la organización. Esta
evaluación generalmente ocurre a nivel ejecutivo. Utilice BI estratégico para respaldar metas y objetivos corporativos a largo plazo.
• El análisis descriptivo de autoservicio proporciona BI a la primera línea del negocio, donde el análisis
las capacidades guían las decisiones operativas. El análisis operativo combina aplicaciones de BI con funciones y procesos operativos para
guiar las decisiones casi en tiempo real. El requisito de baja latencia (captura y entrega de datos casi en tiempo real) impulsará el enfoque
arquitectónico de las soluciones de análisis operativo. La arquitectura orientada a servicios (SOA) y Big Data se vuelven necesarios para
respaldar completamente el análisis operativo (consulte los Capítulos 8 y 15).
3.3.1 Informes operativos
Los informes operativos involucran a los usuarios comerciales que generan informes directamente desde sistemas transaccionales, aplicaciones
operativas o un almacén de datos. Esto suele ser una funcionalidad de la aplicación. A menudo, las áreas comerciales comenzarán a utilizar un DW para
la elaboración de informes operativos, especialmente si el gobierno de DW/BI es deficiente, o si el DW contiene datos adicionales que mejoran los datos
operativos y de transacciones. A menudo, los informes aparecerán como consultas adhoc, cuando en realidad son informes simples o se utilizan para
iniciar un flujo de trabajo. Desde una perspectiva de gestión de datos, la clave es comprender si los datos necesarios para este informe existen dentro de
la propia aplicación, o si requiere mejoras de datos del DW o del almacén de datos operativos.
Las herramientas de generación de informes y exploración de datos, a veces denominadas herramientas de consulta adhoc, permiten a los usuarios
crear sus propios informes o crear resultados para que otros los utilicen. Les preocupa menos el diseño preciso porque no están tratando de generar una
factura o similar. Sin embargo, sí quieren incluir gráficos y tablas de forma rápida e intuitiva. A menudo, los informes creados por los usuarios comerciales
se convierten en informes estándar, que no se utilizan exclusivamente para preguntas comerciales ad hoc.
Las necesidades dentro de los informes de operaciones comerciales a menudo son diferentes de las necesidades dentro de las consultas y los informes
comerciales. Con las consultas y los informes comerciales, la fuente de datos suele ser un almacén de datos o un data mart (aunque no siempre).
Mientras TI desarrolla informes de producción, los usuarios avanzados y los usuarios empresariales ad hoc desarrollan sus propios informes con
herramientas de consulta empresarial. Utilice informes generados con herramientas de consulta empresarial de forma individual, por departamento o en
toda la empresa.
69 Dataversity se refiere a esta tendencia como la "democratización de las tecnologías de datos". Véase Ghosh, Paramita. "Un estudio comparativo
de las tendencias del mercado de Business Intelligence and Analytics". diversidad de datos. 17 de enero de 2017. http://bit.ly/2sTgXTJ (consultado
el 22 de enero de 2017).
Los informes de producción cruzan el límite DW/BI y, a menudo, consultan los sistemas transaccionales para producir elementos operativos,
como facturas o extractos bancarios. Los desarrolladores de informes de producción suelen ser personal de TI.
Las herramientas de BI tradicionales cubren algunos métodos de visualización de datos, como tablas, gráficos circulares, gráficos de líneas,
gráficos de área, gráficos de barras, histogramas, cuadro llave en mano (candelabro) como ejemplos bastante bien. Las visualizaciones de
datos se pueden entregar en un formato estático, como un informe publicado, o un formato en línea más interactivo; y algunos admiten la
interacción del usuario final donde las capacidades de exploración o filtrado facilitan el análisis de datos dentro de la visualización. Otros
permiten que el usuario cambie la visualización bajo demanda. (Consulte el Capítulo 14.)
3.3.2 Gestión del rendimiento empresarial
La gestión del rendimiento es un conjunto de procesos y aplicaciones organizativos integrados diseñados para optimizar la ejecución de la
estrategia empresarial; las aplicaciones incluyen elaboración de presupuestos, planificación y consolidación financiera. Ha habido una serie
de adquisiciones importantes en este segmento, ya que los proveedores de ERP y los proveedores de BI ven grandes oportunidades de
crecimiento aquí y creen que BI y Performance Management están convergiendo. La frecuencia con la que los clientes compran BI y gestión
del rendimiento del mismo proveedor depende de las capacidades del producto.
En términos generales, la tecnología de gestión del rendimiento permite que los procesos ayuden a cumplir los objetivos de la organización.
La medición y un ciclo de retroalimentación con refuerzo positivo son elementos clave. Dentro del espacio de BI, esto ha tomado la forma
de muchas aplicaciones empresariales estratégicas, como la elaboración de presupuestos, la previsión o la planificación de recursos.
Se ha formado otra especialización en esta área: la creación de cuadros de mando impulsados por paneles para la interacción del usuario.
Los tableros, como los que se encuentran en los automóviles, brindan el resumen necesario o la información agregada al usuario final con
las actualizaciones más recientes (Eckerson, 2005).
3.3.3 Aplicaciones analíticas operativas
Henry Morris de IDC acuñó el término Aplicaciones analíticas en la década de 1990, aclarando en qué se diferencian de las herramientas
generales de OLAP y BI (Morris, 1999). Las aplicaciones analíticas incluyen la lógica y los procesos para extraer datos de sistemas de
origen conocidos, como sistemas ERP de proveedores, un modelo de datos para el data mart e informes y paneles preconstruidos. Brindan
a las empresas una solución preconstruida para optimizar un área funcional (gestión de personas, por ejemplo) o vertical de la industria
(análisis minorista, por ejemplo). Los diferentes tipos de aplicaciones analíticas incluyen aplicaciones de clientes, financieras, de cadena de
suministro, de fabricación y de recursos humanos.
3.3.3.1 Análisis Multidimensional – OLAP
El procesamiento analítico en línea (OLAP) se refiere a un enfoque para proporcionar un rendimiento rápido para consultas analíticas
multidimensionales. El término OLAP se originó, en parte, para hacer una clara distinción de OLTP, Procesamiento transaccional en línea.
La salida típica de las consultas OLAP está en formato de matriz. Las dimensiones forman las filas y columnas de la matriz, y los factores,
o medidas, son los valores dentro de la matriz.
406 • DMBOK2
Conceptualmente, esto se ilustra como un cubo. El análisis multidimensional con cubos es particularmente útil cuando existen formas bien conocidas
en las que los analistas desean ver resúmenes de datos.
Una aplicación tradicional es el análisis financiero, donde los analistas quieren atravesar repetidamente jerarquías conocidas para analizar datos; por
ejemplo, fecha (como Año, Trimestre, Mes, Semana, Día), organización (como Región, País, Unidad comercial, Departamento) y jerarquía de productos
(como Categoría de producto, Línea de producto, Producto).
Muchas herramientas hoy en día incorporan cubos OLAP en su espacio de software y algunas incluso automatizan e integran sin problemas el proceso
de definición y población. Esto significa que cualquier usuario en cualquier proceso de negocios puede dividir sus datos. Alinee esta capacidad con los
usuarios avanzados en las comunidades del área temática y ofrézcala a lo largo de un canal de autoservicio que permita a estos usuarios seleccionados
analizar sus datos a su manera.
Por lo general, las herramientas OLAP tienen un componente de servidor y un componente orientado al cliente del usuario final instalado en el escritorio
o disponible en la web. Se puede acceder a algunos componentes del escritorio desde una hoja de cálculo que aparece como un menú integrado o un
elemento de función. La arquitectura seleccionada (ROLAP, MOLAP, HOLAP) guiará los esfuerzos de desarrollo, pero todos tendrán en común la
definición de la estructura del cubo, las necesidades agregadas, el aumento de metadatos y el análisis de la escasez de datos.
La estructuración del cubo para satisfacer los requisitos funcionales deseados puede requerir la división de dimensiones más grandes en cubos
separados para adaptarse a los requisitos de almacenamiento, población o cálculo. Utilice niveles de agregación para garantizar que el cálculo y la
recuperación de las fórmulas deseadas ocurran dentro de los tiempos de respuesta acordados. El aumento de jerarquías por parte del usuario final
permite el cumplimiento de los requisitos de agregación, cálculo o población. Además, la escasez de datos del cubo puede requerir la adición o
eliminación de estructuras agregadas o necesidades de materialización refinadas en la capa de datos del almacén que lo aprovisiona.
El aprovisionamiento de seguridad basada en roles o texto en varios idiomas dentro del cubo puede requerir dimensiones adicionales, funciones
adicionales, cálculos o, a veces, crear estructuras de cubo separadas. Lograr un equilibrio entre la flexibilidad del usuario final, el rendimiento y las
cargas de trabajo del servidor significa que se espera cierta negociación. La negociación generalmente ocurre durante los procesos de carga y puede
requerir cambios de jerarquía, cambios de estructura agregada u objetos de datos materializados de almacén adicionales. Logre el equilibrio adecuado
entre el número de cubos, la carga de trabajo del servidor y la flexibilidad entregada, de modo que la actualización se produzca de manera oportuna y
los cubos proporcionen consultas confiables y consistentes sin altos costos de almacenamiento o utilización del servidor.
El valor de las herramientas y cubos de procesamiento analítico en línea (OLAP) es la reducción de la posibilidad de confusión e interpretación errónea,
al alinear el contenido de los datos con el modelo mental del analista. El analista puede navegar a través de la base de datos y la pantalla para un
subconjunto particular de datos, cambiando la orientación de los datos y definiendo cálculos analíticos. Sliceanddice es el proceso de navegación
iniciado por el usuario mediante la solicitud de pantallas de página de forma interactiva, a través de la especificación de cortes a través de rotaciones y
desglose hacia abajo/arriba. Las operaciones comunes de OLAP incluyen cortar y dividir, desglosar, desglosar, resumir y pivotar.
• Sector: un sector es un subconjunto de una matriz multidimensional correspondiente a un solo valor para uno o más
miembros de las dimensiones que no están en el subconjunto.
• Dados: la operación de dados es una división en más de dos dimensiones de un cubo de datos, o más de dos
rebanadas consecutivas.
• Drill down/up: Drilling down o up es una técnica analítica específica mediante la cual el usuario navega
entre niveles de datos, desde el más resumido (arriba) hasta el más detallado (abajo).
• Resumen: un resumen implica calcular todas las relaciones de datos para una o más dimensiones. Hacer
esto, define una relación o fórmula computacional.
• Pivote: un pivote cambia la orientación dimensional de un informe o visualización de página.
Tres enfoques de implementación clásicos admiten el procesamiento analítico en línea.
• Procesamiento analítico en línea relacional (ROLAP): ROLAP admite OLAP mediante el uso de técnicas
que implementan la multidimensionalidad en las tablas bidimensionales de los sistemas de gestión de bases de datos relacionales
(RDBMS). Las combinaciones de esquemas en estrella son una técnica de diseño de base de datos común utilizada en ROLAP
entornos.
• Procesamiento analítico en línea multidimensional (MOLAP): MOLAP es compatible con OLAP mediante el uso de
tecnología de base de datos multidimensional patentada y especializada.
• Procesamiento analítico en línea híbrido (HOLAP): Esto es simplemente una combinación de ROLAP y
MOLAP. Las implementaciones de HOLAP permiten que parte de los datos se almacenen en formato MOLAP y otra parte de los
datos se almacenen en ROLAP. Las implementaciones varían según el control que tiene un diseñador para variar la combinación de
particiones.
4. Técnicas
4.1 Prototipos para conducir requisitos
Priorice rápidamente los requisitos antes de que comiencen las actividades de implementación mediante la creación de un conjunto de datos de
demostración y la aplicación de pasos de descubrimiento en un esfuerzo de prototipo conjunto. Los avances en las tecnologías de virtualización de
datos pueden aliviar algunos de los problemas de implementación tradicionales a través de técnicas de creación de prototipos colaborativos.
Perfilar los datos contribuye a la creación de prototipos y ayuda a reducir el riesgo asociado con datos inesperados. El DW es a menudo el primer
lugar donde se hace evidente el dolor de los datos de baja calidad en los sistemas de origen o las funciones de entrada de datos. La creación de
perfiles también revela diferencias entre las fuentes que pueden presentar obstáculos para la integración de datos.
Los datos pueden ser de alta calidad dentro de sus fuentes, pero debido a que las fuentes difieren, el proceso de integración de datos se vuelve
más complicado.
La evaluación del estado de los datos de origen conduce a estimaciones iniciales más precisas de la viabilidad y el alcance del esfuerzo. La
evaluación también es importante para establecer expectativas adecuadas. Planee colaborar con los equipos de calidad de datos y gobierno de
datos y aprovechar la experiencia de otras pymes para comprender las discrepancias y los riesgos de los datos. (Véanse los capítulos 11 y 13.)
408 • DMBOK2
4.2 BI de autoservicio
El autoservicio es un canal de entrega fundamental dentro de la cartera de BI. Esto generalmente canaliza la actividad del usuario dentro
de un portal gobernado donde, según los privilegios del usuario, se proporciona una variedad de funcionalidades que van desde mensajes,
alertas, visualización de informes de producción programados, interacción con informes analíticos, desarrollo de informes ad hoc y, por
supuesto, panel de control. y tarjeta de puntuación. Los informes se pueden enviar al portal en horarios estándar, para que los usuarios los
recuperen cuando lo deseen. Los usuarios también pueden obtener datos mediante la ejecución de informes desde el portal. Estos portales
comparten contenido a través de los límites organizacionales.
Extender la herramienta de colaboración hacia la comunidad de usuarios también puede proporcionar sugerencias y trucos de autoservicio,
un comunicado integrado sobre el estado de carga, el rendimiento general y el progreso de la versión, así como foros de diálogo. Mediar el
contenido del foro a través del canal de soporte y luego facilitar con sesiones de grupo de usuarios a través de
el canal de mantenimiento.
Las herramientas de visualización y análisis estadístico permiten una rápida exploración y descubrimiento de datos. Algunas herramientas
permiten la construcción centrada en el negocio de tableros como objetos que se pueden compartir, revisar y revitalizar rápidamente.
Una vez que el dominio de TI y los desarrolladores era exclusivo, la comunidad empresarial ahora puede emplear muchas técnicas de
modelado, cálculo y visualización de datos. Esto ofrece un grado de distribución de la carga de trabajo y los esfuerzos de integración
pueden ser prototipados de manera factible a través de canales comerciales y luego materializados y optimizados por TI.
4.3 Datos de auditoría que se pueden consultar
Para mantener el linaje, todas las estructuras y procesos deben tener la capacidad de crear y almacenar información de auditoría en un
grano útil para el seguimiento y la generación de informes. Permitir que los usuarios consulten estos datos de auditoría les permite verificar
por sí mismos la condición y la llegada de los datos, lo que mejora la confianza del usuario. La información de auditoría también permite
una resolución de problemas más detallada cuando surgen problemas con los datos.
5. Pautas de implementación
Una arquitectura estable que pueda escalar para cumplir con los requisitos futuros es fundamental para el éxito de un almacén de datos.
Es obligatorio contar con un equipo de soporte de producción capaz de manejar la carga diaria, el análisis y la retroalimentación del usuario
final. Además, para mantener el éxito, asegúrese de que los equipos del almacén y de la unidad comercial estén alineados.
5.1 Evaluación de preparación / Evaluación de riesgos
Puede haber una brecha entre el momento en que una organización adopta una nueva empresa y el momento en que tiene la capacidad
de sostener esa empresa. Los proyectos exitosos comienzan con una lista de verificación de requisitos previos. Todos los proyectos de TI
deben tener soporte comercial, estar alineados con la estrategia y tener un enfoque arquitectónico definido. Además, un DW debe:
• Definir la confidencialidad de los datos y las restricciones de seguridad
• Realizar la selección de herramientas
• Recursos seguros
• Crear un proceso de ingestión para evaluar y recibir datos de origen
Identificar e inventariar elementos de datos confidenciales o restringidos en el almacén. Estos datos deberán enmascararse u ofuscarse para evitar el acceso
de personal no autorizado. Pueden aplicarse restricciones adicionales al considerar la subcontratación para actividades de implementación o mantenimiento.
Tenga en cuenta las restricciones de seguridad antes de seleccionar herramientas y asignar recursos. Asegúrese de que se hayan seguido los procesos de
gobierno de datos para su revisión y aprobación. Los proyectos DW/BI corren el riesgo de reenfocarse o cancelarse por completo debido a estos factores
generales.
5.2 Hoja de ruta de lanzamiento
Debido a que requieren un gran esfuerzo de desarrollo, los almacenes se construyen de forma incremental. Cualquiera que sea el método elegido para
implementar, ya sea en cascada, iterativo o ágil, debe tener en cuenta el estado final deseado. Es por eso que una hoja de ruta es una valiosa herramienta de
planificación. El método combinado con los procesos de mantenimiento puede ser flexible y adaptable para equilibrar las presiones de la entrega de proyectos
individuales con los objetivos generales de datos reutilizables y
infraestructura.
Se sugiere un enfoque incremental que aproveche la matriz de bus DW como herramienta de comunicación y marketing.
Use prioridades determinadas por el negocio atadas por métricas de exposición para determinar cuánto rigor y gastos generales aplicar a cada incremento;
una pequeña entrega de una sola fuente puede permitir la relajación de las reglas, especialmente cuando se siente una exposición limitada en caso de que la
organización se dé cuenta de esos problemas.
Cada incremento modificará las capacidades existentes o agregará capacidades completamente nuevas, típicamente alineadas con una unidad de negocios
recién incorporada. Aplique un proceso consistente de necesidades y habilidades para determinar la próxima unidad de negocios que se incorporará. Mantenga
una lista de elementos de trabajo o pedidos pendientes para identificar las capacidades sobresalientes y las prioridades comerciales. Determinar las
dependencias técnicas que requieran entrega en otro orden. Luego empaquete este trabajo en una versión de software. Cada lanzamiento se puede entregar
a un ritmo acordado: trimestral, mensual, semanal o incluso más rápido cuando corresponda. Administre los lanzamientos con los socios comerciales mediante
el ensamblaje de una hoja de ruta: una lista de lanzamientos por fecha por capacidades.
5.3 Gestión de la configuración
La gestión de la configuración se alinea con la hoja de ruta del lanzamiento y proporciona las secuencias de comandos y las uniones administrativas necesarias
para automatizar el desarrollo, las pruebas y el transporte a la producción. También marca el modelo por el lanzamiento a nivel de la base de datos y vincula
la base de código a esa marca de manera automatizada para que manualmente
410 • DMBOK2
Los programas codificados y generados y el contenido de la capa semántica se armonizan en todo el entorno y se versionan.
revisado.
5.4 Organización y cambio cultural
Comenzar y mantener un enfoque comercial constante a lo largo del ciclo de vida de DW/BI es esencial para el éxito.
Observar la cadena de valor de la empresa es una buena manera de comprender el contexto comercial. Los procesos comerciales específicos
en la cadena de valor de una empresa proporcionan un contexto natural orientado al negocio en el que enmarcar las áreas de análisis.
Lo que es más importante, alinee los proyectos con las necesidades comerciales reales y evalúe el apoyo comercial necesario, considerando
estos factores críticos de éxito:
• Patrocinio empresarial: ¿Existe un patrocinio ejecutivo adecuado, es decir, una empresa identificada y comprometida ?
comité directivo y la financiación correspondiente? Los proyectos DW/BI requieren un fuerte patrocinio ejecutivo.
• Objetivos comerciales y alcance: ¿Existe una necesidad comercial, un propósito y un alcance claramente identificados para el
¿esfuerzo?
• Recursos empresariales: ¿Existe un compromiso por parte de la dirección empresarial con la disponibilidad y
contratación de los expertos en la materia de negocios apropiados? La falta de compromiso es un punto común de falla y una
buena razón para detener un proyecto DW/BI hasta que se confirme el compromiso.
• Preparación comercial: ¿Está el socio comercial preparado para una entrega incremental a largo plazo? ¿Se han comprometido a
establecer centros de excelencia para sustentar el producto en versiones futuras?
¿Qué tan amplia es la brecha promedio de conocimientos o habilidades dentro de la comunidad objetivo y se puede cruzar en
un solo incremento?
• Alineación de la visión: ¿En qué medida la estrategia de TI respalda la visión empresarial? Es vital asegurar
que los requisitos funcionales deseados correspondan a las capacidades comerciales que son o pueden ser sostenidas en la
hoja de ruta de TI inmediata. Cualquier desvío significativo o brecha material en la alineación de la capacidad puede estancar o
detener un programa DW/BI.
5.4.1 Equipo dedicado
Muchas organizaciones cuentan con un equipo dedicado a administrar las operaciones en curso del entorno de producción.
(Ver Capítulo 6). Un par de manos separadas que operen el producto de datos entregado es beneficioso para la optimización de la carga de
trabajo, ya que este grupo tiene tareas repetitivas en un ciclo de calendario y puede usarse más para cualquier elemento de escalamiento,
mientras que el canal de mantenimiento verá picos de carga de trabajo alineados con entregas específicas.
Un grupo de apoyo de la oficina principal interactúa con el equipo de mantenimiento para fomentar las relaciones entre departamentos y
garantizar que las actividades críticas se aborden en las próximas versiones. Notifica al equipo de cualquier deficiencia a ser
dirigido. Un equipo de soporte administrativo en operaciones se asegurará de que la configuración de producción se haya ejecutado según lo
requerido. Escalarán las alertas e informarán sobre el estado del rendimiento.
6. Gobernanza de DW/BI
Las industrias que están altamente reguladas y necesitan informes centrados en el cumplimiento se beneficiarán enormemente de un almacén
de datos bien administrado. Es fundamental para el apoyo continuo y vital para la planificación del lanzamiento garantizar que las actividades
de gobierno se completen y aborden durante la implementación. Cada vez más organizaciones están ampliando su ciclo de vida de desarrollo
de software con productos específicos destinados a abordar las necesidades de gobierno.
Los procesos de gobierno del almacén deben estar alineados con la gestión de riesgos. Deben estar orientados a los negocios, ya que los
diferentes tipos de negocios tienen diferentes necesidades (por ejemplo, las empresas de marketing y publicidad usarán sus datos de manera
diferente a las instituciones financieras). Los procesos de gobierno deben mitigar el riesgo, no reducirlo
ejecución.
Las funciones más críticas son aquellas que gobiernan el área de descubrimiento o refinamiento operada por el negocio, y aquellas que
aseguran una calidad impecable dentro del propio almacén. Dado que el área de refinamiento lidera todos los límites de la iniciativa, se
necesitan procedimientos de negociación y buen funcionamiento para instanciar, operar, transferir y descartar los datos en estas áreas. El
archivo de datos y los horizontes temporales son elementos clave en los acuerdos de límites, ya que ayudan a evitar la expansión. El monitoreo
de estos entornos y los cronogramas para determinar los términos de longevidad se incluyen en las sesiones de grupos de usuarios, así como
en las reuniones de administración. Cargar datos en el almacén significa asignar tiempo, recursos y esfuerzos de programación para que los
datos remediados, creíbles y de alta calidad lleguen a la comunidad de usuarios finales, de manera oportuna, por supuesto.
Considere eventos únicos o de uso limitado como parte del ciclo de vida, y tal vez redúzcalos dentro del área piloto en sí, o dentro de un área
de 'sandbox' controlada por el usuario. Los procesos de análisis en tiempo real pueden devolver los resultados agregados alineados en el
tiempo al almacén de datos a través de un proceso automatizado. La política se define para los procedimientos promulgados en el entorno en
tiempo real, y la gobernanza se aplica a la intermediación de los resultados en el almacén para el consumo de la organización.
Aplicar discriminación de datos a elementos conocidos o catalogados gestionados a través de una matriz de mitigación de exposición al riesgo.
Aquellos elementos con una exposición alta considerada y baja mitigación o detección temprana difícil, garantizan funciones de gobierno para
reducir el riesgo asociado. Dependiendo de la sensibilidad de los datos que se examinan, también puede ser necesario un espacio de trabajo
separado para el personal local seleccionado. Una revisión exhaustiva con el personal legal y de seguridad corporativo durante la formación de
la política crea una red de seguridad final.
6.1 Habilitación de la aceptación comercial
Un factor clave de éxito es la aceptación de los datos por parte de las empresas, lo que incluye que los datos sean comprensibles, tengan una
calidad verificable y tengan un linaje demostrable. La aprobación por parte de la empresa de los datos debe ser parte de la prueba de
aceptación del usuario. Realice pruebas aleatorias estructuradas de los datos en la herramienta de BI contra los datos en la fuente
412 • DMBOK2
sistemas sobre la carga inicial, y después de algunos ciclos de carga de actualización, para cumplir con los criterios de aprobación. Cumplir con
estos requisitos es primordial para cada implementación de DW/BI. Considere, por adelantado, algunos subcomponentes arquitectónicos de
importancia crítica, junto con sus actividades de apoyo:
• Modelo conceptual de datos: ¿Qué información es fundamental para la organización? ¿Cuáles son los negocios clave?
conceptos y cómo se relacionan entre sí?
• Ciclo de retroalimentación de la calidad de los datos: ¿Cómo se identifican y solucionan los problemas de datos? como son los dueños de
sistemas en los que se originan los problemas informados sobre los problemas y responsabilizados por solucionarlos?
¿Cuál es el proceso de corrección de los problemas causados por los procesos de integración de datos de DW?
• Metadatos de extremo a extremo: ¿Cómo admite la arquitectura el flujo integrado de metadatos de extremo a extremo?
En particular, ¿el acceso al significado y al contexto está diseñado en la arquitectura? ¿Cómo responden los consumidores de datos a
preguntas básicas como "¿Qué significa este informe?" o "¿Qué significa esta métrica?"
• Linaje de datos verificable de extremo a extremo: ¿Los elementos expuestos a los usuarios comerciales son rastreables hasta la fuente?
sistemas de manera automatizada y mantenida? ¿Se identifica un sistema de registro para todos los datos?
6.2 Satisfacción del Cliente/Usuario
Las percepciones de la calidad de los datos impulsarán la satisfacción del cliente, pero la satisfacción también depende de otros factores, como la
comprensión de los datos por parte de los consumidores de datos y la capacidad de respuesta del equipo de operaciones a los problemas
identificados. La recopilación, la comprensión y la actuación en función de los comentarios de los clientes se pueden facilitar a través de reuniones
programadas regularmente con los representantes de los usuarios. Dicha interacción también puede ayudar al equipo del almacén a compartir
información sobre la hoja de ruta del lanzamiento y comprender cómo los consumidores de datos utilizan el almacén.
6.3 Acuerdos de nivel de servicio
Las expectativas comerciales y técnicas para los entornos deben especificarse en los acuerdos de nivel de servicio (SLA). A menudo, los requisitos
de tiempo de respuesta, retención de datos y disponibilidad difieren mucho entre las clases de necesidades comerciales y sus respectivos sistemas
de soporte (por ejemplo, ODS versus DW versus data mart).
6.4 Estrategia de informes
Asegúrese de que exista una estrategia de generación de informes dentro y en toda la cartera de BI. Una estrategia de informes incluye estándares,
procesos, directrices, mejores prácticas y procedimientos. Asegurará que los usuarios tengan información clara, precisa y oportuna. La estrategia de
presentación de informes debe abordar
• Acceso de seguridad para garantizar que solo los usuarios autorizados obtengan acceso a elementos de datos confidenciales
• Mecanismos de acceso para describir cómo los usuarios desean interactuar, informar, examinar o ver sus datos
• Tipo de comunidad de usuarios y herramienta apropiada para consumirla •
Naturaleza de los informes resumen, detallado, excepción así como frecuencia, tiempo, distribución y
formatos de almacenamiento
• Uso potencial de capacidades de visualización para proporcionar salida gráfica •
Compensaciones entre puntualidad y rendimiento
Los informes estándar deben evaluarse periódicamente para asegurarse de que siguen proporcionando valor, ya que solo ejecutar informes
genera costos de almacenamiento y procesamiento. Los procesos de implementación y mantenimiento y las actividades de gestión son
críticos. Alinear las herramientas de informes apropiadas con la comunidad empresarial es un factor crítico de éxito. Según el tamaño y la
naturaleza de la organización, probablemente se utilicen muchas herramientas de informes diferentes en una variedad de procesos.
Asegúrese de que la audiencia sea capaz de hacer el mejor uso de las herramientas de informes; los usuarios más sofisticados tendrán
demandas cada vez más complejas. Mantenga una matriz de decisiones basada en estas demandas para determinar actualizaciones o
futuras selecciones de herramientas.
La supervisión y el control de la gobernanza de las fuentes de datos también son vitales. Asegúrese de que los niveles adecuados de datos
se proporcionen de forma segura para el personal autorizado y que los datos de suscripción sean accesibles de acuerdo con lo acordado.
niveles
Un Centro de Excelencia puede proporcionar capacitación, conjuntos de inicio, mejores prácticas de diseño, consejos y trucos de fuentes de
datos y otras soluciones puntuales o artefactos para ayudar a empoderar a los usuarios comerciales hacia un modelo de autoservicio.
Además de la gestión del conocimiento, este centro puede proporcionar comunicaciones oportunas entre las comunidades de desarrolladores,
diseñadores, analistas y usuarios suscriptores.
6.5 Métricas
6.5.1 Métricas de uso
Las métricas de uso de DW suelen incluir la cantidad de usuarios registrados, así como los usuarios conectados o los usuarios conectados
concurrentes. Estas métricas muestran cuántas personas dentro de la organización están utilizando el almacén de datos.
La cantidad de cuentas de usuario con licencia para cada herramienta es un gran comienzo, especialmente para los auditores. Sin embargo,
cuántos realmente se conectan con esa herramienta es una mejor medida, y cuántas consultas (o consultas equivalentes) envía una
comunidad de usuarios por período de tiempo es una medida técnica aún mejor, especialmente para la planificación de la capacidad. Permita
múltiples métricas de análisis, como usuarios de auditoría, capacidad de consulta de usuario generada y consumo
usuarios
6.5.2 Porcentajes de cobertura del área temática
Los porcentajes de cobertura del área temática miden la cantidad del almacén (desde una perspectiva de topología de datos) a la que
accede cada departamento. También destacan qué datos se comparten entre departamentos y cuáles no, pero podrían serlo.
414 • DMBOK2
La asignación de fuentes operativas a objetivos es otra extensión natural, que hace cumplir y valida el linaje y los metadatos ya recopilados, y puede
proporcionar un análisis de penetración para qué sistemas de origen están en uso analítico por qué departamentos. Esto puede ayudar a centrar
los esfuerzos de ajuste en esas consultas analíticas de alto impacto al mitigar cualquier cambio en los objetos de origen muy utilizados.
6.5.3 Métricas de respuesta y rendimiento
La mayoría de las herramientas de consulta miden el tiempo de respuesta. Recupere métricas de respuesta o rendimiento de las herramientas.
Estos datos informarán las métricas sobre el número y tipo de usuarios.
Coseche los tiempos de carga para cada producto de datos en formato sin procesar de los procesos de población. Estos también deben expresarse
como un porcentaje del soporte esperado: por lo tanto, un mercado que se espera que se actualice diariamente y se cargue en una ventana de
cuatro horas es 100 % compatible cuando se carga en cuatro horas. Aplique este proceso también a todos los extractos generados para el
procesamiento posterior.
La mayoría de las herramientas retendrán, en un registro o repositorio, registros de consultas, actualización de datos y tiempos de extracción de
datos para los objetos proporcionados a los usuarios. Divida estos datos en objetos programados y ejecutados, y expréselos como recuentos sin
procesar tanto de intentos como de éxito. Es probable que los objetos muy populares o las consultas con un rendimiento deficiente necesiten
atención antes de que sufran las métricas de satisfacción. Esto puede guiar el análisis de defectos, la planificación del mantenimiento y la
planificación de la capacidad si un grupo de objetos falla con regularidad. La corrección puede variar según la herramienta, pero a veces crear o
eliminar un índice puede generar grandes mejoras. (Consulte el Capítulo 6.)
Un seguimiento natural de esto es la validación y el ajuste de los niveles de servicio. Ajuste los elementos que han fallado constantemente en la
próxima versión o, en ausencia de los fondos necesarios, se debe reducir el nivel de soporte.
7. Obras Citadas / Recomendadas
Adamson, Cristóbal. Dominar los agregados del almacén de datos: soluciones para el rendimiento del esquema en estrella. John Wiley and
Sons, 2006. Imprimir.
Adelman, Sid y Larissa T. Moss. Gestión de proyectos de almacén de datos. AddisonWesley Professional, 2000. Imprimir.
Adelman, Sid, Larissa Moss y Majid Abai. Estrategia de datos. AddisonWesley Professional, 2005. Imprimir.
Adelman, Sid, et al. Situaciones imposibles de almacenamiento de datos: soluciones de los expertos. AddisonWesley, 2002. Imprimir.
Aggarwal, Charu. Minería de datos: el libro de texto. Springer, 2015. Imprimir.
Biere, Mike. Inteligencia de Negocios para la Empresa. IBM Press, 2003. Impreso.
Biere, Mike. La nueva era de la inteligencia comercial empresarial: uso de análisis para lograr una ventaja competitiva global.
IBM Press, 2010. Impreso. IBM Press.
Brown, Meta S. Minería de datos para tontos. Para Dummies, 2014. Imprimir. Para Dummies.
Chorianopoulos, Antonios. CRM eficaz utilizando análisis predictivo. Wiley, 2016. Imprimir.
Delmater, Rhonda y Monte Hancock Jr. Explicación de la minería de datos; Una guía para gerentes sobre Business Intelligence centrada en el
cliente. Prensa Digital, 2001. Impreso.
Dyché, Jill. EData: convertir datos en información con almacenamiento de datos. AddisonWesley, 2000. Imprimir.
Eckerson, Wayne W. Paneles de rendimiento: medición, seguimiento y gestión de su negocio. Wiley, 2005. Imprimir.
Han, Jiawei, Micheline Kamber y Jian Pei. Minería de Datos: Conceptos y Técnicas. 3ra ed. Morgan Kaufmann, 2011.
Imprimir. El Ser de Morgan Kaufmann en Sistemas de Gestión de Datos.
Hastie, Trevor, Robert Tibshirani y Jerome Friedman. Los elementos del aprendizaje estadístico: minería de datos, inferencia y predicción. 2ª ed. Springer,
2011. Imprimir. Serie Springer en Estadística.
Hill, Thomas y Paul Lewicki. Estadística: Métodos y Aplicaciones. Statsoft, Inc., 2005. Imprimir.
Howson, Cindy. Business Intelligence exitosa: Libere el valor de BI y Big Data. 2ª ed. McgrawHill Osborne Media, 2013. Imprimir.
Imhoff, Claudia, Lisa Loftis y Jonathan G. Geiger. Creación de la empresa centrada en el cliente: técnicas de almacenamiento de datos para
respaldar la gestión de relaciones con el cliente. John Wiley and Sons, 2001. Imprimir.
Imhoff, Claudia, Nicholas Galemmo y Jonathan G. Geiger. Dominar el Diseño de Almacenes de Datos: Técnicas Relacionales y Dimensionales.
John Wiley and Sons, 2003. Imprimir.
Inmon, WH, Claudia Imhoff y Ryan Sousa. La Fábrica de Información Corporativa. 2ª ed. John Wiley and Sons, 2000.
Imprimir.
Inmon, WH y Krish Krishnan. Construcción del almacén de datos no estructurados. Publicaciones de Technics, LLC., 2011. Imprimir.
Josey, Andrés. TOGAF Versión 9.1 Enterprise Edition: Introducción. El Grupo Abierto, 2011. Kindle. Libro blanco del grupo abierto.
Kaplan, Robert S y David P. Norton. El cuadro de mando integral: traducir la estrategia en acción. Harvard Business Review Press, 1996. Kindle.
Kimball, Ralph y Margy Ross. El kit de herramientas de almacenamiento de datos: la guía definitiva para el modelado dimensional. edición 3d.
Wiley, 2013. Imprimir.
Kimball, Ralph y col. El kit de herramientas del ciclo de vida del almacén de datos. 2ª ed. Wiley, 2008. Imprimir.
Kimball, Ralph. El kit de herramientas ETL del almacén de datos: técnicas prácticas para extraer, limpiar, conformar y entregar datos. Amazon
Digital Services, Inc., 2007. Kindle.
Linoff, Gordon S. y Michael JA Berry. Técnicas de minería de datos: para marketing, ventas y gestión de relaciones con los clientes. 3ra ed. Wiley,
2011. Imprimir.
Linstedt, Dan. Documento oficial de estándares de Data Vault (Versión 1.0) (Arquitectura de almacenamiento de datos). Amazon Digital Services, Inc.,
2012. Kindle.
Loukides, Mike. ¿Qué es la ciencia de datos? O'Reilly Media, 2012. Kindle.
Lublinsky, Boris, Kevin T. Smith y Alexey Yakubovich. Soluciones profesionales de Hadoop. Wrox, 2013. Imprimir.
Malik, Shadan. Paneles empresariales: diseño y mejores prácticas para TI. Wiley, 2005. Imprimir.
Morris, Enrique. “Aplicaciones analíticas y gestión del rendimiento empresarial”. Revista DM Review, marzo de 1999. http://bit.ly/2rRrP4x.
Moss, Larissa T. y Shaku Atre. Hoja de ruta de Business Intelligence: el ciclo de vida completo del proyecto para aplicaciones de soporte de decisiones.
AddisonWesley Professional, 2003. Imprimir.
416 • DMBOK2
Ponniah, Paulraj. Fundamentos de almacenamiento de datos: una guía completa para profesionales de TI. WileyInterscience, 2001. Imprimir.
Provost, Foster y Tom Fawcett. Ciencia de datos para empresas: lo que necesita saber sobre la minería de datos y el pensamiento analítico de datos.
O'Reilly Media, 2013. Imprimir.
Reeves, Laura L. Una guía para administradores de almacenamiento de datos. Wiley, 2009. Imprimir.
Russell, Matthew A. Minería de la web social: minería de datos Facebook, Twitter, LinkedIn, Google+, GitHub y más. 2ª ed. O'Reilly Media, 2013. Imprimir.
Silverston, Len y Paul Agnew. Libro de recursos del modelo de datos Volumen 3: Patrones universales para el modelado de datos. Wiley, 2008. Imprimir.
Simón, Alan. Gestión de datos e inteligencia empresarial empresarial moderna: una hoja de ruta para directores, gerentes y arquitectos de TI. Morgan
Kaufmann, 2014. Imprimir.
Thomsen, Erik. Soluciones OLAP: Construcción de Sistemas de Información Multidimensionales. 2ª ed. Wiley, 2002. Imprimir.
Vitt, Elizabeth, Michael Luckevich y Stacia Misner. Inteligencia de Negocio. Microsoft Press, 2008. Imprimir. Referencia del desarrollador.
WAGmob. Big Data y Hadoop. WAGmob, 2013. Kindle.
Wremble, Robert y Christian Koncilia. Data Warehouses y Olap: Conceptos, Arquitecturas y Soluciones. IGI Global, 2006. Imprimir.
CAPÍTULO 1 2
Gestión de metadatos
Datos Modelado de datos
Arquitectura & Diseño
Almacenamiento de datos
Calidad de datos
y operaciones
Datos Datos
metadatos
Gobernancia Seguridad
Almacenamiento de datos Integración de datos &
& Negocio interoperabilidad
Inteligencia
Referencia Documento
& Maestro & Contenido
Datos Gestión
Marco de gestión de datos DAMADMBOK2
Copyright © 2017 por DAMA Internacional
1. Introducción
T
a definición más común de metadatos, "datos sobre datos", es engañosamente simple. El tipo de
la información que se puede clasificar como metadatos es muy variada. Los metadatos incluyen información sobre
procesos técnicos y comerciales, reglas y restricciones de datos, y estructuras de datos lógicos y físicos. Describe
los datos en sí (p. ej., bases de datos, elementos de datos, modelos de datos), los conceptos que representan los datos (p.
ej., procesos comerciales, sistemas de aplicación, código de software, infraestructura tecnológica) y las conexiones
(relaciones) entre los datos y los conceptos. Los metadatos ayudan a una organización a comprender sus datos, sus sistemas,
417
418 • DMBOK2
y sus flujos de trabajo. Permite la evaluación de la calidad de los datos y es parte integral de la gestión de bases de datos y otras aplicaciones.
Contribuye a la capacidad de procesar, mantener, integrar, asegurar, auditar y controlar otros datos.
Para comprender el papel fundamental de los metadatos en la gestión de datos, imagine una gran biblioteca, con cientos de miles de libros y
revistas, pero sin un catálogo de fichas. Sin un catálogo de tarjetas, es posible que los lectores ni siquiera sepan cómo comenzar a buscar un libro
específico o incluso un tema específico. El catálogo de fichas no solo proporciona la información necesaria (qué libros y materiales posee la
biblioteca y dónde están guardados), sino que también permite a los usuarios encontrar materiales utilizando diferentes puntos de partida (área
temática, autor o título). Sin el catálogo, encontrar un libro específico sería difícil, si no imposible. Una organización sin Metadatos es como una
biblioteca sin catálogo de fichas.
Los metadatos son esenciales para la gestión de datos, así como para el uso de datos (consulte las múltiples referencias a los metadatos en DAMA
DMBOK). Todas las grandes organizaciones producen y utilizan una gran cantidad de datos. En una organización, diferentes personas tendrán
diferentes niveles de conocimiento de los datos, pero ninguna persona sabrá todo acerca de los datos.
Esta información debe estar documentada o la organización corre el riesgo de perder valiosos conocimientos sobre sí misma.
Los metadatos proporcionan el medio principal para capturar y administrar el conocimiento organizacional sobre los datos.
Sin embargo, la gestión de metadatos no es solo un desafío de gestión del conocimiento; también es una necesidad de la gestión de riesgos. Los
metadatos son necesarios para garantizar que una organización pueda identificar datos privados o confidenciales y que pueda administrar el ciclo
de vida de los datos para su propio beneficio y para cumplir con los requisitos de cumplimiento y minimizar el riesgo.
exposición.
Sin metadatos confiables, una organización no sabe qué datos tiene, qué representan, dónde se originan, cómo se mueven a través de los sistemas,
quién tiene acceso a ellos o qué significa que los datos sean de alta calidad. Sin metadatos, una organización no puede administrar sus datos como
un activo. De hecho, sin metadatos, es posible que una organización no pueda administrar sus datos en absoluto.
A medida que la tecnología ha evolucionado, la velocidad a la que se generan los datos también ha aumentado. Los metadatos técnicos se han
vuelto parte integral de la forma en que se mueven e integran los datos. El estándar de registro de metadatos de ISO, ISO/IEC 11179, está
destinado a permitir el intercambio de datos impulsado por metadatos en un entorno heterogéneo, basado en definiciones exactas de datos. Los
metadatos presentes en XML y otros formatos permiten el uso de los datos. Otros tipos de etiquetado de metadatos permiten el intercambio de
datos conservando los indicadores de propiedad, los requisitos de seguridad, etc. (Consulte el Capítulo 8).
Al igual que otros datos, los metadatos requieren gestión. A medida que aumenta la capacidad de las organizaciones para recopilar y almacenar
datos, el papel de los metadatos en la gestión de datos crece en importancia. Para estar basada en datos, una organización
debe estar basado en metadatos.
GESTIÓN DE METADATOS • 419
Gestión de metadatos
Definición: actividades de planificación, implementación y control para permitir el acceso a metadatos integrados de alta
calidad.
Metas:
1. Proporcionar comprensión organizacional de los términos comerciales y su uso.
2. Recopilar e integrar metadatos de diversas fuentes.
3. Proporcione una forma estándar de acceder a los metadatos.
4. Garantice la calidad y la seguridad de los metadatos.
Negocio
Conductores
Entradas: Actividades: 1. Entregables:

• Negocio Definir la estrategia de metadatos (P) •
Estrategia de metadatos
Requisitos 2. Comprender los requisitos de los metadatos
• Estándares de metadatos
• Problemas de metadatos • Arquitectura de metadatos
(PAG)
• Arquitectura de datos • metamodelo
1. Requisitos del usuario comercial 2.
• Metadatos comerciales • Metadatos unificados
Requisitos del usuario técnico 3.
• Metadatos técnicos • Almacenes de metadatos
Definición de la arquitectura de metadatos (P)
• Procesar metadatos •
1. Crear MetaModelo (D) Linaje de datos
• •
Metadatos operativos 2. Aplicar estándares de metadatos (C) Análisis de Impacto
• Dato de governancia 3. Administrar almacenes de metadatos (C) • Análisis de Dependencia
metadatos 4. Crear y mantener metadatos (O)
• Control de Metadatos
1. Integrar metadatos (O) Proceso
2. Distribuir y entregar metadatos (O)
5. Consultar, informar y analizar metadatos (O)
Proveedores: Participantes: • Consumidores:
• Datos comerciales
Administradores de •
Desarrolladores de aplicaciones
• datos Administradores Analista
de proyectos • Arquitectos • Integradores de datos
Administradores •
Administradores de datos • Gobernanza •de datos
de datos Analistas • Usuarios comerciales
Cuerpos comerciales • Analistas de sistemas • Trabajadores del

conocimiento • Clientes y
• Modeladores de datos •
Colaboradores
Base de datos
• Científicos de datos
Administradores Técnico
• Periodistas de datos
Conductores
Técnicas: • Linaje Herramientas: Métricas: •
e impacto de los datos Repositorio de metadatos • Cobertura de metadatos
Análisis • Herramientas de gestión Tanteador
Metadatos para Big Data • Repositorios de metadatos en otros • Repositorio de metadatos
Ingerir Herramientas Contribución •
Informes de uso de metadatos • Calidad
de metadatos
Tanteador
(P) Planificación, (C) Control, (D) Desarrollo, (O) Operaciones
Figura 84 Diagrama de contexto: Metadatos
420 • DMBOK2
1.1 Impulsores comerciales
Los datos no se pueden gestionar sin metadatos. Además, los propios metadatos deben gestionarse. Los metadatos confiables y bien administrados
ayudan a:
• Aumentar la confianza en los datos al proporcionar contexto y permitir la medición de la calidad de los datos • Aumentar el valor de
la información estratégica (por ejemplo, datos maestros) al permitir múltiples usos • Mejorar la eficiencia operativa al identificar datos
y procesos redundantes
• Evitar el uso de datos desactualizados o incorrectos
• Reducir el tiempo de investigación orientada a datos
• Mejore la comunicación entre los consumidores de datos y los profesionales de TI. • Cree un análisis
de impacto preciso, reduciendo así el riesgo de fracaso del proyecto. • Mejore el tiempo de
comercialización al reducir el tiempo del ciclo de vida del desarrollo del sistema. de datos
contexto, historia y origen • Apoyar
el cumplimiento normativo
Los metadatos ayudan a representar la información de manera uniforme, optimizan las capacidades del flujo de trabajo y protegen la información
confidencial, en particular cuando se requiere el cumplimiento normativo.
Las organizaciones obtienen más valor de sus activos de datos si sus datos son de alta calidad. La calidad de los datos depende de la gobernanza.
Debido a que explica los datos y procesos que permiten que las organizaciones funcionen, los metadatos son fundamentales para el gobierno de datos.
Si los metadatos son una guía para los datos de una organización, entonces deben administrarse bien.
Los metadatos mal administrados conducen a:
• Datos redundantes y procesos de administración de datos •
Diccionarios, repositorios y otros almacenamientos de metadatos replicados y redundantes
• Definiciones inconsistentes de elementos de datos y riesgos asociados con el uso indebido de datos
• Fuentes y versiones de metadatos que compiten y están en conflicto, lo que reduce la confianza de los datos
consumidores
• Dudas sobre la fiabilidad de los Metadatos y datos
La gestión de metadatos bien ejecutada permite una comprensión coherente de los recursos de datos y un desarrollo interorganizacional más eficiente.
1.2 Objetivos y principios
Los objetivos de la gestión de metadatos incluyen:
• Documentar y administrar el conocimiento organizacional de la terminología comercial relacionada con los datos para
asegurar que las personas entiendan el contenido de los datos y puedan usar los datos de manera consistente
• Recopilar e integrar metadatos de diversas fuentes para garantizar que las personas entiendan las similitudes y
diferencias entre los datos de diferentes partes de la organización
• Asegurar la calidad, consistencia, vigencia y seguridad de los Metadatos • Proporcionar
formas estándar para hacer que los Metadatos sean accesibles para los consumidores de Metadatos (personas, sistemas y
procesos)
• Establecer o hacer cumplir el uso de estándares técnicos de metadatos para permitir el intercambio de datos
La implementación de una solución de Metadatos exitosa sigue estos principios rectores:
• Compromiso organizacional: Asegurar el compromiso organizacional (apoyo de la alta dirección y
financiación) a la gestión de metadatos como parte de una estrategia general para gestionar los datos como un activo empresarial.
• Estrategia: desarrollar una estrategia de metadatos que dé cuenta de cómo se crearán, mantendrán, integrarán y accederán a los metadatos.
La estrategia debe impulsar los requisitos, que deben definirse antes de evaluar, comprar e instalar productos de gestión de metadatos.
La estrategia de metadatos debe alinearse con las prioridades comerciales.
• Perspectiva empresarial: adopte una perspectiva empresarial para garantizar la extensibilidad futura, pero implemente
a través de la entrega iterativa e incremental para aportar valor.
• Socialización: Comunicar la necesidad de Metadatos y la finalidad de cada tipo de Metadatos;
la socialización del valor de los metadatos fomentará el uso empresarial y, lo que es más importante, la contribución de la experiencia
empresarial.
• Acceso: asegúrese de que los miembros del personal sepan cómo acceder y utilizar los metadatos.
• Calidad: reconozca que los metadatos a menudo se producen a través de procesos existentes (modelado de datos, SDLC, definición de procesos
comerciales) y responsabilice a los propietarios de los procesos por la calidad de los metadatos.
• Auditoría: establezca, aplique y audite estándares para metadatos para simplificar la integración y habilitar el uso.
• Mejora: Crear un mecanismo de retroalimentación para que los consumidores puedan informar a la Gestión de Metadatos
equipo de metadatos incorrectos o desactualizados.
1.3 Conceptos esenciales
1.3.1 Metadatos frente a datos
Como se indicó en la introducción del capítulo, los metadatos son un tipo de datos y deben gestionarse como tales. Una pregunta que enfrentan algunas
organizaciones es dónde trazar la línea entre los datos que no son metadatos y los datos que son metadatos. Conceptualmente, esta línea está
relacionada con el nivel de abstracción que representan los datos. Por ejemplo, al informar sobre la publicación de la vigilancia de la Administración de
Seguridad Nacional de EE. UU. sobre el uso del teléfono por parte de las personas en EE.
422 • DMBOK2
los datos comprendían únicamente el contenido de las conversaciones telefónicas. El sentido común reconoce que los números de teléfono y
la duración de las llamadas telefónicas también son datos simples.70
Una regla general podría ser que los metadatos de una persona son los datos de otra. Incluso algo que parece metadatos (p. ej., una lista de
nombres de columnas) puede ser solo datos simples, si, por ejemplo, estos datos fueron la entrada para un análisis destinado a comprender el
contenido de los datos en diferentes organizaciones.
Para administrar sus metadatos, las organizaciones no deben preocuparse por las distinciones filosóficas. En su lugar, deben definir los
requisitos de metadatos centrados en para qué necesitan los metadatos (para crear nuevos datos, comprender los datos existentes, permitir el
movimiento entre sistemas, acceder a datos, compartir datos) y obtener datos de origen para cumplir con estos requisitos.
1.3.2 Tipos de Metadatos
Los metadatos a menudo se clasifican en tres tipos: comerciales, técnicos y operativos. Estas categorías permiten a las personas comprender
el rango de información que se encuentra bajo el paraguas general de los metadatos, así como las funciones a través de las cuales se producen
los metadatos. Dicho esto, las categorías también podrían generar confusión, especialmente si las personas quedan atrapadas en preguntas
sobre a qué categoría pertenece un conjunto de metadatos o quién se supone que debe usarlo. Es mejor pensar en estas categorías en relación
con el origen de los metadatos, en lugar de cómo se utilizan. En relación con el uso, las distinciones entre los tipos de metadatos no son
estrictas. Uso del personal técnico y operativo
Metadatos 'comerciales' y viceversa.
Fuera de la tecnología de la información, por ejemplo, en bibliotecas o ciencias de la información, los metadatos se describen utilizando un
conjunto diferente de categorías:
• Los metadatos descriptivos (p. ej., título, autor y tema) describen un recurso y permiten su identificación
y recuperación.
• Los metadatos estructurales describen las relaciones dentro y entre los recursos y sus componentes.
(por ejemplo, número de páginas, número de capítulos).
• Los metadatos administrativos (p. ej., números de versión, fechas de archivo) se utilizan para administrar los recursos en su
ciclo vital.
Estas categorías pueden ayudar a informar el proceso de definición de los requisitos de metadatos.
1.3.2.1 Metadatos comerciales
Business Metadata se centra principalmente en el contenido y la condición de los datos e incluye detalles relacionados con el gobierno de datos.
Los metadatos comerciales incluyen los nombres no técnicos y las definiciones de conceptos, áreas temáticas, entidades y atributos; tipos de
datos de atributos y otras propiedades de atributos; descripciones de rango; cálculos;
70 Col, David. “Matamos personas basándonos en los metadatos”. Revisión de libros de Nueva York. 10 de mayo de 2014. http://bit.ly/2sV1ulS.
algoritmos y reglas de negocio; valores de dominio válidos y sus definiciones. Ejemplos de metadatos comerciales
incluir:
• Definiciones y descripciones de conjuntos de datos, tablas y columnas • Reglas
comerciales, reglas de transformación, cálculos y derivaciones
• Modelos de datos
• Reglas de calidad de datos y resultados de medición •
Calendarios según los cuales se actualizan los datos •
Procedencia y linaje de los datos
• Estándares de datos
• Designaciones del sistema de registro de elementos de datos
• Restricciones de valores válidos
• Información de contacto de las partes interesadas (p. ej., propietarios de datos, administradores de
datos) • Nivel de seguridad/privacidad de los datos
• Problemas conocidos con los datos
• Notas de uso de datos
1.3.2.2 Metadatos técnicos
Los metadatos técnicos proporcionan información sobre los detalles técnicos de los datos, los sistemas que almacenan datos y los procesos que
los mueven dentro y entre sistemas. Los ejemplos de metadatos técnicos incluyen:
• Nombres de columnas y tablas de bases de datos físicas •
Propiedades de columnas • Propiedades de objetos de bases
de datos • Permisos de acceso • Reglas CRUD (crear,
reemplazar, actualizar y eliminar) de datos • Modelos de
datos físicos, incluidos nombres de tablas de datos, claves e índices •
Relaciones documentadas entre los datos modelos y los activos físicos • Detalles del trabajo
ETL
• Definiciones de esquemas de formato de archivo
• Documentación de mapeo de origen a destino •
Documentación de linaje de datos, incluida información de impacto de cambios ascendentes y descendentes • Nombres y
descripciones de programas y aplicaciones • Programaciones y dependencias de trabajo del ciclo de actualización de contenido
• Reglas de recuperación y copia de seguridad • Derechos de acceso a datos, grupos, roles
1.3.2.3 Metadatos operativos
Los metadatos operativos describen los detalles del procesamiento y el acceso a los datos. Por ejemplo:
424 • DMBOK2
• Registros de ejecución de trabajos para programas por
lotes • Historial de extractos y resultados
• Programar anomalías
• Resultados de auditoría, balance, medidas de control
• Registros de
errores • Patrones de acceso a informes y consultas, frecuencia y tiempo de ejecución
• Plan y ejecución de mantenimiento de parches y versiones, nivel de parche actual • Respaldo,
retención, fecha de creación, provisiones de recuperación ante desastres • Requisitos y provisiones
de SLA • Patrones volumétricos y de uso • Datos reglas de archivo y retención, archivos relacionados
• Criterios de depuración • Reglas y acuerdos de intercambio de datos • Funciones y responsabilidades
técnicas, contactos
1.3.3 Norma de registro de metadatos ISO/IEC 11179
El estándar de registro de metadatos de ISO, ISO/IEC 11179, proporciona un marco para definir un registro de metadatos. Está diseñado
para permitir el intercambio de datos impulsado por metadatos, basado en definiciones exactas de datos, comenzando con elementos de
datos. El estándar está estructurado en varias partes:
• Parte 1: Marco para la Generación y Estandarización de Elementos de Datos
• Parte 3: Atributos básicos de los elementos de datos
• Parte 4: Reglas y Directrices para la Formulación de Definiciones de Datos
• Parte 5: Principios de nomenclatura e identificación para elementos de datos •
Parte 6: Registro de elementos de datos
1.3.4 Metadatos para datos no estructurados
Por su naturaleza, todos los datos tienen alguna estructura, aunque no todos están formalmente estructurados en las filas, columnas y
registros familiares de las bases de datos relacionales. Cualquier dato que no esté en una base de datos o archivo de datos, incluidos
documentos u otros medios, se considera información no estructurada. (Consulte los capítulos 9 y 14).
Los metadatos son tan esenciales para la gestión de datos no estructurados como lo son para la gestión de datos estructurados, quizás
incluso más. Piense de nuevo en la analogía del catálogo de fichas de la introducción del capítulo. Los libros y revistas de una biblioteca son
buenos ejemplos de datos no estructurados. El uso principal de los Metadatos en un catálogo de fichas es encontrar los materiales que se
buscan, cualquiera que sea su formato.
Los metadatos para datos no estructurados incluyen metadatos descriptivos, como información de catálogo y palabras clave de tesauro;
Metadatos estructurales como etiquetas, estructuras de campo, formato; Metadatos administrativos, como fuentes, calendarios de
actualización, derechos de acceso e información de navegación; Metadatos bibliográficos, como el catálogo de la biblioteca
entradas; Metadatos de mantenimiento de registros, como políticas de retención; y preservación Metadatos, tales como almacenamiento, condición
de archivo y reglas para la conservación. (Consulte el Capítulo 9.)
Si bien la mayoría de las afirmaciones sobre los metadatos para datos no estructurados están conectadas con las preocupaciones tradicionales de
gestión de contenido, están surgiendo nuevas prácticas en torno a la gestión de datos no estructurados en lagos de datos. Las organizaciones que
desean aprovechar los lagos de datos, utilizando plataformas de Big Data como Hadoop, descubren que deben catalogar los datos ingeridos para
permitir el acceso posterior. La mayoría implementa procesos para recopilar metadatos como parte de la ingestión de datos. Se debe recopilar un
conjunto mínimo de atributos de metadatos sobre cada objeto ingerido en el lago de datos (p. ej., nombre, formato, fuente, versión, fecha de recepción,
etc.). Esto produce un catálogo de contenidos del lago de datos.
1.3.5 Fuentes de metadatos
Como debería quedar claro a partir de los tipos de metadatos, los metadatos se pueden recopilar de muchas fuentes diferentes.
Además, si los metadatos de las aplicaciones y las bases de datos han sido bien administrados, simplemente pueden recopilarse e integrarse. Sin
embargo, la mayoría de las organizaciones no administran bien los metadatos a nivel de la aplicación, porque los metadatos a menudo se crean
como un subproducto del procesamiento de la aplicación y no como un producto final (es decir, no se crean pensando en el consumo). Al igual que
con otras formas de datos, hay mucho trabajo en la preparación de metadatos antes de que puedan integrarse.
La mayoría de los metadatos operativos se generan a medida que se procesan los datos. La clave para usar estos metadatos es recopilarlos en una
forma utilizable y asegurarse de que los responsables de interpretarlos tengan las herramientas que necesitan para hacerlo. Tenga en cuenta que la
interpretación de datos en lugares como los propios registros de errores requiere metadatos que describan los registros.
De manera similar, una gran parte de los metadatos técnicos se pueden recopilar de los objetos de la base de datos.
Es posible aplicar ingeniería inversa al conocimiento sobre los datos de los sistemas existentes y recopilar metadatos comerciales de los diccionarios
de datos, modelos y documentación de procesos existentes (Loshin, 2001; Aiken, 1995), pero hacerlo conlleva riesgos. El mayor riesgo es no saber
cuánto cuidado se tuvo para desarrollar y refinar las definiciones en primer lugar. Si las definiciones están subdesarrolladas o son ambiguas, entonces
no proporcionarán a los consumidores de datos la información que necesitan para comprender los datos que están utilizando.
Es mejor ser intencional en el desarrollo de definiciones que simplemente aceptar las existentes. El desarrollo de definiciones requiere tiempo y el
conjunto de habilidades adecuado (p. ej., habilidades de redacción y facilitación). Esta es la razón por la cual el desarrollo de metadatos comerciales
requiere administración. (Consulte el Capítulo 3.)
Gran parte de los metadatos técnicos necesarios para gestionar las bases de datos y los metadatos empresariales necesarios para utilizar los datos
se pueden recopilar y desarrollar como parte del trabajo del proyecto. Por ejemplo, el proceso de modelado de datos requiere discusiones sobre el
significado de los elementos de datos y la relación entre ellos. El conocimiento compartido durante dichas discusiones debe capturarse y prepararse
para su uso en diccionarios de datos, glosarios comerciales y otros repositorios. Los propios modelos de datos incluyen detalles importantes sobre
las características físicas de los datos.
Se debe asignar tiempo para garantizar que los artefactos del proyecto contengan metadatos de alta calidad que se alineen con los estándares
empresariales.
426 • DMBOK2
Los metadatos comerciales bien definidos se pueden reutilizar de un proyecto a otro y pueden impulsar una comprensión consistente de cómo se representan
los conceptos comerciales en diferentes conjuntos de datos. Como parte del desarrollo intencional de metadatos para que puedan reutilizarse, una
organización también puede planificar la integración de metadatos. Por ejemplo, puede desarrollar un inventario de sistemas y todos los metadatos
relacionados con un sistema en particular pueden etiquetarse con el mismo sistema.
identificador
La creación de metadatos por su propio bien rara vez funciona bien. La mayoría de las organizaciones no financiarán este tipo de esfuerzo e, incluso cuando
lo hagan, es poco probable que implementen procesos de mantenimiento. En este sentido, como en otros, los metadatos son como otros datos: deben
crearse como el producto de un proceso bien definido, utilizando herramientas que respaldarán su calidad general. Los administradores y otros profesionales
de la gestión de datos deben asegurarse de que existan procesos para mantener los metadatos relacionados con estos procesos. Por ejemplo, si una
organización recopila metadatos críticos de sus modelos de datos, debe asegurarse de que exista un proceso de gestión de cambios para mantener los
modelos actualizados.
Para dar una idea de la amplitud de los metadatos en cualquier organización, aquí se describe una variedad de fuentes, en orden alfabético en lugar de
prioritario.
1.3.5.1 Repositorios de metadatos de aplicaciones
Un repositorio de metadatos se refiere a las tablas físicas en las que se almacenan los metadatos. A menudo, estos están integrados en herramientas de
modelado, herramientas de BI y otras aplicaciones. A medida que una organización madure, querrá integrar metadatos de repositorios en estas aplicaciones
para permitir que los consumidores de datos vean la amplitud de la información.
1.3.5.2 Glosario empresarial
El propósito de un glosario empresarial es documentar y almacenar los conceptos y la terminología empresarial de una organización, las definiciones y las
relaciones entre esos términos.
En muchas organizaciones, el glosario empresarial es simplemente una hoja de cálculo. Sin embargo, a medida que las organizaciones maduran, a menudo
compran o crean glosarios que contienen información sólida y la capacidad de administrarla a lo largo del tiempo. Al igual que con todos los sistemas
orientados a datos, los glosarios comerciales deben diseñarse para tener en cuenta el hardware, el software, la base de datos, los procesos y los recursos
humanos con diferentes roles y responsabilidades. La aplicación del glosario de negocios está estructurada para cumplir con los requisitos funcionales de
las tres audiencias principales:
• Usuarios comerciales: los analistas de datos, los analistas de investigación, la gerencia y el personal ejecutivo usan el negocio
glosario para comprender la terminología y los datos.
• Administradores de datos: los administradores de datos utilizan el glosario comercial para administrar el ciclo de vida de los términos y
definiciones y mejorar el conocimiento de la empresa mediante la asociación de activos de datos con términos del glosario; por ejemplo,
vincular términos a métricas comerciales, informes, análisis de calidad de datos o componentes tecnológicos.
Los administradores de datos plantean problemas de terminología y uso y ayudan a resolver las diferencias en toda la organización.
• Usuarios técnicos : los usuarios técnicos usan el glosario de negocios para hacer arquitectura, diseño de sistemas y
decisiones de desarrollo y realizar análisis de impacto.
El glosario de negocios debe capturar atributos de términos de negocios tales como:
• Nombre del término, definición, acrónimo o abreviatura y cualquier sinónimo • Unidad de
negocio y/o aplicación responsable de administrar los datos asociados con la terminología • Nombre de la persona que identifica el
término y fecha de actualización • Asociación de categorización o taxonomía para el término (negocio asociación funcional) •
Definiciones en conflicto que necesitan resolución, naturaleza del problema, cronograma de acción • Malentendidos comunes en los
términos • Algoritmos que respaldan las definiciones • Linaje • Fuente oficial o autorizada para los datos que respaldan el término
Cada implementación de glosario empresarial debe tener un conjunto básico de informes para respaldar los procesos de gobierno.
Se recomienda que las organizaciones no 'impriman el glosario' porque el contenido del glosario no es estático. Los administradores de datos son
generalmente responsables del desarrollo, uso, operaciones e informes del glosario. Los informes incluyen el seguimiento de nuevos términos y
definiciones que aún no se han revisado, aquellos en estado pendiente y aquellos a los que les faltan definiciones u otros atributos. (Consulte la
Sección 6.4.)
La facilidad de uso y la funcionalidad pueden variar ampliamente. Cuanto más simple y sencilla sea la búsqueda en el glosario empresarial, más
probable será que se utilice el contenido del glosario. Sin embargo, la característica más importante de un glosario es que contiene
contenido robusto.
1.3.5.3 Herramientas de inteligencia empresarial (BI)
Las herramientas de Business Intelligence producen varios tipos de metadatos relevantes para el diseño de Business Intelligence, incluida
información general, clases, objetos, elementos derivados y calculados, filtros, informes, campos de informes, diseño de informes, usuarios de
informes, frecuencia de distribución de informes y canales de distribución de informes.
1.3.5.4 Herramientas de gestión de la configuración
Las herramientas o bases de datos de administración de configuración (CMDB) brindan la capacidad de administrar y mantener metadatos
específicamente relacionados con los activos de TI, las relaciones entre ellos y los detalles contractuales del activo. Cada activo en la base de
datos de CMDB se denomina elemento de configuración (CI). Los metadatos estándar se recopilan y administran para cada tipo de CI. Muchas
organizaciones integran la CMDB con los procesos de gestión de cambios para identificar los activos o aplicaciones relacionados afectados por un
cambio en un activo específico. Los repositorios proporcionan mecanismos para vincular los activos en el repositorio de metadatos con los detalles
de implementación física reales en CMDB para brindar una imagen completa de los datos y las plataformas.
428 • DMBOK2
1.3.5.5 Diccionarios de datos
Un diccionario de datos define la estructura y el contenido de los conjuntos de datos, a menudo para una sola base de datos, aplicación o almacén. El diccionario
se puede utilizar para gestionar los nombres, las descripciones, la estructura, las características, los requisitos de almacenamiento, los valores predeterminados,
las relaciones, la unicidad y otros atributos de cada elemento de datos de un modelo. También debe contener definiciones de tablas o archivos. Los diccionarios
de datos están integrados en herramientas de base de datos para la creación,
operación, manipulación de los datos contenidos en ellos. Para que estos metadatos estén disponibles para los consumidores de datos, deben extraerse de la
base de datos o de las herramientas de modelado. Los diccionarios de datos también pueden describir en terminología comercial qué elementos de datos están
disponibles para la comunidad, aprovisionados bajo qué restricciones de seguridad y aplicados en qué proceso comercial. Se puede ahorrar tiempo al definir,
publicar y mantener una capa semántica para informes y análisis aprovechando el contenido directamente desde el modelo lógico. Sin embargo, como se señaló
anteriormente, las definiciones existentes deben usarse con precaución, especialmente en una organización con un bajo nivel de madurez en torno a la gestión
de metadatos.
Muchos procesos comerciales, relaciones y terminologías clave se explican durante el desarrollo del modelo de datos. Esta información, capturada en el modelo
de datos lógicos, a menudo se pierde cuando las estructuras físicas se implementan en producción. Un diccionario de datos puede ayudar a garantizar que esta
información no se pierda por completo en la organización y que los modelos lógicos y físicos se mantengan de acuerdo después de la implementación de
producción.
1.3.5.6 Herramientas de integración de datos
Muchas herramientas de integración de datos se utilizan para ejecutables para mover datos de un sistema a otro o entre varios módulos dentro del mismo
sistema. Muchas de estas herramientas generan archivos transitorios, que pueden contener copias o copias derivadas de los datos. Estas herramientas son
capaces de cargar datos de varias fuentes y luego operar en los datos cargados, a través de la agrupación, reparación, reformateo, unión, filtrado u otras
operaciones, y luego generar datos de salida, que se distribuyen a las ubicaciones de destino. Documentan el linaje como datos a medida que se mueve entre
sistemas. Cualquier solución de Metadatos exitosa debería poder usar el linaje Metadatos a medida que se mueve a través de las herramientas de integración y
exponerlo como un linaje holístico de las fuentes reales.
a los destinos finales.
Las herramientas de integración de datos proporcionan interfaces de aplicación (API) para permitir que los repositorios de metadatos externos extraigan la
información de linaje y los metadatos de los archivos transitorios. Una vez que el repositorio de metadatos recopila la información, algunas herramientas pueden
generar un diagrama de linaje holístico para cualquier elemento de datos. Las herramientas de integración de datos también proporcionan metadatos sobre la
ejecución de varios trabajos de integración de datos, incluida la última ejecución exitosa, la duración y el estado del trabajo. Algunos repositorios de metadatos
pueden extraer las estadísticas de tiempo de ejecución de integración de datos y los metadatos y exponerlos junto con los elementos de datos. (Consulte los
capítulos 6 y 8).
1.3.5.7 Gestión de bases de datos y catálogos del sistema
Los catálogos de bases de datos son una fuente importante de metadatos. Describen el contenido de las bases de datos, junto con información de tamaño,
versiones de software, estado de implementación, tiempo de actividad de la red, tiempo de actividad de la infraestructura, disponibilidad,
y muchos otros atributos de metadatos operativos. La forma más común de base de datos es relacional. Las bases de datos relacionales administran los datos como
un conjunto de tablas y columnas, donde una tabla contiene una o más columnas, índices, restricciones, vistas y procedimientos. Una solución de metadatos debería
poder conectarse a las diversas bases de datos y conjuntos de datos y leer todos los metadatos expuestos por la base de datos. Algunas de las herramientas del
repositorio de metadatos pueden integrar los metadatos expuestos de las herramientas de administración del sistema para brindar una imagen más holística de los
activos físicos capturados.
1.3.5.8 Herramientas de gestión de mapeo de datos
Las herramientas de administración de mapeo se utilizan durante la fase de análisis y diseño de un proyecto para transformar los requisitos en especificaciones de
mapeo, que luego pueden ser consumidas directamente por una herramienta de integración de datos o utilizadas por los desarrolladores para generar código de
integración de datos. La documentación de mapeo también se mantiene a menudo en documentos de Excel en toda la empresa. Los proveedores ahora están
considerando repositorios centralizados para las especificaciones de mapeo con capacidades para realizar control de versiones y análisis de cambios entre versiones.
Muchas herramientas de mapeo se integran con herramientas de integración de datos para automatizar la generación de programas de integración de datos y la
mayoría puede intercambiar datos con otros repositorios de metadatos y datos de referencia. (Consulte el Capítulo 8.)
1.3.5.9 Herramientas de calidad de datos
Las herramientas de calidad de datos evalúan la calidad de los datos a través de reglas de validación. La mayoría de estas herramientas brindan la capacidad de
intercambiar puntajes de calidad y patrones de perfiles con otros repositorios de metadatos, lo que permite que el repositorio de metadatos adjunte los puntajes de
calidad a los activos físicos relevantes.
1.3.5.10 Directorios y Catálogos
Mientras que los diccionarios y glosarios de datos contienen información detallada sobre terminología, tablas y campos, un directorio o catálogo contiene información
sobre sistemas, fuentes y ubicaciones de datos dentro de una organización.
Un directorio de metadatos es particularmente útil para desarrolladores y superusuarios de datos, como equipos de administración de datos y analistas de datos, para
comprender el alcance de los datos en la empresa, ya sea para investigar problemas o encontrar información sobre cómo obtener nuevas aplicaciones.
1.3.5.11 Herramientas de mensajería de eventos
Las herramientas de mensajería de eventos mueven datos entre diversos sistemas. Para hacerlo, requieren una gran cantidad de metadatos. También generan
metadatos que describen este movimiento. Estas herramientas incluyen interfaces gráficas a través de las cuales gestionan la lógica del movimiento de datos. Pueden
exportar los detalles de implementación de las interfaces, la lógica de movimiento y las estadísticas de procesamiento a otros repositorios de metadatos.
430 • DMBOK2
1.3.5.12 Herramientas de modelado y repositorios
Las herramientas de modelado de datos se utilizan para construir varios tipos de modelos de datos: conceptuales, lógicos y físicos. Estas
herramientas producen metadatos relevantes para el diseño de la aplicación o el modelo del sistema, como áreas temáticas, entidades
lógicas, atributos lógicos, relaciones entre entidades y atributos, supertipos y subtipos, tablas, columnas, índices, claves primarias y
externas, restricciones de integridad y otros tipos de atribución a partir de los modelos. Los repositorios de metadatos pueden ingerir los
modelos creados por estas herramientas e integrar los metadatos importados en el repositorio. Las herramientas de modelado suelen ser
la fuente del contenido del diccionario de datos.
1.3.5.13 Repositorios de datos de referencia
Los datos de referencia documentan los valores comerciales y las descripciones de los diversos tipos de datos enumerados (dominios) y
su uso contextual en un sistema. Las herramientas utilizadas para administrar los datos de referencia también pueden administrar las
relaciones entre los diversos valores codificados dentro del mismo o entre dominios. Estos conjuntos de herramientas normalmente
brindan capacidades para enviar los Datos de referencia recopilados a un repositorio de Metadatos, que a su vez proporcionará
mecanismos para asociar los Datos de referencia al glosario comercial y a las ubicaciones donde se implementan físicamente como
columnas o campos.
1.3.5.14 Registros de servicios
Un registro de servicios administra y almacena la información técnica sobre los servicios y los puntos finales de los servicios desde una
perspectiva de arquitectura orientada a servicios (SOA). Por ejemplo, definiciones, interfaces, operaciones, parámetros de entrada y
salida, políticas, versiones y escenarios de uso de muestra. Algunos de los metadatos más importantes relacionados con los servicios
incluyen la versión del servicio, la ubicación del servicio, el centro de datos, la disponibilidad, la fecha de implementación, el puerto del
servicio, la dirección IP, el puerto de estadísticas, el tiempo de espera de conexión y el tiempo de espera de reintento de conexión. Los
registros de servicios se pueden consultar para satisfacer diversas necesidades, como mostrar una lista de todos los servicios disponibles,
servicios con una versión específica, servicios obsoletos o detalles sobre un servicio específico. Los servicios también se pueden revisar
para su posible reutilización. La información contenida en estos repositorios proporciona datos importantes sobre qué datos existen y
cómo se mueven entre varios sistemas o aplicaciones. Los metadatos en los repositorios de servicios se pueden extraer e incorporar con
los metadatos recopilados de otras herramientas para proporcionar una imagen completa de cómo se mueven los datos entre los distintos sistemas.
1.3.5.15 Otros almacenes de metadatos
Otros almacenes de metadatos incluyen listas especializadas como registros de eventos, listas de fuentes o interfaces, conjuntos de
códigos, léxicos, esquema espacial y temporal, referencia espacial y distribución de conjuntos de datos geográficos digitales, repositorios
de repositorios y reglas comerciales.
1.3.6 Tipos de arquitectura de metadatos
Al igual que otras formas de datos, los metadatos tienen un ciclo de vida. Conceptualmente, todas las soluciones de gestión de metadatos incluyen
capas arquitectónicas que corresponden a puntos del ciclo de vida de los metadatos:
• Creación y abastecimiento de metadatos •
Almacenamiento de metadatos en uno o más repositorios •
Integración de metadatos • Entrega de metadatos • Uso de
metadatos • Control y gestión de metadatos
Se pueden usar diferentes enfoques arquitectónicos para obtener, almacenar, integrar, mantener y crear metadatos.
accesible a los consumidores.
1.3.6.1 Arquitectura de metadatos centralizada
Una arquitectura centralizada consta de un único repositorio de Metadatos que contiene copias de Metadatos de varias fuentes. Las organizaciones con
recursos de TI limitados, o aquellas que buscan automatizar tanto como sea posible, pueden optar por evitar esta opción de arquitectura. Las
organizaciones que buscan un alto grado de coherencia dentro del repositorio de metadatos común pueden beneficiarse de una arquitectura centralizada.
Las ventajas de un repositorio centralizado incluyen:
• Alta disponibilidad, ya que es independiente de los sistemas de origen • Recuperación
rápida de metadatos, ya que el repositorio y la consulta residen juntos • Estructuras de bases de datos
resueltas que no se ven afectadas por la naturaleza propietaria de terceros o comerciales
sistemas
• Los Metadatos extraídos pueden transformarse, personalizarse o mejorarse con Metadatos adicionales que pueden
no residir en el sistema fuente, mejorando la calidad
Algunas limitaciones del enfoque centralizado incluyen:
• Se necesitan procesos complejos para garantizar que los cambios en los metadatos de origen se reproduzcan rápidamente en
el repositorio • El
mantenimiento de un repositorio centralizado puede ser costoso • La extracción
podría requerir módulos personalizados o middleware
• La validación y el mantenimiento del código personalizado pueden aumentar las demandas tanto del personal interno de TI como del
los proveedores de software
La Figura 85 muestra cómo se recopilan los metadatos en un repositorio de metadatos independiente con su propio almacén interno de metadatos. El
almacén interno se llena a través de una importación programada (flechas) de los metadatos de las distintas herramientas. A su vez, el repositorio
centralizado expone un portal para que los usuarios finales envíen sus consultas. El portal de metadatos pasa la solicitud al repositorio centralizado de
metadatos. El repositorio centralizado cumplirá con las
432 • DMBOK2
solicitud de los metadatos recopilados. En este tipo de implementación, no se admite la capacidad de pasar directamente la solicitud del
usuario a varias herramientas. La búsqueda global en los metadatos recopilados de las diversas herramientas es posible debido a la
recopilación de varios metadatos en el repositorio centralizado.
Portal de metadatos
REPOSITORIO DE METADATOS EMPRESARIALES
Herramientas de BI
Modelado Herramientas ETL Servicios SGBD Referencia Datos Mensajería Herramientas
Herramientas
Repositorio Herramientas Datos Calidad Herramientas de configuración
Herramientas
Figura 85 Arquitectura de metadatos centralizados
1.3.6.2 Arquitectura de metadatos distribuidos
Una arquitectura completamente distribuida mantiene un único punto de acceso. El motor de recuperación de metadatos responde a las
solicitudes de los usuarios recuperando datos de los sistemas de origen en tiempo real; no hay un repositorio persistente. En esta
arquitectura, el entorno de gestión de metadatos mantiene los catálogos del sistema de origen necesarios y la información de búsqueda
necesaria para procesar las consultas y búsquedas de los usuarios de manera eficaz. Un intermediario de solicitudes de objetos comunes
o un protocolo de middleware similar accede a estos sistemas de origen.
Las ventajas de la arquitectura de metadatos distribuidos incluyen:
• Los metadatos siempre son lo más actualizados y válidos posible porque se recuperan de su fuente • Las
consultas se distribuyen, lo que posiblemente mejore la respuesta y el tiempo de procesamiento • Las solicitudes
de metadatos de los sistemas patentados se limitan al procesamiento de consultas en lugar de requerir una comprensión
detallada de las estructuras de datos patentadas, por lo tanto, minimiza el esfuerzo de implementación y mantenimiento
requerido • El desarrollo del procesamiento automatizado de consultas de metadatos es probablemente más simple, y
requiere un mínimo de
intervención
• Se reduce el procesamiento por lotes, sin replicación de metadatos ni procesos de sincronización.
Las arquitecturas distribuidas también tienen limitaciones:
• No hay capacidad para admitir entradas de metadatos definidas por el usuario o insertadas manualmente, ya que no hay un
depósito en el que colocar estas adiciones
• Estandarización de la presentación de metadatos de varios sistemas • Las
capacidades de consulta se ven directamente afectadas por la disponibilidad de los sistemas fuente participantes • La
calidad de los metadatos depende únicamente de los sistemas fuente participantes
Portal de Metadatos
Herramientas de BI
Herramientas
Herramientas
Figura 86 Arquitectura de metadatos distribuidos
La Figura 86 ilustra una arquitectura de metadatos distribuidos. No existe un almacén de repositorio de metadatos centralizado y el portal
pasa las solicitudes de los usuarios a la herramienta adecuada para ejecutarlas. Como no existe un almacén centralizado para recopilar los
metadatos de las diversas herramientas, cada solicitud debe delegarse a las fuentes; por lo tanto, no existe ninguna capacidad para realizar
una búsqueda global en las distintas fuentes de metadatos.
1.3.6.3 Arquitectura híbrida de metadatos
Una arquitectura híbrida combina características de arquitecturas centralizadas y distribuidas. Los metadatos aún se mueven directamente
desde los sistemas de origen a un repositorio centralizado. Sin embargo, el diseño del repositorio solo tiene en cuenta los metadatos
agregados por el usuario, los elementos estandarizados críticos y las adiciones de fuentes manuales.
La arquitectura se beneficia de la recuperación casi en tiempo real de metadatos desde su fuente y metadatos mejorados.
para satisfacer las necesidades del usuario de la manera más efectiva, cuando sea necesario. El enfoque híbrido reduce el esfuerzo de la
intervención manual de TI y la funcionalidad de acceso con código personalizado a los sistemas propietarios. Los metadatos son lo más
actuales y válidos posible en el momento de su uso, en función de las prioridades y los requisitos del usuario. La arquitectura híbrida no
mejora la disponibilidad del sistema.
La disponibilidad de los sistemas de origen es una limitación, porque la naturaleza distribuida de los sistemas de backend maneja el
procesamiento de consultas. Se requiere una sobrecarga adicional para vincular esos resultados iniciales con el aumento de metadatos en
el repositorio central antes de presentar el conjunto de resultados al usuario final.
Muchas organizaciones pueden beneficiarse de una arquitectura híbrida, incluidas aquellas que tienen metadatos operativos que cambian
rápidamente, aquellas que necesitan metadatos consistentes y uniformes y aquellas que experimentan un crecimiento sustancial en
metadatos y fuentes de metadatos. Es posible que las organizaciones con metadatos más estáticos y perfiles de crecimiento de metadatos
más pequeños no vean el potencial máximo de esta alternativa de arquitectura.
1.3.6.4 Arquitectura bidireccional de metadatos
Otro enfoque arquitectónico avanzado es la arquitectura de metadatos bidireccional, que permite que los metadatos cambien en cualquier
parte de la arquitectura (fuente, integración de datos, interfaz de usuario) y luego se coordinan los comentarios desde el repositorio
(intermediario) a su fuente original.
434 • DMBOK2
Varios desafíos son evidentes en este enfoque. El diseño obliga al repositorio de metadatos a contener la última versión de la
fuente de metadatos y también lo obliga a administrar los cambios en la fuente. Los cambios deben detectarse sistemáticamente
y luego resolverse. Se deben crear y mantener conjuntos adicionales de interfaces de proceso para vincular el repositorio a
la(s) fuente(s) de metadatos.
Portal de metadatos
REPOSITORIO DE METADATOS EMPRESARIALES
BI Modelado ETL Servicios SGBD Referencia Datos Mensajería Configurar

metadatos metadatos metadatos metadatos metadatos metadatos metadatos ción
Calidad
metadatos metadatos
Herramientas de BI
Herramientas
Herramientas
Figura 87 Arquitectura híbrida de metadatos
La Figura 87 ilustra cómo se recopilan metadatos comunes de diferentes fuentes en un almacén de metadatos centralizado.
Los usuarios envían sus consultas al portal de metadatos, que pasa la solicitud a un repositorio centralizado. El repositorio
centralizado intentará cumplir con la solicitud del usuario a partir de los Metadatos comunes recopilados inicialmente de las
diversas fuentes. A medida que la solicitud se vuelve más específica o el usuario necesita Metadatos más detallados, el
repositorio centralizado delegará a la fuente específica para investigar los detalles específicos. La búsqueda global en las
diversas herramientas está disponible debido a los metadatos comunes recopilados en el repositorio centralizado.
2. Actividades
2.1 Definir la estrategia de metadatos
Una estrategia de metadatos describe cómo una organización pretende administrar sus metadatos y cómo pasará del estado
actual a las prácticas del estado futuro. Una estrategia de metadatos debe proporcionar un marco para que los equipos de
desarrollo mejoren la gestión de metadatos. El desarrollo de los requisitos de metadatos ayudará a aclarar los impulsores de la
estrategia e identificará los posibles obstáculos para implementarla.
La estrategia incluye la definición de la futura arquitectura de metadatos de la empresa estatal de la organización y las fases de implementación
requeridas para cumplir con los objetivos estratégicos. Los pasos incluyen:
• Iniciar la planificación de la estrategia de metadatos: el objetivo de la iniciación y la planificación es permitir que los metadatos
equipo de estrategia para definir sus objetivos a corto y largo plazo. La planificación incluye redactar un estatuto, alcance y objetivos
alineados con los esfuerzos generales de gobierno y establecer un plan de comunicaciones para respaldar el esfuerzo. Las partes
interesadas clave deben participar en la planificación.
• Llevar a cabo entrevistas con las partes interesadas clave: las entrevistas con las partes interesadas comerciales y técnicas brindan una
base de conocimiento para la estrategia de Metadatos.
• Evaluar las fuentes de metadatos existentes y la arquitectura de la información: la evaluación determina la
grado de dificultad para resolver los problemas de metadatos y sistemas identificados en las entrevistas y la revisión de la
documentación. Durante esta etapa, lleve a cabo entrevistas detalladas con el personal clave de TI y revise la documentación
de las arquitecturas del sistema, los modelos de datos, etc.
• Desarrollar la futura arquitectura de metadatos: refinar y confirmar la visión futura, y desarrollar el largo
término arquitectura de destino para el entorno de metadatos administrados en esta etapa. Esta fase debe tener en cuenta los
componentes estratégicos, como la estructura de la organización, la alineación con el gobierno y la administración de datos, la
arquitectura de metadatos gestionados, la arquitectura de entrega de metadatos, la arquitectura técnica y la arquitectura de seguridad.
• Desarrollar un plan de implementación por etapas: validar, integrar y priorizar los hallazgos del
entrevistas y análisis de datos. Documente la estrategia de metadatos y defina un enfoque de implementación por etapas para
pasar del entorno de metadatos administrado existente al futuro.
La estrategia evolucionará con el tiempo, ya que los requisitos de metadatos, la arquitectura y el ciclo de vida de los metadatos son
mejor entendido
2.2 Comprender los requisitos de los metadatos
Los requisitos de metadatos comienzan con el contenido: qué metadatos se necesitan y en qué nivel. Por ejemplo, los nombres físicos y lógicos
deben capturarse tanto para las columnas como para las tablas. El contenido de los metadatos es amplio y los requisitos provendrán tanto de los
consumidores de datos comerciales como técnicos. (Consulte la Sección 1.3.2.)
También hay muchos requisitos centrados en la funcionalidad asociados con una solución integral de metadatos:
• Volatilidad: con qué frecuencia se actualizarán los atributos y conjuntos de metadatos
• Sincronización: sincronización de las actualizaciones en relación con los cambios de fuente
• Historial: si es necesario conservar las versiones históricas de los metadatos
• Derechos de acceso: quién puede acceder a los metadatos y cómo acceden, junto con una interfaz de usuario específica
funcionalidad de acceso
436 • DMBOK2
• Estructura: cómo se modelarán los metadatos para su almacenamiento
• Integración: El grado de integración de Metadatos de diferentes fuentes; reglas para la integración
• Mantenimiento: Procesos y reglas para la actualización de Metadatos (registro y referencia para aprobación)
• Gestión: roles y responsabilidades para la gestión de metadatos
• Calidad: requisitos de calidad de los metadatos
• Seguridad: algunos metadatos no pueden exponerse porque revelarán la existencia de información altamente protegida.
datos
2.3 Definir la arquitectura de metadatos
Un sistema de gestión de metadatos debe ser capaz de extraer metadatos de muchas fuentes. Diseñe la arquitectura para que sea capaz de
escanear las diversas fuentes de metadatos y actualizar periódicamente el repositorio.
El sistema debe admitir actualizaciones manuales de metadatos, solicitudes, búsquedas y búsquedas de metadatos por parte de varios grupos de
usuarios.
Un entorno de metadatos administrado debe aislar al usuario final de las diversas y dispares fuentes de metadatos.
La arquitectura debe proporcionar un único punto de acceso para el repositorio de metadatos. El punto de acceso debe proporcionar todos los
recursos de metadatos relacionados de forma transparente al usuario. Los usuarios deben poder acceder a los metadatos sin ser conscientes de
los diferentes entornos de las fuentes de datos. En las soluciones de análisis y Big Data, la interfaz puede tener en gran medida funciones definidas
por el usuario (UDF) para aprovechar varios conjuntos de datos, y la exposición de los metadatos al usuario final es inherente a esas
personalizaciones. Con una menor dependencia de UDF en las soluciones, los usuarios finales recopilarán, inspeccionarán y utilizarán conjuntos
de datos de manera más directa y, por lo general, varios metadatos de soporte estarán más expuestos.
El diseño de la arquitectura depende de los requisitos específicos de la organización. Tres enfoques arquitectónicos técnicos para crear un
repositorio de metadatos común imitan los enfoques para diseñar almacenes de datos: centralizado, distribuido e híbrido (consulte la Sección 1.3.6).
Todos estos enfoques tienen en cuenta la implementación del repositorio y cómo funcionan los mecanismos de actualización.
2.3.1 Crear MetaModelo
Cree un modelo de datos para el repositorio de metadatos, o metamodelo, como uno de los primeros pasos de diseño después de que se complete
la estrategia de metadatos y se comprendan los requisitos comerciales. Se pueden desarrollar diferentes niveles de metamodelo según sea
necesario; un modelo conceptual de alto nivel, que explica las relaciones entre sistemas, y un metamodelo de nivel inferior que detalla las
atribuciones, para describir los elementos y procesos de un modelo. Además de ser una herramienta de planificación y un medio para articular
requisitos, el metamodelo es en sí mismo un valioso
fuente de metadatos.
La Figura 88 muestra un metamodelo de repositorio de metadatos de muestra. Los recuadros representan las principales entidades de alto nivel,
que contienen los datos.
Arquitectura Negocios Metadatos
Negocio
Sistema
Glosario
Datos lógicos Datos físicos
Modelo de datos Almacén de datos Glosario

Solicitud
Términos
Archivo/Tabla codificado
Entidad
Dominio
Atributo Campo/Columna Conjuntos de códigos Valor del código Valor de negocio
Metadatos técnicos
Figura 88 Metamodelo de repositorio de metadatos de ejemplo
2.3.2 Aplicar estándares de metadatos
La solución de metadatos debe adherirse a los estándares internos y externos acordados según se identifican en la estrategia de metadatos. Las
actividades de gobierno deben monitorear el cumplimiento de los metadatos. Los estándares de metadatos internos de la organización incluyen
convenciones de nomenclatura, atribuciones personalizadas, seguridad, visibilidad y documentación de procesamiento. Los estándares de metadatos
externos de la organización incluyen los formatos de intercambio de datos y el diseño de interfaces de programación de aplicaciones.
2.3.3 Administrar almacenes de metadatos
Implementar actividades de control para gestionar el entorno de metadatos. El control de repositorios es el control del movimiento de metadatos y las
actualizaciones del repositorio realizadas por el especialista en metadatos. Estas actividades son de naturaleza administrativa e implican monitorear y
responder a informes, advertencias, registros de trabajo y resolver varios problemas en el entorno de repositorio implementado. Muchas actividades de
control son estándar para las operaciones de datos y el mantenimiento de la interfaz. Las actividades de control deben tener supervisión de gobierno de
datos.
Las actividades de control incluyen:
• Programación y supervisión de trabajos •
Análisis estadístico de carga • Copia de
seguridad, recuperación, archivado, depuración
438 • DMBOK2
• Modificaciones de configuración •
Ajuste de rendimiento • Análisis de
estadísticas de consulta • Generación de
consultas e informes • Gestión de
seguridad • Las actividades de control
de calidad incluyen: • Garantía de calidad,
control de calidad • Frecuencia de actualización
de datos: conjuntos coincidentes con marcos de tiempo • Informes de
metadatos faltantes • Informe de metadatos antiguos • Metadatos Las
actividades de administración incluyen: • Carga, escaneo, importación y
etiquetado de activos • Movimiento y mapeo de fuentes • Control de
versiones • Administración de la interfaz de usuario • Vinculación de
conjuntos de datos Mantenimiento de metadatos: para el aprovisionamiento
de NOSQL • Vinculación de datos a la adquisición de datos internos:
enlaces personalizados y metadatos de trabajo • Licencias para Fuentes y
fuentes de datos externas • Metadatos de mejora de datos, p. ej., Enlace a GIS • Y
capacitación, que incluye: • Educación y capacitación de usuarios y administradores de datos •
Generación y análisis de métricas de gestión • Capacitación sobre actividades de control y
consulta e informes
2.4 Crear y mantener metadatos
Como se describe en la Sección 1.3.5, los metadatos se crean a través de una variedad de procesos y se almacenan en muchos lugares
dentro de una organización. Para ser de alta calidad, los metadatos deben administrarse como un producto. Los buenos metadatos no se
crean por accidente. Requiere planificación. (Consulte el Capítulo 13.)
Varios principios generales de la gestión de metadatos describen los medios para gestionar los metadatos para la calidad:
• Responsabilidad: reconocer que los metadatos a menudo se producen a través de procesos existentes (modelado de datos, SDLC,
definición de procesos de negocios) y responsabilizar a los propietarios de los procesos por la calidad de los metadatos.
• Estándares: establezca, aplique y audite estándares para metadatos para simplificar la integración y permitir el uso.
• Mejora: Crear un mecanismo de retroalimentación para que los consumidores puedan informar a la Gestión de Metadatos
equipo de metadatos incorrectos o desactualizados.
Al igual que otros datos, los metadatos se pueden perfilar e inspeccionar para comprobar su calidad. Su mantenimiento debe programarse o
completarse como parte auditable del trabajo del proyecto.
2.4.1 Integrar metadatos
Los procesos de integración recopilan y consolidan los metadatos de toda la empresa, incluidos los metadatos de los datos adquiridos fuera de la
empresa. El repositorio de metadatos debe integrar los metadatos técnicos extraídos con los metadatos comerciales, de procesos y de administración
relevantes. Los metadatos se pueden extraer mediante adaptadores, escáneres, aplicaciones puente o accediendo directamente a los metadatos en un
almacén de datos de origen. Los adaptadores están disponibles con muchas herramientas de software de terceros, así como con herramientas de
integración de metadatos. En algunos casos, los adaptadores se desarrollarán utilizando las API de la herramienta.
Surgen desafíos en la integración que requerirán gobernanza. La integración de conjuntos de datos internos, datos externos, como estadísticas
gubernamentales, y datos obtenidos de formularios no electrónicos, como libros blancos, artículos en revistas o informes, puede generar numerosas
preguntas sobre la calidad y la semántica.
Realice el escaneo del repositorio en dos enfoques distintos.
• Interfaz patentada: en un proceso de escaneado y carga de un solo paso, un escáner recopila los metadatos de un sistema de origen y luego
llama directamente al componente cargador específico del formato para cargar los metadatos en el repositorio. En este proceso, no hay
salida de archivo de formato específico y la recopilación y carga de metadatos ocurre en un solo paso.
• Interfaz semipropietaria: en un proceso de dos pasos, un escáner recopila los metadatos de un sistema de origen y los envía a un archivo
de datos de formato específico. El escáner solo produce un archivo de datos que el repositorio receptor necesita para poder leer y
cargar adecuadamente. La interfaz es una arquitectura más abierta, ya que muchos métodos pueden leer el archivo.
Un proceso de escaneo usa y produce varios tipos de archivos durante el proceso.
• Archivo de control: contiene la estructura de origen del modelo de datos • Archivo de
reutilización: contiene las reglas para gestionar la reutilización de las cargas del proceso • Archivos
de registro: producidos durante cada fase del proceso, uno para cada exploración o extracción y uno para cada
ciclo de carga
• Archivos temporales y de respaldo: Uso durante el proceso o para trazabilidad
Utilice un área de ensayo de metadatos no persistentes para almacenar archivos temporales y de copia de seguridad. El área de preparación admite
procesos de reversión y recuperación, y proporciona un seguimiento de auditoría provisional para ayudar a los administradores de repositorios cuando
investigan problemas de calidad o fuentes de metadatos. El área de preparación puede tomar la forma de un directorio de archivos o un
base de datos.
Las herramientas de integración de datos utilizadas para el almacenamiento de datos y las aplicaciones de Business Intelligence se utilizan a menudo de
forma eficaz en los procesos de integración de metadatos. (Consulte el Capítulo 8.)
2.4.2 Distribuir y entregar metadatos
Los metadatos se entregan a los consumidores de datos ya las aplicaciones o herramientas que requieren fuentes de metadatos. Entrega
mecanismos incluyen:
440 • DMBOK2
• Sitios web de intranet de metadatos para navegar, buscar, consultar, generar informes y analizar •
Informes, glosarios y otros documentos • Almacenes de datos, data marts y herramientas de BI
(inteligencia comercial) • Herramientas de modelado y desarrollo de software • Mensajería y
transacciones • Servicios web y Interfaces de programación de aplicaciones (API) • Soluciones de
interfaz de organización externa (p. ej., soluciones de cadena de suministro)
La solución de metadatos a menudo se vincula con una solución de Business Intelligence, de modo que tanto el alcance como la actualidad
de los metadatos se sincronizan con el contenido de BI. Un enlace proporciona un medio de integración en la entrega de BI al usuario final.
De manera similar, algunas soluciones CRM (gestión de relaciones con los clientes) u otras soluciones ERP (planificación de recursos
empresariales) pueden requerir la integración de metadatos en la capa de entrega de la aplicación.
Los metadatos se intercambian con organizaciones externas mediante archivos (planos, XML o JSON estructurados) o a través de la web.
servicios.
2.5 Consultar, generar informes y analizar metadatos
Los metadatos guían el uso de los activos de datos. Use metadatos en Business Intelligence (informes y análisis), decisiones comerciales
(operativas, tácticas, estratégicas) y en semántica comercial (lo que dicen, lo que significan, jerga comercial). Un repositorio de metadatos
debe tener una aplicación frontal que admita la funcionalidad de búsqueda y recuperación requerida para toda esta orientación y gestión de
activos de datos. La interfaz proporcionada a los usuarios comerciales puede tener un conjunto de requisitos funcionales diferente al de los
usuarios técnicos y desarrolladores. Algunos informes facilitan el desarrollo futuro, como el análisis del impacto del cambio, o solucionan
problemas de definiciones variables para proyectos de almacenamiento de datos e inteligencia comercial, como informes de linaje de datos.
3. Herramientas
La herramienta principal utilizada para administrar metadatos es el repositorio de metadatos. Esto incluirá una capa de integración y, a
menudo, una interfaz para actualizaciones manuales. Las herramientas que producen y utilizan metadatos se convierten en fuentes de
metadatos que pueden integrarse en un repositorio de metadatos.
3.1 Herramientas de gestión del repositorio de metadatos
Las herramientas de administración de metadatos brindan capacidades para administrar metadatos en una ubicación centralizada
(repositorio). Los metadatos pueden ingresarse manualmente o extraerse de varias otras fuentes a través de conectores especializados. Los
repositorios de metadatos también brindan capacidades para intercambiar metadatos con otros sistemas.
Las herramientas de gestión de metadatos y los propios repositorios también son una fuente de metadatos, especialmente en un
modelo arquitectónico híbrido de metadatos o en implementaciones de grandes empresas. Las herramientas de gestión de metadatos
permiten el intercambio de los metadatos recopilados con otros repositorios de metadatos, lo que permite la recopilación de varios y
diversos metadatos de diferentes fuentes en un repositorio centralizado, o permite el enriquecimiento y la estandarización de los
diversos metadatos a medida que se mueven entre los repositorios.
4. Técnicas
4.1 Linaje de datos y análisis de impacto
Un beneficio clave de descubrir y documentar metadatos sobre los activos físicos es proporcionar información sobre cómo se
transforman los datos a medida que se mueven entre sistemas. Muchas herramientas de metadatos transportan información sobre lo
que sucede con los datos dentro de sus entornos y brindan capacidades para ver el linaje a lo largo de los sistemas o aplicaciones
con los que interactúan. La versión actual del linaje basada en el código de programación se conoce como 'Linaje implementado'. Por
el contrario, el linaje descrito en los documentos de especificación de mapeo se denomina 'tal como linaje diseñado'.
Las limitaciones de una compilación de linaje se basan en la cobertura del sistema de gestión de metadatos. Los repositorios de
metadatos específicos de la función o las herramientas de visualización de datos tienen información sobre el linaje de datos dentro
del alcance de los entornos con los que interactúan, pero no proporcionarán visibilidad de lo que sucede con los datos.
fuera de sus entornos.
Los sistemas de gestión de metadatos importan el linaje 'Como se implementó' de las diversas herramientas que pueden proporcionar
este detalle de linaje y luego aumentan el linaje de datos con 'Como se diseñó' desde los lugares donde los detalles de implementación
reales no se pueden extraer. El proceso de conectar las piezas del linaje de datos se denomina unión . Da como resultado una
visualización holística de los datos a medida que se mueven desde sus ubicaciones originales (fuente oficial o sistema de registro)
hasta que llegan a su destino final.
La Figura 89 muestra un linaje de elementos de datos de muestra. Al leer esto, el elemento de datos comerciales 'Total de pedidos
pendientes', que se implementa físicamente como columna zz_total, depende de otros 3 elementos de datos: 'Costo de unidades en
centavos' implementado físicamente como 'yy_unit_cost', 'Impuesto en el estado de envío' implementado en 'yy_tax' y 'Cantidad de
pedidos pendientes' implementados en 'yy_qty'.
Aunque un gráfico de linaje, como el de la Figura 89, describe lo que sucede con un elemento de datos en particular, no todos los
usuarios comerciales lo entenderán. Los niveles más altos de linaje (p. ej., 'linaje del sistema') resumen el movimiento a nivel del
sistema o de la aplicación. Muchas herramientas de visualización brindan la capacidad de acercar/alejar, para mostrar el linaje de los
elementos de datos en el contexto del linaje del sistema. Por ejemplo, la Figura 90 muestra un linaje de sistema de muestra, donde
de un vistazo, el movimiento general de datos se comprende y visualiza a nivel de sistema o aplicación.
442 • DMBOK2
*)Información restringida
*)Actualizado semanalmente
*)Incluye pedidos cancelados *)Solamente
pedidos en EE. UU., para consultas internacionales.
*)Administrador: John Doe *)La
moneda es dólares estadounidenses Costo unitario en centavos
yy_unt_cost
Historial de pedidos orden activa Pedido pendiente total

Enviar al estado Impuesto en Enviar al
zz_ord_tran_hist xx_cur_ord yy_state_cd estado yy_tax zz_total
Pedido pendiente
Cantidad
aa_qty
Figura 89 Diagrama de flujo de linaje de elemento de datos de muestra
Sistema 1 Sistema 3
Depósito
Sistema 2 Sistema 4
Figura 90 Diagrama de flujo del linaje del sistema de muestra
A medida que crece la cantidad de elementos de datos en un sistema, el descubrimiento del linaje se vuelve complejo y difícil de
administrar. Para lograr con éxito los objetivos comerciales, una estrategia para descubrir e importar activos en el repositorio de
metadatos requiere planificación y diseño. El descubrimiento exitoso del linaje debe tener en cuenta ambos
enfoque comercial y técnico:
• Enfoque comercial: limite el descubrimiento de linaje a elementos de datos priorizados por el negocio. Comience desde las ubicaciones de
destino y realice un seguimiento hasta los sistemas de origen donde se originan los datos específicos. Al limitar los activos escaneados
a aquellos que mueven, transfieren o actualizan los elementos de datos seleccionados, este enfoque permitirá a los consumidores de
datos comerciales comprender qué sucede con el elemento de datos específico a medida que se mueve a través de los sistemas. Si se
combina con mediciones de calidad de datos, el linaje se puede usar para identificar dónde el diseño del sistema afecta negativamente
la calidad de los datos.
• Enfoque técnico: Comience en los sistemas de origen e identifique todos los consumidores inmediatos, luego identifique todos los consumidores
subsiguientes del primer conjunto identificado y siga repitiendo estos pasos hasta que se identifiquen todos los sistemas. Los usuarios de
tecnología se benefician más de la estrategia de descubrimiento del sistema para ayudar a responder las diversas preguntas sobre los
datos. Este enfoque permitirá a los usuarios de tecnología y negocios responder preguntas sobre el descubrimiento de elementos de
datos en toda la empresa, como "¿Dónde está el número de seguro social?" o generar informes de impacto como "¿Qué sistemas se ven
afectados si se cambia el ancho de una columna específica?" Sin embargo, esta estrategia puede resultar compleja de gestionar.
Muchas herramientas de integración de datos ofrecen análisis de linaje que considera no solo el código de población desarrollado, sino también el
modelo de datos y la base de datos física. Algunos ofrecen interfaces web orientadas al usuario comercial para monitorear y actualizar definiciones.
Estos comienzan a parecerse a glosarios de negocios.
El linaje documentado ayuda tanto a la gente de negocios como a la técnica a usar los datos. Sin él, se desperdicia mucho tiempo investigando
anomalías, impactos de cambios potenciales o resultados desconocidos. Busque implementar una herramienta integrada de impacto y linaje que
pueda comprender todas las partes móviles involucradas en el proceso de carga, así como los informes y análisis del usuario final. Los informes de
impacto describen qué componentes se ven afectados por un cambio potencial, lo que agiliza y agiliza las tareas de estimación y mantenimiento.
4.2 Metadatos para la ingesta de Big Data
Muchos profesionales de la gestión de datos están familiarizados y se sienten cómodos con los almacenes de datos estructurados, donde cada
elemento se puede identificar y etiquetar claramente. Hoy en día, sin embargo, muchos datos vienen en formatos menos estructurados. Algunas
fuentes no estructuradas serán internas a la organización y otras serán externas. En cualquier caso, ya no es necesario llevar físicamente los datos a
un solo lugar. A través de las nuevas tecnologías, el programa irá a los datos en lugar de mover los datos al programa, reduciendo la cantidad de
movimiento de datos y acelerando la ejecución del proceso. No obstante, la gestión de datos exitosa en un lago de datos depende de la gestión
Metadatos.
Las etiquetas de metadatos se deben aplicar a los datos en el momento de la ingesta. Luego, los metadatos se pueden usar para identificar el
contenido de datos disponible para el acceso en el lago de datos. Muchos motores de ingestión perfilan los datos a medida que se ingieren. La
creación de perfiles de datos puede identificar dominios de datos, relaciones y problemas de calidad de datos. También puede habilitar el etiquetado.
En la ingestión, se pueden agregar etiquetas de metadatos para identificar datos confidenciales o privados (como información de identificación
personal, PPI), por ejemplo. Los científicos de datos pueden agregar confianza, identificadores textuales y códigos que representan grupos de
comportamiento. (Consulte el Capítulo 14.)
444 • DMBOK2
Implemente un entorno de metadatos administrado en pasos incrementales para minimizar los riesgos para la organización y facilitar la
aceptación. Implemente repositorios de metadatos utilizando una plataforma de base de datos relacional abierta. Esto permite el desarrollo
y la implementación de varios controles e interfaces que pueden no anticiparse al comienzo de un proyecto de desarrollo de repositorio.
El contenido del repositorio debe tener un diseño genérico y no reflejar simplemente los diseños de la base de datos del sistema de origen.
Diseñe contenidos alineados con los expertos en el área temática de la empresa y con base en un modelo integral de metadatos. La
planificación debe tener en cuenta la integración de metadatos para que los consumidores de datos puedan ver diferentes fuentes de
datos. La capacidad de hacerlo será una de las capacidades más valiosas del repositorio. Debe albergar versiones actuales, planificadas
e históricas de los metadatos.
A menudo, la primera implementación es un piloto para probar conceptos y aprender a administrar el entorno de metadatos.
Es necesaria la integración de los proyectos de metadatos en la metodología de desarrollo de TI. Habrá variaciones según la arquitectura
y los tipos de almacenamiento.
Tener una estrategia sólida de metadatos ayuda a todos a tomar decisiones más efectivas. En primer lugar, las personas deben ser
conscientes de los riesgos de no gestionar los metadatos. Evaluar el grado en que la falta de Metadatos de alta calidad podría resultar en:
• Errores de juicio debido a suposiciones incorrectas, incompletas o inválidas o falta de conocimiento sobre el
contexto de los datos
• Exposición de datos confidenciales, que pueden poner en riesgo a clientes o empleados, o afectar la credibilidad de
el negocio y dar lugar a gastos legales
• Riesgo de que el pequeño conjunto de PYMES que conocen los datos se vaya y se lleve su conocimiento con ellos
El riesgo se reduce cuando una organización adopta una estrategia sólida de metadatos. La preparación organizacional se aborda
mediante una evaluación formal de la madurez actual en las actividades de metadatos. La evaluación debe incluir los elementos críticos
de datos comerciales, los glosarios de metadatos disponibles, el linaje, los procesos de calidad y perfilado de datos, la madurez de MDM
(Gestión de datos maestros) y otros aspectos. Los hallazgos de la evaluación, alineados con las prioridades comerciales, proporcionarán
la base para un enfoque estratégico para mejorar las prácticas de gestión de metadatos. Una evaluación formal también proporciona la
base para un caso de negocios, patrocinio y financiación.
La estrategia de metadatos puede ser parte de una estrategia general de gobierno de datos o puede ser el primer paso para implementar
un gobierno de datos efectivo. Se debe realizar una evaluación de metadatos a través de una inspección objetiva de los metadatos
existentes, junto con entrevistas con las partes interesadas clave. Los resultados de una evaluación de riesgos incluyen una estrategia y
una hoja de ruta.
5.2 Cambio Organizacional y Cultural
Al igual que otros esfuerzos de gestión de datos, las iniciativas de metadatos a menudo encuentran resistencia cultural. Pasar de un entorno de
metadatos no administrado a uno administrado requiere trabajo y disciplina. No es fácil de hacer, incluso si la mayoría de la gente reconoce el valor
de los metadatos confiables. La preparación organizativa es una preocupación importante, al igual que los métodos de gobierno y control.
La gestión de metadatos es una prioridad baja en muchas organizaciones. Un conjunto esencial de metadatos necesita coordinación y compromiso
en una organización. Pueden ser estructuras de datos de identificación de empleados, números de pólizas de seguros, números de identificación
de vehículos o especificaciones de productos, que si se modifican, requerirían revisiones importantes de muchos sistemas empresariales. Busque
ese buen ejemplo en el que el control obtendrá beneficios de calidad inmediatos para los datos de la empresa. Construya el argumento a partir de
ejemplos concretos relevantes para el negocio.
La implementación de una estrategia de gobierno de datos empresariales necesita el apoyo y el compromiso de la alta dirección. Requiere que el
personal comercial y de tecnología pueda trabajar en estrecha colaboración de manera multifuncional.
6. Gobernanza de metadatos
Las organizaciones deben determinar sus requisitos específicos para la gestión del ciclo de vida de los metadatos y establecer procesos de
gobierno para permitir esos requisitos. Se recomienda que las funciones y responsabilidades formales se asignen a recursos dedicados,
especialmente en áreas grandes o críticas para el negocio. Los propios procesos de gobierno de metadatos dependen de metadatos confiables,
por lo que el equipo encargado de administrar los metadatos puede probar los principios en los metadatos que crean y usan.
6.1 Controles de proceso
El equipo de gobierno de datos debe ser responsable de definir los estándares y administrar los cambios de estado de los metadatos, a menudo
con software de flujo de trabajo o de colaboración, y puede ser responsable de las actividades promocionales y el desarrollo de la capacitación o la
capacitación real en toda la organización.
Una gobernanza de metadatos más madura requerirá términos comerciales y definiciones para progresar a través de diferentes cambios de estado
o puertas de gobernanza; por ejemplo, desde un término candidato hasta aprobado, publicado y hasta un punto final en el ciclo de vida de
reemplazado o retirado. El equipo de gobierno también puede administrar asociaciones de términos comerciales, como términos relacionados, así
como la categorización y agrupación de los términos.
La integración de la estrategia de metadatos en el SDLC es necesaria para garantizar que los metadatos modificados se recopilen cuando se
modifican. Esto ayuda a garantizar que los metadatos permanezcan actualizados.
446 • DMBOK2
6.2 Documentación de soluciones de metadatos
Un catálogo maestro de Metadatos incluirá las fuentes y los objetivos actualmente en el alcance. Este es un recurso para usuarios comerciales y de
TI y se puede publicar para la comunidad de usuarios como una guía sobre "qué es dónde" y para establecer expectativas sobre lo que encontrarán:
• Estado de implementación de metadatos •
Almacén de metadatos de origen y de destino •
Programar información para actualizaciones •
Retención y versiones guardadas
• Contenidos
• Declaraciones o advertencias de calidad (p. ej., valores faltantes) • Sistema
de registro y otros estados de la fuente de datos (p. ej., cobertura del historial del contenido de los datos, retiro o
reemplazando
banderas) • Herramientas, arquitecturas y personas
involucradas • Información confidencial y estrategia de eliminación o enmascaramiento para la fuente
En la gestión de documentos y contenidos, los mapas de datos muestran información similar. Las visualizaciones del panorama general de los
sistemas de integración de metadatos también se mantienen como parte de la documentación de metadatos. (Consulte el Capítulo 9.)
6.3 Normas y directrices sobre metadatos
Los estándares de metadatos son esenciales en el intercambio de datos con socios comerciales operativos. Las empresas se dan cuenta del valor
de compartir información con clientes, proveedores, socios y organismos reguladores. La necesidad de compartir metadatos comunes para respaldar
el uso óptimo de la información compartida ha generado muchos cambios basados en el sector.
estándares
Adopte estándares de metadatos sensibles al sector y basados en la industria al principio del ciclo de planificación. Utilice los estándares para
evaluar las tecnologías de gestión de metadatos. Muchos proveedores líderes admiten múltiples estándares, y algunos pueden ayudar a personalizar
estándares sensibles al sector y basados en la industria.
Los proveedores de herramientas brindan compatibilidad con XML y JSON o REST para intercambiar datos para sus productos de gestión de datos.
Utilizan la misma estrategia para unir sus herramientas en conjuntos de soluciones. Las tecnologías, incluidas la integración de datos, las bases de
datos relacionales y multidimensionales, la gestión de requisitos, los informes de Business Intelligence, el modelado de datos y las reglas
comerciales, ofrecen capacidades de importación y exportación de datos y metadatos mediante XML. Los proveedores mantienen sus propios
esquemas XML y definiciones de tipo de documento (DTD) o, más comúnmente, las definiciones de esquema XML (XSD). A estos se accede a
través de interfaces propietarias. Se requiere un desarrollo personalizado para integrar estas herramientas en un entorno de gestión de metadatos.
Las pautas incluyen plantillas y ejemplos asociados y capacitación sobre las entradas y actualizaciones esperadas, incluidas reglas como 'no defina
un término usando el término' y declaraciones de integridad. Hay diferentes plantillas
desarrollados para diferentes tipos de Metadatos, y son impulsados en parte por la solución de Metadatos seleccionada. El monitoreo continuo de las pautas para
la efectividad y las actualizaciones necesarias es una responsabilidad de la gobernanza.
Los estándares ISO para metadatos brindan orientación para los desarrolladores de herramientas, pero es poco probable que sean una preocupación para las
organizaciones que implementan el uso de herramientas comerciales, ya que las herramientas deben cumplir con los estándares. De todos modos, puede ser útil
tener una buena comprensión de estos estándares y sus repercusiones.
6.4 Métricas
Es difícil medir el impacto de los metadatos sin medir primero el impacto de la falta de metadatos. Como parte de la evaluación de riesgos, obtenga métricas sobre
la cantidad de tiempo que los consumidores de datos dedican a buscar información, para mostrar mejoras después de implementar la solución de metadatos. La
eficacia de la implementación de los metadatos también se puede medir en términos de la integridad de los metadatos en sí, de las rutinas de gestión asociadas a
ellos y del uso de los metadatos. Las métricas sugeridas en entornos de metadatos incluyen:
• Integridad del repositorio de metadatos: compare la cobertura ideal de los metadatos de la empresa (todos los artefactos
y todas las instancias dentro del alcance) a la cobertura real. Haga referencia a la estrategia para las definiciones de alcance.
• Madurez de la gestión de metadatos: Métricas desarrolladas para juzgar la madurez de los metadatos del
empresa, basado en el enfoque del modelo de madurez de capacidad (CMMDMM) para la evaluación de la madurez.
(Consulte el Capítulo 15.)
• Representación del administrador: Compromiso de la organización con los metadatos según lo evaluado por el nombramiento de
delegados, cobertura en toda la empresa para la administración y documentación de los roles en las descripciones de puestos.
• Uso de metadatos: la captación de usuarios en el uso del repositorio de metadatos se puede medir mediante el recuento de inicios de sesión del
repositorio. La referencia a los metadatos por parte de los usuarios en la práctica comercial es una medida más difícil de rastrear.
Es posible que se requieran medidas anecdóticas en encuestas cualitativas para capturar esta medida.
• Actividad del Business Glossary: Uso, actualización, resolución de definiciones, cobertura.
• Cumplimiento de datos del servicio Master Data: Muestra la reutilización de datos en soluciones SOA. Los metadatos en los servicios de datos ayudan
a los desarrolladores a decidir cuándo un nuevo desarrollo podría usar un servicio existente.
• Calidad de la documentación de metadatos: evalúe la calidad de la documentación de metadatos a través de
métodos automáticos y manuales. Los métodos automáticos incluyen realizar la lógica de colisión en dos fuentes, medir cuánto coinciden y la
tendencia a lo largo del tiempo. Otra métrica mediría el porcentaje de atributos que tienen definiciones, con tendencia a lo largo del tiempo. Los
métodos manuales incluyen encuestas aleatorias o completas, basadas en definiciones empresariales de calidad. Las medidas de calidad indican la
integridad, confiabilidad, actualidad, etc., de los Metadatos en el repositorio.
• Disponibilidad del repositorio de metadatos: tiempo de actividad, tiempo de procesamiento (lote y consulta).
448 • DMBOK2
Aiken, Peter. Ingeniería inversa de datos: matar al dragón heredado. 1995.
Foreman, John W. Data Smart: uso de la ciencia de datos para transformar la información en conocimiento. Wiley, 2013. Imprimir.
Loshin, David. Gestión del conocimiento empresarial: el enfoque de calidad de datos. Morgan Kaufmann, 2001.
Marco, David. Creación y gestión del repositorio de metadatos: una guía completa del ciclo de vida. Wiley, 2000. Imprimir.
Milton, Nicolás Ross. Adquisición de conocimientos en la práctica: una guía paso a paso. Springer, 2007. Imprimir. Ingeniería de
decisiones.
Park, Jungran, ed. Pautas y mejores prácticas de metadatos: implementación actual y tendencias futuras. Routledge, 2014.
Imprimir.
Pomerantz, Jeffrey. Metadatos. La prensa del MIT, 2015. Imprimir. El ser de conocimiento esencial de MIT Press.
Schneier, Bruce. Datos y Goliat: las batallas ocultas para recopilar sus datos y controlar su mundo. WW Norton and Company, 2015. Imprimir.
Tannenbaum, Adrienne. Implementando un Repositorio Corporativo: Los Modelos se Encuentran con la Realidad. Wiley, 1994. Imprimir.
Informática Profesional Wiley.
Guardián, Pete. Glosario de Big Data. O'Reilly Media, 2011. Imprimir.
Zeng, Marcia Lei y Jian Qin. Metadatos. 2ª ed. ALA NealSchuman, 2015. Imprimir.
CAPÍTULO 1 3
Calidad de datos
Datos Modelado de datos
Arquitectura & Diseño
Almacenamiento de datos
Calidad de datos
y operaciones
Datos Datos
metadatos
Gobernancia Seguridad
Almacenamiento de datos Integración de datos &
& Negocio interoperabilidad
Inteligencia
Referencia Documento
& Maestro & Contenido
Datos Gestión
Marco de gestión de datos DAMADMBOK2
Copyright © 2017 por DAMA Internacional
1. Introducción
mi
La gestión eficaz de los datos implica un conjunto de procesos complejos e interrelacionados que permiten a una organización
utilizar sus datos para lograr objetivos estratégicos. La gestión de datos incluye la capacidad de diseñar datos para
almacene y acceda a ellos de forma segura, compártalos adecuadamente, aprenda de ellos y asegúrese de que satisfagan
las necesidades comerciales. Una suposición que subyace a las afirmaciones sobre el valor de los datos es que los datos en sí son
fiables y fidedignos. En otras palabras, que sea de alta calidad.
449
450 • DMBOK2
Sin embargo, muchos factores pueden socavar esa suposición al contribuir a la baja calidad de los datos: falta de comprensión acerca de
los efectos de la baja calidad de los datos en el éxito de la organización, mala planificación, diseño de sistemas 'aislados', procesos de
desarrollo inconsistentes, documentación incompleta, falta de estándares, o falta de gobernabilidad. Muchas organizaciones no logran
definir qué hace que los datos se ajusten a su propósito.
Todas las disciplinas de gestión de datos contribuyen a la calidad de los datos, y los datos de alta calidad que respaldan a la organización
deben ser el objetivo de todas las disciplinas de gestión de datos. Debido a que las decisiones o acciones desinformadas de cualquier
persona que interactúe con los datos pueden dar como resultado datos de mala calidad, la producción de datos de alta calidad requiere
un compromiso y una coordinación entre funciones. Las organizaciones y los equipos deben ser conscientes de esto y deben planificar
datos de alta calidad mediante la ejecución de procesos y proyectos de manera que tengan en cuenta el riesgo relacionado con condiciones
inesperadas o inaceptables en los datos.
Debido a que ninguna organización tiene procesos comerciales perfectos, procesos técnicos perfectos o prácticas de gestión de datos
perfectas, todas las organizaciones experimentan problemas relacionados con la calidad de sus datos. Las organizaciones que gestionan
formalmente la calidad de los datos tienen menos problemas que aquellas que dejan la calidad de los datos al azar.
La gestión formal de la calidad de los datos es similar a la gestión continua de la calidad de otros productos. Incluye la gestión de datos a
lo largo de su ciclo de vida mediante el establecimiento de estándares, la construcción de calidad en los procesos que crean, transforman
y almacenan datos, y la medición de datos frente a estándares. La gestión de datos a este nivel generalmente requiere un equipo del
programa de calidad de datos. El equipo del programa de calidad de datos es responsable de involucrar a los profesionales de gestión de
datos comerciales y técnicos e impulsar el trabajo de aplicar técnicas de gestión de calidad a los datos para garantizar que los datos sean
aptos para el consumo para una variedad de propósitos. Es probable que el equipo participe en una serie de proyectos a través de los
cuales puedan establecer procesos y mejores prácticas mientras abordan problemas de alta prioridad.
problemas de datos.
Debido a que administrar la calidad de los datos implica administrar el ciclo de vida de los datos, un programa de calidad de datos también
tendrá responsabilidades operativas relacionadas con el uso de datos. Por ejemplo, informar sobre los niveles de calidad de los datos y
participar en el análisis, la cuantificación y la priorización de problemas de datos. El equipo también es responsable de trabajar con
quienes necesitan datos para hacer su trabajo para garantizar que los datos satisfagan sus necesidades y de trabajar con quienes crean,
actualizan o eliminan datos en el transcurso de sus trabajos para garantizar que los manejen correctamente. La calidad de los datos
depende de todos los que interactúan con los datos, no solo de los profesionales de gestión de datos.
Como es el caso con Data Governance y con la gestión de datos en su conjunto, Data Quality Management es un programa, no un
proyecto. Incluirá tanto el proyecto como el trabajo de mantenimiento, junto con un compromiso con las comunicaciones y la capacitación.
Lo que es más importante, el éxito a largo plazo del programa de mejora de la calidad de los datos depende de lograr que una organización
cambie su cultura y adopte una mentalidad de calidad. Como se indica en el Manifiesto de datos del líder: el cambio fundamental y
duradero requiere un liderazgo comprometido y la participación de las personas en todos los niveles de una organización. Las personas
que usan datos para hacer su trabajo, que en la mayoría de las organizaciones es un porcentaje muy grande de empleados, necesitan
impulsar el cambio. Uno de los cambios más críticos en los que centrarse es cómo sus organizaciones gestionan y mejoran la calidad de
sus datos.71
71 Para obtener el texto completo del Manifiesto de datos del líder, consulte http://bit.ly/2sQhcy7.
CALIDAD DE DATOS • 451
Gestión de calidad de datos
Definición: La planificación, implementación y control de actividades que aplican técnicas de gestión de calidad a los datos, para asegurar que
sean aptos para el consumo y satisfagan las necesidades de los consumidores de datos.
Objetivos:
1. Desarrollar un enfoque gobernado para hacer que los datos se ajusten a su propósito en función de los requisitos de los consumidores de datos.
2. Definir estándares, requisitos y especificaciones para los controles de calidad de los datos como parte del ciclo de vida de los datos.
3. Definir e implementar procesos para medir, monitorear e informar sobre los niveles de calidad de los datos.
4. Identificar y abogar por oportunidades para mejorar la calidad de los datos, a través de mejoras de procesos y sistemas.
Negocio
Conductores
Entradas: Actividades: Entregables:

• Políticas de datos y 1. Definir datos de alta calidad (P) • Marco y estrategia de calidad de
Estándares 2. Definir una estrategia de calidad de datos (P) datos
• Calidad de datos 3. Definir el Alcance de la Evaluación Inicial (P) • Organización del programa de

1. Identificar datos críticos
Expectativas calidad de datos
2. Identificar reglas y patrones existentes 4. •
• Negocio Análisis a partir de datos
Realizar una evaluación inicial de la calidad de los datos (P)
perfilado
Requisitos 1. Identificar y priorizar problemas 2.
• Reglas del negocio • Recomendaciones basadas en el
Realizar análisis de causa raíz de problemas 5.
análisis de la causa raíz de los
• Requerimientos de datos Identificar y priorizar mejoras
problemas • Procedimientos DQM
• Metadatos comerciales 1. Priorizar acciones basadas en el impacto comercial 2.
• Metadatos técnicos Desarrollar acciones preventivas y correctivas 3. Confirmar
acciones planificadas • Informes de calidad de datos
• Fuentes de datos y
6. Desarrollar e implementar operaciones de calidad
• Gobernanza de la calidad de los datos
Almacenes de datos
de datos (D) Informes
• Linaje de datos 1. Desarrollar procedimientos operativos de calidad de datos
• Nivel de servicio de calidad de datos
2. Corregir defectos de calidad de datos 3. Medir y monitorear Acuerdos •
la calidad de datos 4. Informar sobre los niveles y hallazgos Políticas DQ y
de calidad de datos Pautas
Proveedores: Participantes: • CDO Consumidores:

• • Consumidores de datos comerciales
Administración de Empresas
• • • Administradores de datos
Expertos en la materia Analistas de calidad de datos
• Arquitectos de datos • Administradores de datos • Profesionales de datos
• Modeladores de datos • Propietarios de datos • Profesionales de TI
• • •
Especialistas en sistemas Analistas de datos Trabajadores del conocimiento
• Administradores de datos • Administradores de bases de datos • Órganos de Gobierno de Datos
• • Profesionales de datos •
Analistas de Procesos de Negocios Organizaciones asociadas
• Centros de Excelencia
• Gerentes DQ
•
operaciones de TI
• Arquitectos de integración de datos
• Equipo de cumplimiento
Técnico
Conductores
Herramientas:
Métrica:
Técnicas: • Gobernanza y
•
Comprobación al azar usando múltiples • Motores de creación de perfiles, herramientas de consulta
• Métricas de conformidad
subconjuntos Plantillas de reglas de calidad de datos
• Etiquetas y notas para marcar datos • Control de calidad y código de auditoría
• Medición de la calidad de los datos
Asuntos Módulos
• Resultados • Tendencias de mejora
Análisis de raíz de la causa
• Control del Proceso Estadístico • Métricas de gestión de problemas
Figura 91 Diagrama de contexto: calidad de datos
452 • DMBOK2
Los impulsores comerciales para establecer un programa formal de gestión de la calidad de los datos incluyen:
• Aumentar el valor de los datos organizacionales y las oportunidades para usarlos • Reducir los riesgos y costos
asociados con datos de mala calidad • Mejorar la eficiencia y la productividad organizacionales • Proteger y
mejorar la reputación de la organización
Las organizaciones que desean obtener valor de sus datos reconocen que los datos de alta calidad son más valiosos que los de baja calidad. Los datos de mala
calidad están cargados de riesgos (consulte el Capítulo 1). Puede dañar la reputación de una organización, lo que resulta en multas, pérdida de ingresos, pérdida
de clientes y exposición negativa a los medios. Los requisitos reglamentarios a menudo exigen datos de alta calidad. Además, muchos costos directos están
asociados con datos de mala calidad. Por ejemplo,
• Incapacidad para facturar correctamente •
Aumento de llamadas al servicio de atención al cliente y disminución de la capacidad para resolverlas •
Pérdida de ingresos debido a oportunidades comerciales perdidas • Retraso en la integración durante
fusiones y adquisiciones • Mayor exposición al fraude • Pérdida debido a malas decisiones comerciales
impulsadas por datos incorrectos • Pérdida de negocios debido a la falta de buena reputación crediticia
Aún así, los datos de alta calidad no son un fin en sí mismos. Es un medio para el éxito organizacional. Los datos confiables no solo mitigan el riesgo y reducen los
costos, sino que también mejoran la eficiencia. Los empleados pueden responder preguntas de manera más rápida y consistente cuando trabajan con datos
confiables. Pasan menos tiempo tratando de averiguar si los datos son correctos y más tiempo usándolos para obtener información, tomar decisiones y atender a
los clientes.
Los programas de calidad de datos se centran en estos objetivos generales:
• Desarrollar un enfoque gobernado para hacer que los datos se ajusten a su propósito en función de los requisitos de los consumidores de datos • Definir
estándares y especificaciones para los controles de calidad de los datos como parte del ciclo de vida de los datos • Definir e implementar procesos para
medir, monitorear e informar sobre los niveles de calidad de los datos • Identificar y abogar por oportunidades para mejorar la calidad de los datos, a
través de cambios en
procesos y sistemas y participar en actividades que mejoran de forma medible la calidad de los datos en función de los requisitos de los consumidores
de datos
Los programas de calidad de datos deben guiarse por los siguientes principios:
• Criticidad: un programa de calidad de datos debe centrarse en los datos más críticos para la empresa y sus
clientes. Las prioridades de mejora deben basarse en la criticidad de los datos y en el nivel de
riesgo si los datos no son correctos.
• Gestión del ciclo de vida: la calidad de los datos debe gestionarse a lo largo del ciclo de vida de los datos, desde
creación o adquisición a través de la enajenación. Esto incluye la gestión de datos a medida que se mueven dentro y entre sistemas
(es decir, cada eslabón de la cadena de datos debe garantizar que la salida de datos sea de alta calidad).
• Prevención: El enfoque de un programa de calidad de datos debe ser prevenir errores en los datos y condiciones que reduzcan la
usabilidad de los datos; no debe centrarse en simplemente corregir registros.
• Corrección de la causa raíz: mejorar la calidad de los datos va más allá de corregir errores. Los problemas con la calidad de los datos
deben entenderse y abordarse desde sus causas fundamentales, en lugar de solo sus síntomas. Debido a que estas causas a
menudo están relacionadas con el diseño de procesos o sistemas, mejorar la calidad de los datos a menudo requiere cambios en los
procesos y los sistemas que los respaldan.
• Gobernanza: las actividades de la Gobernanza de datos deben respaldar el desarrollo de datos y datos de alta calidad.
Las actividades del programa de calidad deben respaldar y sostener un entorno de datos gobernado.
• Impulsado por estándares: todas las partes interesadas en el ciclo de vida de los datos tienen requisitos de calidad de datos. En la medida
de lo posible, estos requisitos deben definirse en forma de estándares medibles y expectativas contra las cuales se puede medir la
calidad de los datos.
• Medición objetiva y transparencia: los niveles de calidad de los datos deben medirse de manera objetiva y consistente. Las mediciones y
la metodología de medición deben compartirse con las partes interesadas, ya que son los árbitros de la calidad.
• Integrado en los procesos comerciales: los propietarios de los procesos comerciales son responsables de la calidad de los datos
producidos a través de sus procesos. Deben hacer cumplir los estándares de calidad de datos en sus procesos.
• Cumplimiento sistemático: los propietarios del sistema deben hacer cumplir sistemáticamente los requisitos de calidad de los datos.
• Conectado a los niveles de servicio: deben incorporarse informes de calidad de datos y gestión de problemas.
en acuerdos de nivel de servicio (SLA).
1.3.1 Calidad de los datos
El término calidad de datos se refiere tanto a las características asociadas con datos de alta calidad como a los procesos utilizados para medir o
mejorar la calidad de los datos. Estos usos duales pueden ser confusos, por lo que es útil separarlos y aclarar qué constituye información de alta
calidad.72
72 En el DAMADMBOK2, hemos tratado de evitar el uso de las palabras calidad de los datos sin aclarar su contexto. Por ejemplo,
referirse a datos de alta calidad o datos de baja calidad, y a esfuerzos de trabajo de calidad de datos o actividades de calidad de datos.
454 • DMBOK2
Los datos son de alta calidad en la medida en que cumplen con las expectativas y necesidades de los consumidores de datos. Es decir, si los
datos son aptos para los fines a los que los quiere aplicar. Es de baja calidad si no es apto para esos fines.
Por lo tanto, la calidad de los datos depende del contexto y de las necesidades del consumidor de datos.
Uno de los desafíos en la gestión de la calidad de los datos es que no siempre se conocen las expectativas relacionadas con la calidad. Los
clientes pueden no articularlos. A menudo, las personas que manejan los datos ni siquiera preguntan acerca de estos requisitos. Sin embargo,
para que los datos sean fiables y fiables, los profesionales de la gestión de datos deben comprender mejor los requisitos de calidad de sus
clientes y cómo medirlos. Esto debe ser una discusión continua, ya que los requisitos cambian con el tiempo a medida que evolucionan las
necesidades comerciales y las fuerzas externas.
1.3.2 Datos críticos
La mayoría de las organizaciones tienen una gran cantidad de datos, no todos los cuales tienen la misma importancia. Un principio de la gestión
de la calidad de los datos es centrar los esfuerzos de mejora en los datos más importantes para la organización y sus clientes. Hacerlo le da al
programa alcance y enfoque y le permite tener un impacto directo y medible en
Necesidades del negocio.
Si bien los impulsores específicos de la criticidad diferirán según la industria, existen características comunes en todas las organizaciones. Los
datos se pueden evaluar en función de si son necesarios para:
• Informes regulatorios • Informes
financieros • Política comercial •
Operaciones en curso • Estrategia
comercial, especialmente los
esfuerzos de diferenciación competitiva
Los datos maestros son críticos por definición. Los conjuntos de datos o elementos de datos individuales pueden evaluarse en cuanto a su
criticidad en función de los procesos que los consumen, la naturaleza de los informes en los que aparecen o el riesgo financiero, regulatorio o
reputacional para la organización si algo sale mal con los datos. 73
1.3.3 Dimensiones de la calidad de los datos
Una dimensión de calidad de datos es una característica medible o característica de los datos. El término dimensión se usa para hacer la conexión
con las dimensiones en la medición de objetos físicos (por ejemplo, largo, ancho, alto). Las dimensiones de calidad de datos proporcionan un
vocabulario para definir los requisitos de calidad de datos. A partir de ahí, se pueden utilizar para definir los resultados de la evaluación inicial de
la calidad de los datos, así como la medición en curso. Para medir la calidad de los datos, una organización necesita establecer características
que sean importantes para los procesos comerciales (que vale la pena medir) y medibles. Las dimensiones proporcionan una base para las reglas
medibles, que a su vez deben estar directamente conectadas con los riesgos potenciales en los procesos críticos.
73 Ver Jugulum (2014), Capítulos 6 y 7 para un enfoque para racionalizar datos críticos.
Por ejemplo, si los datos en el campo de la dirección de correo electrónico del cliente están incompletos, no podremos enviar
información del producto a nuestros clientes por correo electrónico y perderemos ventas potenciales. Por lo tanto, mediremos el
porcentaje de clientes para los que tenemos direcciones de correo electrónico utilizables y mejoraremos nuestros procesos hasta que
tener una dirección de correo electrónico utilizable para al menos el 98% de nuestros clientes.
Muchos pensadores líderes en calidad de datos han publicado conjuntos de dimensiones.74 Las tres más influyentes se
describen aquí porque brindan información sobre cómo pensar sobre lo que significa tener datos de alta calidad, así como sobre
cómo se puede medir la calidad de los datos.
El marco StrongWang (1996) se centra en las percepciones de los datos por parte de los consumidores de datos. Describe 15
dimensiones en cuatro categorías generales de calidad de datos:
• DQ intrínseco o
Precisión o
Objetividad o
Credibilidad o
Reputación • DQ
contextual
o Valor agregado
o Relevancia
o Puntualidad
o Integridad o
Cantidad adecuada de datos • DQ
representacional o Interpretabilidad o Facilidad
de comprensión o Consistencia
representacional o Representación
concisa • Accesibilidad DQ o
Accesibilidad o Seguridad de acceso
En Data Quality for the Information Age (1996), Thomas Redman formuló un conjunto de dimensiones de calidad de datos
arraigadas en la estructura de datos.75 Redman define un elemento de datos como un "triple representable": un valor del dominio
de un atributo dentro de una entidad. Las dimensiones se pueden asociar con cualquiera de los componentes de los datos: el
modelo (entidades y atributos), así como los valores. Redman incluye la dimensión de representación, que define como un
conjunto de reglas para registrar elementos de datos. Dentro de estas tres categorías generales (modelo de datos, valores de
datos, representación), describe más de dos docenas de dimensiones. Incluyen lo siguiente:
74 Además de los ejemplos detallados aquí y numerosos artículos académicos sobre este tema, consulte Loshin (2001), Olson (2003), McGilvray
(2008) y SebastianColeman (2013) para obtener discusiones detalladas sobre las dimensiones de la calidad de los datos. Ver Myers (2013) para
una comparación de dimensiones.
75 Redman amplió y revisó su conjunto de dimensiones en Data Quality: The Field Guide (2001).
456 • DMBOK2
Modelo de datos:
• Contenido:
o Relevancia de los datos
o La capacidad de obtener los valores o
Claridad de las definiciones
• Nivel de detalle:
o Granularidad de atributos
o Precisión de los dominios de atributos
• Composición: o
Naturalidad: la idea de que cada atributo debe tener una contraparte simple en el mundo real y que cada
atributo debe relacionarse con un hecho único sobre la entidad o Capacidad de identificación: cada
entidad debe distinguirse de cualquier otra entidad o Homogeneidad o Redundancia mínima necesaria •
Coherencia: o Coherencia semántica de los componentes del modelo o Coherencia estructural de atributos
entre tipos de entidad • Reacción al cambio:
o Robustez
o Flexibilidad
Valores de datos:
• Exactitud •
Integridad • Actualidad
• Consistencia
Representación:
• Idoneidad •
Interpretabilidad •
Portabilidad • Precisión
del formato • Flexibilidad
del formato • Habilidad
para representar valores nulos • Uso
eficiente del almacenamiento • Instancias
físicas de datos de acuerdo con sus formatos
Redman reconoce que la coherencia de las entidades, los valores y la representación se puede entender en términos de
restricciones. Los diferentes tipos de consistencia están sujetos a diferentes tipos de restricciones.
En Improving Data Warehouse and Business Information Quality (1999), Larry English presenta un conjunto completo de dimensiones divididas
en dos amplias categorías: inherentes y pragmáticas.76 Las características inherentes son independientes del uso de datos. Las características
pragmáticas están asociadas con la presentación de datos y son dinámicas; su valor (calidad) puede cambiar dependiendo de los usos de los
datos.
• Características de calidad inherentes
o Conformidad con la definición
o Integridad de los valores o Validez
o conformidad con las reglas de negocio o Precisión
de una fuente sustituta o Precisión de la realidad
o Precisión
o No duplicación o
Equivalencia de datos redundantes o distribuidos o
Concurrencia de datos redundantes o distribuidos •
Características de calidad pragmática o Accesibilidad
o Puntualidad
o Claridad contextual o
Usabilidad o Integridad de
la derivación o Corrección o
integridad de los hechos
En 2013, DAMA UK elaboró un libro blanco que describía seis dimensiones fundamentales de la calidad de los datos:
• Completitud: la proporción de datos almacenados frente al potencial del 100%. • Singularidad: ninguna
instancia de entidad (cosa) se registrará más de una vez en función de cómo es esa cosa.
identificado.
• Oportunidad: el grado en que los datos representan la realidad desde el momento requerido. • Validez: Los datos
son válidos si se ajustan a la sintaxis (formato, tipo, rango) de su definición. • Precisión: el grado en que los datos
describen correctamente el objeto o evento del 'mundo real'
descrito.
• Consistencia: La ausencia de diferencia, cuando se comparan dos o más representaciones de una cosa
contra una definición.
El libro blanco de DAMA UK también describe otras características que tienen un impacto en la calidad. Si bien el libro blanco no menciona
estas dimensiones, funcionan de manera similar al DQ contextual y representacional de Strong y Wang y las características pragmáticas del
inglés.
• Usabilidad: ¿Son los datos comprensibles, simples, relevantes, accesibles, mantenibles y en el nivel correcto?
de precisión?
76 English amplió y revisó sus dimensiones en Information Quality Applied (2009).
458 • DMBOK2
• Cuestiones de tiempo (más allá de la puntualidad en sí misma): ¿Es estable pero responde a las solicitudes de cambio
legítimas? • Flexibilidad: ¿Son los datos comparables y compatibles con otros datos? ¿Tiene agrupaciones útiles y
clasificaciones? ¿Se puede reutilizar? ¿Es fácil de manipular?
• Confianza: ¿Existen procesos de gobierno de datos, protección de datos y seguridad de datos? Cuál es el
reputación de los datos, y es verificable o verificable?
• Valor: ¿Existe un buen caso de costo/beneficio para los datos? ¿Se está utilizando de manera óptima? ¿pone en peligro
la seguridad o privacidad de las personas, o las responsabilidades legales de la empresa? ¿Apoya o contradice la imagen
corporativa o el mensaje corporativo?
Si bien no existe un único conjunto acordado de dimensiones de calidad de datos, estas formulaciones contienen ideas comunes.
Las dimensiones incluyen algunas características que se pueden medir objetivamente (integridad, validez, conformidad del formato) y otras
que dependen en gran medida del contexto o de la interpretación subjetiva (usabilidad, confiabilidad, reputación). Independientemente de los
nombres que se utilicen, las dimensiones se centran en si hay suficientes datos (integridad), si son correctos (exactitud, validez), qué tan bien
encajan (coherencia, integridad, singularidad), si están actualizados (puntualidad). ), accesible, utilizable y seguro. La Tabla 29 contiene
definiciones de un conjunto de dimensiones de la calidad de los datos, sobre las cuales existe un acuerdo general y describe enfoques para
medirlas.
Tabla 29 Dimensiones comunes de la calidad de los datos
Dimensión de Descripción
Calidad
Precisión La precisión se refiere al grado en que los datos representan correctamente entidades de la "vida real". La precisión es difícil
de medir, a menos que una organización pueda reproducir la recopilación de datos o confirmar manualmente la precisión de
los registros. La mayoría de las medidas de precisión se basan en la comparación con una fuente de datos que ha sido
verificada como precisa, como un sistema de registro o datos de una fuente confiable (p. ej., datos de referencia de Dun and
Bradstreet).
Completitud La integridad se refiere a si todos los datos requeridos están presentes. La integridad se puede medir a nivel de conjunto de datos,
registro o columna. ¿El conjunto de datos contiene todos los registros esperados? ¿Se llenan correctamente los registros?
(Los registros con diferentes estados pueden tener diferentes expectativas de completitud). ¿Se completan las columnas/
atributos al nivel esperado? (Algunas columnas son obligatorias. Las columnas opcionales se completan solo bajo
condiciones específicas). Asigne reglas de integridad a un conjunto de datos con diferentes niveles de restricción: atributos
obligatorios que requieren un valor, elementos de datos con valores condicionales y opcionales y valores de atributo no
aplicables. Las mediciones del nivel del conjunto de datos pueden requerir una comparación con una fuente de registro o
pueden basarse en niveles históricos de población.
Consistencia La coherencia puede referirse a garantizar que los valores de los datos se representen de forma coherente dentro de
un conjunto de datos y entre conjuntos de datos, y que se asocien de forma coherente entre conjuntos de datos. También
puede referirse al tamaño y la composición de conjuntos de datos entre sistemas o a lo largo del tiempo. La coherencia se
puede definir entre un conjunto de valores de atributo y otro conjunto de atributos dentro del mismo registro (coherencia a
nivel de registro), entre un conjunto de valores de atributo y otro conjunto de atributos en diferentes registros (coherencia
entre registros), o entre un conjunto de valores de atributo y el mismo conjunto de atributos dentro del mismo registro en
diferentes momentos (coherencia temporal). La consistencia también se puede usar para referirse a la consistencia del
formato. Tenga cuidado de no confundir consistencia con exactitud o corrección.
Las características que se espera que sean consistentes dentro y entre conjuntos de datos se pueden usar como base
para estandarizar los datos. La estandarización de datos se refiere al condicionamiento de los datos de entrada para
garantizar que los datos cumplan con las reglas de contenido y formato. La estandarización de los datos permite una
coincidencia más efectiva y facilita una salida consistente. Encapsule las restricciones de coherencia como un conjunto de
reglas que especifican relaciones coherentes entre los valores de los atributos, ya sea en un registro o mensaje, o en todos
los valores de un solo atributo (como un rango o una lista de valores válidos). Por ejemplo, uno podría esperar que la
cantidad de transacciones cada día no supere el 105 % de la cantidad promedio móvil de transacciones de los 30 días
anteriores.
Dimensión de Descripción
Calidad
Integridad La integridad de los datos (o coherencia) incluye ideas asociadas con la integridad, la precisión y la coherencia. En
los datos, la integridad generalmente se refiere a la integridad referencial (coherencia entre los objetos de datos a través
de una clave de referencia contenida en ambos objetos) o la coherencia interna dentro de un conjunto de datos, de modo que
no haya agujeros ni partes faltantes. Los conjuntos de datos sin integridad se consideran corruptos o tienen pérdida de datos.
Los conjuntos de datos sin integridad referencial tienen "huérfanos" (claves de referencia no válidas) o "duplicados" (filas
idénticas que pueden afectar negativamente a las funciones de agregación). El nivel de registros huérfanos se puede medir
como un recuento sin procesar o como un porcentaje del conjunto de datos.
Razonabilidad La razonabilidad pregunta si un patrón de datos cumple con las expectativas. Por ejemplo, si una distribución de ventas en un área
geográfica tiene sentido según lo que se sabe sobre los clientes en esa área. La medición de la razonabilidad puede tomar
diferentes formas. Por ejemplo, la razonabilidad puede basarse en la comparación con datos de referencia o instancias
anteriores de un conjunto de datos similar (por ejemplo, ventas del trimestre anterior). Algunas ideas sobre la razonabilidad
pueden percibirse como subjetivas. Si este es el caso, trabaje con los consumidores de datos para articular la base de sus
expectativas de datos para formular comparaciones objetivas. Una vez que se establecen las medidas de referencia de la
razonabilidad, se pueden usar para comparar objetivamente nuevas instancias del mismo conjunto de datos para detectar
cambios. (Consulte la Sección 4.5.)
Oportunidad El concepto de datos La oportunidad se refiere a varias características de los datos. Las medidas de oportunidad deben
entenderse en términos de volatilidad esperada: con qué frecuencia es probable que cambien los datos y por qué motivos. La
vigencia de los datos es la medida de si los valores de los datos son la versión más actualizada de la información. Los datos
relativamente estáticos, por ejemplo, algunos valores de datos de referencia como los códigos de países, pueden permanecer
actualizados durante un período prolongado. Los datos volátiles permanecen actualizados durante un breve período. Algunos
datos, por ejemplo, los precios de las acciones en las páginas web financieras, a menudo se mostrarán con fecha actual, de
modo que los consumidores de datos comprendan el riesgo de que los datos hayan cambiado desde que se registraron.
Durante el día, mientras los mercados estén abiertos, dichos datos se actualizarán con frecuencia. Una vez que los mercados
cierran, los datos permanecerán sin cambios, pero seguirán siendo actuales, ya que el propio mercado está inactivo. La
latencia mide el tiempo entre el momento en que se crearon los datos y el momento en que estuvieron disponibles para su
uso. Por ejemplo, el procesamiento por lotes durante la noche puede generar una latencia de 1 día a las 8 a. m. para los datos
ingresados en el sistema durante el día anterior, pero solo una hora para los datos generados durante el procesamiento por
lotes. (Consulte el Capítulo 8.)
Singularidad / La singularidad establece que ninguna entidad existe más de una vez dentro del conjunto de datos. Afirmar la unicidad de las
Deduplicación entidades dentro de un conjunto de datos implica que un valor clave se relaciona con cada entidad única, y solo con esa
entidad específica, dentro del conjunto de datos. Mida la unicidad al probar contra la estructura clave. (Consulte el Capítulo 5.)
Validez La validez se refiere a si los valores de los datos son consistentes con un dominio definido de valores. Un dominio de valores
puede ser un conjunto definido de valores válidos (como en una tabla de referencia), un rango de valores o un valor que se
puede determinar mediante reglas. El tipo de datos, el formato y la precisión de los valores esperados deben tenerse en cuenta
al definir el dominio. Los datos también pueden ser válidos solo durante un período de tiempo específico, por ejemplo, los datos
que se generan a partir de RFID (identificación por radiofrecuencia) o algunos conjuntos de datos científicos. Valide los datos
comparándolos con las restricciones del dominio. Tenga en cuenta que los datos pueden ser válidos (es decir, pueden cumplir
con los requisitos del dominio) y aun así no ser precisos o estar asociados correctamente con registros particulares.
La Figura 92 alinea las dimensiones de la calidad de los datos y los conceptos asociados con esas dimensiones. Las flechas indican
superposiciones significativas entre conceptos y también demuestran que no hay acuerdo sobre un conjunto específico. Por ejemplo, la dimensión
de precisión está asociada con 'concuerda con el mundo real' y 'coincide con la fuente acordada' y también con los conceptos asociados con la
validez, como 'derivación correcta'.
460 • DMBOK2
Dimensión Conceptos
Está de acuerdo con el mundo real
PRECISIÓN
Coincidir con la fuente acordada
Fila poblada
Columna poblada
LO COMPLETO
Tabla poblada
Esquema poblado
Equivalencia de datos redundantes o distribuidos
CONSISTENCIA
Coherencia lógica
Concurrencia de datos distribuidos
MONEDA
Actual con el mundo
ID único de entidad
INTEGRIDAD DE LOS DATOS Cardinalidad
Integridad referencial de datos
Precisión de los valores de datos
PRECISIÓN
Datos suficientes para completar una tarea dada
Cumplimiento de los controles
PRIVACIDAD
Coherencia dentro de la tarea operativa
SENSATEZ
Considerado como verdadero y creíble
Expectativa de Disponibilidad
OPORTUNIDAD
Flotador manual y electrónico
Exclusividad del elemento con conjunto de datos
Exclusividad de entidad con conjunto de datos
UNICIDAD
Redundancia controlada
Control de valores válidos
Derivación correcta
VALIDEZ
Los valores se ajustan a las reglas comerciales
Los valores se ajustan a otras especificaciones de tipos de datos
Facilidad de obtención de datos
Control de acceso
ACCESIBILIDAD
Retención
Figura 92 Relación entre dimensiones de calidad de datos 77
77 Adaptado de Myers (2013), utilizado con autorización.
1.3.4 Calidad de datos y metadatos
Los metadatos son fundamentales para gestionar la calidad de los datos. La calidad de los datos se basa en qué tan bien cumplen con los
requisitos de los consumidores de datos. Los metadatos definen lo que representan los datos. Tener un proceso sólido mediante el cual se
definen los datos respalda la capacidad de una organización para formalizar y documentar los estándares y requisitos mediante los cuales
se puede medir la calidad de los datos. La calidad de los datos se trata de cumplir con las expectativas. Los metadatos son un medio
principal para aclarar las expectativas.
Los metadatos bien administrados también pueden respaldar el esfuerzo por mejorar la calidad de los datos. Un repositorio de metadatos
puede albergar los resultados de las mediciones de calidad de datos para que se compartan en toda la organización y el equipo de calidad
de datos pueda trabajar para lograr un consenso sobre las prioridades y los impulsores de mejora. (Consulte el Capítulo 12.)
1.3.5 Estándar ISO de calidad de datos
ISO 8000, el estándar internacional para la calidad de los datos, se está desarrollando para permitir el intercambio de datos complejos en
una forma de aplicación neutral. En la introducción a la norma, ISO afirma: “La capacidad de crear, recopilar, almacenar, mantener, transferir,
procesar y presentar datos para respaldar los procesos comerciales de manera oportuna y rentable requiere tanto la comprensión de las
características de los datos que determinar su calidad y la capacidad de medir, gestionar e informar sobre la calidad de los datos”.
ISO 8000 define características que pueden ser probadas por cualquier organización en la cadena de suministro de datos para determinar
objetivamente la conformidad de los datos con ISO 8000.78
La primera parte publicada de ISO 8000 (parte 110, publicada en 2008) se centró en la sintaxis, la codificación semántica y la
conformidad con la especificación de datos de Master Data. Otras partes proyectadas para el estándar incluyen la parte 100
Introducción, la parte 120 Procedencia, la parte 130 Precisión y la parte 140 Completitud.79
ISO define los datos de calidad como “datos portátiles que cumplen con los requisitos establecidos”. 80 El estándar de calidad de datos está
relacionado con el trabajo general de ISO sobre portabilidad y preservación de datos. Los datos se consideran 'portátiles' si se pueden
separar de una aplicación de software. Los datos que solo se pueden usar o leer con una aplicación de software con licencia específica
están sujetos a los términos de la licencia de software. Es posible que una organización no pueda usar los datos que creó
a menos que esos datos puedan separarse del software que se usó para crearlos.
Para cumplir con los requisitos establecidos se requiere que estos requisitos se definan de manera clara e inequívoca. ISO 8000 es
compatible con ISO 22745, un estándar para definir e intercambiar datos maestros. ISO 22745 define cómo deben construirse las
declaraciones de requisitos de datos, proporciona ejemplos en XML y define un formato para
78 http://bit.ly/2ttdiZJ.
79 http://bit.ly/2sANGdi.
80 http://bit.ly/2rV1oWC.
462 • DMBOK2
el intercambio de datos codificados.81 ISO 22745 crea datos portátiles mediante el etiquetado de los datos mediante un diccionario técnico abierto
compatible con ISO 22745, como el diccionario técnico abierto ECCMA (eOTD).
La intención de ISO 8000 es ayudar a las organizaciones a definir qué son y qué no son datos de calidad, permitirles solicitar datos de calidad
utilizando convenciones estándar y verificar que han recibido datos de calidad utilizando esos mismos estándares. Cuando se siguen los estándares,
los requisitos se pueden confirmar a través de un programa de computadora.
ISO 8000 Parte 61 El modelo de referencia del proceso de gestión de calidad de datos e información está en desarrollo.82 Esta norma describirá
la estructura y organización de la gestión de calidad de datos, incluyendo:
• Planificación de la calidad de los
datos • Control de la calidad de los
datos • Garantía de la calidad de los
datos • Mejora de la calidad de los datos
1.3.6 Ciclo de vida de mejora de la calidad de los datos
La mayoría de los enfoques para mejorar la calidad de los datos se basan en las técnicas de mejora de la calidad en la fabricación de productos
físicos.83 En este paradigma, los datos se entienden como el producto de un conjunto de procesos. En su forma más simple, un proceso se define
como una serie de pasos que convierte las entradas en salidas. Un proceso que crea datos puede constar de un solo paso (recopilación de datos) o
de muchos pasos: recopilación de datos, integración en un almacén de datos, agregación en un data mart, etc. En cualquier paso, los datos pueden
verse afectados negativamente. Se puede recopilar incorrectamente, descartar o duplicar entre sistemas, alinear o agregar incorrectamente, etc.
Mejorar la calidad de los datos requiere la capacidad de evaluar la relación entre entradas y salidas, para garantizar que las entradas cumplan con
los requisitos del proceso y que las salidas cumplan a las expectativas. Dado que las salidas de un proceso se convierten en entradas para otros
procesos, los requisitos deben definirse a lo largo de toda la cadena de datos.
Un enfoque general para mejorar la calidad de los datos, que se muestra en la Figura 93, es una versión del ciclo Shewhart/Deming. 'planificarhacer
84
verificaractuar'.
La e
Basado mn
ejora
viene a
el método través de
científico, ucn
el conjunto
iclo definido de pasos.
de Shewhart/Deming es uLn
a
mcondición
odelo de dresolución
e los datos
se
de debe medir
problemas con respecto
conocido como a los estándares
y, si no cumple con los estándares, se deben identificar y remediar las causas raíz de la discrepancia con los estándares. Las causas fundamentales
se pueden encontrar en cualquiera de los pasos del proceso, técnicos o no técnicos. Una vez remediados, los datos deben monitorearse para
garantizar que continúen cumpliendo con los requisitos.
81 http://bit.ly/2rUZyoz.
82 http://bit.ly/2sVik3Q.
83
Véase Wang (1998), English (1999), Redman (2001), Loshin (2001) y McGilvray (2008). Consulte Pierce (2004) para obtener una descripción
general de la literatura relacionada con el concepto de datos como producto.
84
Consulte la Sociedad Estadounidense para la Calidad: http://bit.ly/1lelyBK PlanDoCheckAct fue originado por Walter Shewhart y popularizado
por W. Edwards Deming. Medir, Analizar, Mejorar, Controlar (DMAIC) de 6 Sigma es una variación de este ciclo.
PLAN HACER
ACTUAR CONTROLAR
Figura 93 El gráfico de Shewhart
Para un conjunto de datos determinado, un ciclo de gestión de calidad de datos comienza con la identificación de los datos que no cumplen
con los requisitos de los consumidores de datos y los problemas de datos que son obstáculos para el logro de los objetivos comerciales. Los
datos deben evaluarse frente a dimensiones clave de calidad y requisitos comerciales conocidos. Causas raíz de los problemas
será necesario identificar para que las partes interesadas puedan comprender los costos de remediación y los riesgos de no
remediando los problemas. Este trabajo a menudo se realiza en conjunto con Data Stewards y otras partes interesadas.
En la etapa de planificación , el equipo de calidad de datos evalúa el alcance, el impacto y la prioridad de los problemas conocidos y evalúa
las alternativas para abordarlos. Este plan debe basarse en una base sólida de análisis de las causas fundamentales de los problemas. A
partir del conocimiento de las causas y el impacto de los problemas, se puede comprender el costo/beneficio, se puede determinar la prioridad
y se puede formular un plan básico para abordarlos.
En la etapa Hacer , el equipo de DQ lidera los esfuerzos para abordar las causas fundamentales de los problemas y planificar el monitoreo
continuo de los datos. Para las causas fundamentales que se basan en procesos no técnicos, el equipo de DQ puede trabajar con los
propietarios de los procesos para implementar cambios. Para las causas fundamentales que requieren cambios técnicos, el equipo de DQ
debe trabajar con los equipos técnicos para garantizar que los requisitos se implementen correctamente y que los cambios técnicos no introduzcan errores.
La etapa de Verificación implica monitorear activamente la calidad de los datos medidos contra los requisitos. Siempre que los datos cumplan
con los umbrales de calidad definidos, no se requieren acciones adicionales. Los procesos se considerarán bajo control y cumpliendo los
requisitos del negocio. Sin embargo, si los datos caen por debajo de los umbrales de calidad aceptables, se deben tomar medidas adicionales
para llevarlos a niveles aceptables.
La etapa de Actuar es para actividades para abordar y resolver problemas emergentes de calidad de datos. El ciclo se reinicia, a medida que
se evalúan las causas de los problemas y se proponen soluciones. La mejora continua se logra iniciando un nuevo ciclo. Los nuevos ciclos
comienzan como:
• Las mediciones existentes caen por debajo de los umbrales
• Se investigan nuevos conjuntos de datos • Surgen nuevos
requisitos de calidad de datos para los conjuntos de datos existentes • Las reglas
comerciales, los estándares o las expectativas cambian
464 • DMBOK2
El costo de obtener los datos correctamente la primera vez es más económico que los costos de obtener datos incorrectos y corregirlos más tarde.
Construir calidad en los procesos de gestión de datos desde el principio cuesta menos que actualizarlos.
Mantener datos de alta calidad durante todo el ciclo de vida de los datos es menos riesgoso que tratar de mejorar la calidad en un proceso existente.
También crea un impacto mucho menor en la organización. Establecer criterios para la calidad de los datos al comienzo de la construcción de un
proceso o sistema es una señal de una organización de gestión de datos madura. Hacerlo requiere gobierno y disciplina, así como colaboración
interfuncional.
1.3.7 Tipos de reglas comerciales de calidad de datos
Las reglas comerciales describen cómo los negocios deben operar internamente para tener éxito y cumplir con el mundo exterior. Las reglas
comerciales de calidad de datos describen cómo deben existir los datos para que sean útiles y utilizables dentro de una organización. Estas reglas
pueden alinearse con las dimensiones de la calidad y usarse para describir los requisitos de calidad de los datos. Por ejemplo, una regla comercial
que establece que todos los campos de código de estado deben cumplir con las abreviaturas de estado de EE. UU. se puede aplicar mediante listas
de selección de entrada de datos y búsquedas de integración de datos. El nivel de válido o no válido
entonces se pueden medir los registros.
Las reglas comerciales se implementan comúnmente en el software o mediante el uso de plantillas de documentos para la entrada de datos.
Algunos tipos de reglas comerciales simples comunes son:
• Conformidad con las definiciones: confirme que la misma comprensión de las definiciones de datos se implementa y utiliza correctamente
en los procesos de toda la organización. La confirmación incluye un acuerdo algorítmico sobre los campos calculados, incluidas las
restricciones locales o de tiempo, y la interdependencia de acumulación y estado.
normas.
• Presencia de valor y completitud del registro: Reglas que definen las condiciones bajo las cuales los valores faltantes
son aceptables o inaceptables.
• Cumplimiento de formato: uno o más patrones especifican valores asignados a un elemento de datos, como estándares para
formatear números de teléfono.
• Membresía de dominio de valor: especifique que el valor asignado de un elemento de datos se incluye en esos
enumerados en un dominio de valor de datos definido, como códigos postales de Estados Unidos de 2 caracteres para un
campo ESTADO.
• Conformidad con el rango: un valor asignado a un elemento de datos debe estar dentro de un valor numérico, lexicográfico,
o rango de tiempo, como mayor que 0 y menor que 100 para un rango numérico.
• Conformidad de mapeo: indica que el valor asignado a un elemento de datos debe corresponder a uno seleccionado de un dominio de
valor que se mapea a otro(s) dominio(s) de valor equivalente equivalente. El dominio de datos ESTADO nuevamente brinda un buen
ejemplo, ya que los valores de Estado pueden representarse usando diferentes dominios de valor (códigos postales de USPS,
códigos FIPS de 2 dígitos, nombres completos), y este tipo de reglas validan que 'AL' y '01' mapa a 'Alabama'.
• Reglas de consistencia: Aserciones condicionales que se refieren a mantener una relación entre dos (o
más) atributos basados en los valores reales de esos atributos. Por ejemplo, validación de direcciones donde los códigos postales
corresponden a estados o provincias particulares.
• Verificación de precisión: compare un valor de datos con un valor correspondiente en un sistema de registro u otra fuente verificada (p. ej.,
datos de marketing comprados a un proveedor) para verificar que los valores coincidan.
• Verificación de unicidad: Reglas que especifican qué entidades deben tener una representación única y
si existe uno y solo un registro para cada objeto del mundo real representado.
• Validación de oportunidad: Reglas que indican las características asociadas a las expectativas de
accesibilidad y disponibilidad de los datos.
Otros tipos de reglas pueden involucrar funciones de agregación aplicadas a conjuntos de instancias de datos (consulte la Sección 4.5).
Los ejemplos de verificaciones de agregación incluyen:
• Validar la razonabilidad del número de registros en un archivo. Esto requiere mantener estadísticas a lo largo del tiempo para
generar tendencias.
• Validar la razonabilidad de un monto promedio calculado a partir de un conjunto de transacciones. Esto requiere establecer umbrales
para la comparación y puede basarse en estadísticas a lo largo del tiempo.
• Validar la variación esperada en el recuento de transacciones durante un período de tiempo específico. Esto requiere
mantener estadísticas a lo largo del tiempo y usarlas para establecer umbrales.
1.3.8 Causas comunes de problemas de calidad de datos
Los problemas de calidad de los datos pueden surgir en cualquier punto del ciclo de vida de los datos, desde la creación hasta la eliminación. Al
investigar las causas fundamentales, los analistas deben buscar culpables potenciales, como problemas con la entrada de datos, el procesamiento de
datos, el diseño del sistema y la intervención manual en procesos automatizados. Muchos problemas tendrán múltiples causas y factores contribuyentes
(especialmente si las personas han creado formas de solucionarlos). Estas causas de problemas también implican formas de prevenir problemas: a
través de la mejora del diseño de la interfaz, la prueba de las reglas de calidad de los datos como parte del procesamiento, un enfoque en la calidad
de los datos dentro del diseño del sistema y controles estrictos sobre la intervención manual en los procesos automatizados.
1.3.8.1 Problemas causados por la falta de liderazgo
Mucha gente asume que la mayoría de los problemas de calidad de los datos son causados por errores de entrada de datos. Una comprensión más
sofisticada reconoce que las lagunas o la ejecución deficiente de los procesos comerciales y técnicos causan muchos más problemas que los errores
de tecleo. Sin embargo, el sentido común dice y la investigación indica que muchos problemas de calidad de los datos se deben a la falta de
compromiso de la organización con los datos de alta calidad, que a su vez se deriva de la falta de liderazgo, tanto en forma de gobierno como de
gestión.
466 • DMBOK2
Cada organización tiene activos de información y datos que son valiosos para sus operaciones. De hecho, las operaciones de cada organización dependen
de la capacidad de compartir información. A pesar de ello, pocas organizaciones gestionan estos activos con rigor. Dentro de la mayoría de las
organizaciones, la disparidad de datos (diferencias en la estructura de datos, el formato y el uso de valores) es un problema mayor que los simples errores;
puede ser un gran obstáculo para la integración de datos. Una de las razones por las que los programas de administración de datos se enfocan en definir
términos y consolidar el lenguaje en torno a los datos es porque ese es el punto de partida para obtener datos más consistentes.
Muchos programas de activos de información y gobierno están impulsados únicamente por el cumplimiento, en lugar del valor potencial que se deriva de
los datos como un activo. La falta de reconocimiento por parte del liderazgo significa una falta de compromiso dentro de una organización para gestionar los
datos como un activo, incluida la gestión de su calidad (Evans y Price, 2012). (Consulte la Figura 94.)
Las barreras para la gestión eficaz de la calidad de los datos incluyen:85
• Falta de conciencia por parte del liderazgo y el personal • Falta de gobierno
empresarial • Falta de liderazgo y gestión • Dificultad en la justificación de las
mejoras • Instrumentos inadecuados o ineficaces para medir el valor
Estas barreras tienen efectos negativos en la experiencia del cliente, la productividad, la moral, la eficacia organizacional, los ingresos y la ventaja
competitiva. Aumentan los costos de funcionamiento de la organización y también introducen riesgos. (Consulte el Capítulo 11.)
1.3.8.2 Problemas causados por los procesos de entrada de datos
• Problemas de la interfaz de entrada de datos: las interfaces de entrada de datos mal diseñadas pueden contribuir a la calidad de los datos
asuntos. Si una interfaz de ingreso de datos no tiene ediciones o controles para evitar que se ingresen datos incorrectos en el sistema, es
probable que los procesadores de datos tomen atajos, como omitir campos no obligatorios y no actualizar los campos predeterminados.
• Colocación de entrada de lista: Incluso las características simples de las interfaces de entrada de datos, como el orden de los valores dentro
una lista desplegable, puede contribuir a errores de entrada de datos.
• Sobrecarga de campos: algunas organizaciones reutilizan campos a lo largo del tiempo para diferentes propósitos comerciales en lugar de
realizar cambios en el modelo de datos y la interfaz de usuario. Esta práctica da como resultado una población inconsistente y confusa de
los campos.
• Problemas de capacitación: la falta de conocimiento del proceso puede conducir a una entrada de datos incorrecta, incluso si existen controles y
ediciones. Si los procesadores de datos no son conscientes del impacto de los datos incorrectos o si están incentivados por la velocidad, en
lugar de la precisión, es probable que tomen decisiones basadas en factores distintos a la calidad de la información.
los datos.
85 Adaptado de The Leader's Data Manifesto. https://dataleaders.org/.
falta de negocio Dificultad en
Gobernancia Justificación
Los mercados no exigen
Falta de responsabilidad
lo hacen
Falta de propiedad No se comprende el costo de
administrar los activos de información
no está claro quién es
El valor de los datos depende del
responsable de que
contexto y es difícil de precisar
Cliente
Falta medir a Los beneficios son difíciles de obtener
Experiencia
guiar la acción
Business Cases no crea un
Organización
sensación de urgencia Prontitud
No Ingresos
Falta de educación Información

terciaria Activos No Competitivo
Conciencia
Ventaja
• Ejecutivo • Mediodía Adecuadamente
Practicante educación Administrado

Productividad
en el trabajo No sé cómo poner la
información a trabajar
No se entienden las Costos
herramientas de gestión de la información.
Carecen de la capacidad para hacer el trabajo.
No invierten en calidad, lo que aumenta los Riesgo
El lenguaje es impreciso
costos y complica los esfuerzos para usar los datos. • Continuidad •
Cultura inapropiada (ej. intuición valorada Software visto como una panacea/ Cumplimiento •
sobre los “hechos”, información no valorada confusión sobre TI vs. datos Descubrimiento •
como activo) Seguridad
Estructura inapropiada (p. ej., los silos Los principios contables no
impiden compartir) permiten la capitalización de los
Confundido acerca de "quién hace qué" activos de información
Falta liderazgo proactivo.
Ausencia:
Falta el equivalente de GAAP
• Visión
• Estrategia •
Política •
Principios Rectores •
Falta de
Sistema de Gestión Inapropiado o ineficaz
Liderazgo y
Gestión
Instrumentos
© 2017 dataleaders.org
Usado con permiso
Barreras que ralentizan/dificultan/
impiden que las empresas gestionen
su información como un activo empresarial
Causas raíz más comúnmente observadas
Danette McGilvray/James Price/Tom Redman
octubre 2016
Trabajo basado en la investigación de la Dra. Nina Evans y James Price,
consulte "Barreras para el despliegue efectivo de activos de información"
en www.dataleaders.org
Figura 94 Obstáculos para la gestión de la información como un activo comercial86
• Cambios en los procesos comerciales: los procesos comerciales cambian con el tiempo y, con estos cambios, se
introducen nuevas reglas comerciales y requisitos de calidad de datos. Sin embargo, los cambios en las reglas
comerciales no siempre se incorporan a los sistemas de manera oportuna o integral. Se producirán errores de
datos si una interfaz no se actualiza para adaptarse a requisitos nuevos o modificados. Además, es probable que
los datos se vean afectados a menos que los cambios en las reglas comerciales se propaguen por todo el sistema.
86 Diagrama desarrollado por Danette McGilvray, James Price y Tom Redman. Usado con permiso. https://dataleaders.org/.
468 • DMBOK2
• Ejecución de procesos comerciales inconsistentes: es probable que los datos creados a través de procesos que se ejecutan de
manera inconsistente sean inconsistentes. La ejecución inconsistente puede deberse a problemas de capacitación o
documentación, así como a cambios en los requisitos.
1.3.8.3 Problemas causados por las funciones de procesamiento de datos
• Suposiciones incorrectas sobre las fuentes de datos: pueden ocurrir problemas de producción debido a errores o cambios,
documentación del sistema inadecuada u obsoleta, o transferencia de conocimiento inadecuada (por ejemplo, cuando las PYME se van
sin documentar su conocimiento). Las actividades de consolidación de sistemas, como las asociadas con fusiones y adquisiciones, a
menudo se basan en un conocimiento limitado sobre la relación entre los sistemas. Cuando es necesario integrar varios sistemas de origen
y fuentes de datos, siempre existe el riesgo de que se pasen por alto detalles, especialmente con diferentes niveles de conocimiento de
origen disponibles y ajustados.
lineas de tiempo
• Reglas comerciales obsoletas: con el tiempo, las reglas comerciales cambian. Deben ser revisados periódicamente y
actualizado. Si hay medición automatizada de reglas, también se debe actualizar el proceso técnico para la medición de reglas. Si no se
actualiza, es posible que no se identifiquen problemas o se produzcan falsos positivos (o ambos).
• Estructuras de datos modificadas: los sistemas de origen pueden cambiar estructuras sin informar aguas abajo
consumidores (tanto humanos como del sistema) o sin proporcionar tiempo suficiente para dar cuenta de los cambios.
Esto puede generar valores no válidos u otras condiciones que impidan el movimiento y la carga de datos, o cambios más sutiles que
pueden no detectarse de inmediato.
1.3.8.4 Problemas causados por el diseño del sistema
• Incumplimiento de la integridad referencial: la integridad referencial es necesaria para garantizar datos de alta calidad a nivel de aplicación o
sistema. Si no se aplica la integridad referencial o si se desactiva la validación (por ejemplo, para mejorar los tiempos de respuesta), pueden
surgir varios problemas de calidad de datos:
o Datos duplicados que rompen las reglas de exclusividad o Filas
huérfanas, que pueden incluirse en algunos informes y excluirse de otros, lo que genera múltiples valores para el mismo cálculo
o Incapacidad para actualizar debido a requisitos de integridad referencial restaurados o modificados o Datos
inexactos debido a que a los datos faltantes se les asignan valores predeterminados
• Incumplimiento de las restricciones de unicidad: Múltiples copias de instancias de datos dentro de una tabla o archivo
se espera que contenga instancias únicas. Si no hay suficientes comprobaciones de la unicidad de las instancias, o si las restricciones
únicas están desactivadas en la base de datos para mejorar el rendimiento, los resultados de la agregación de datos
puede ser exagerado.
• Inexactitudes y lagunas en la codificación: si el mapeo o el diseño de los datos es incorrecto, o las reglas para procesar los datos no son precisas,
los datos procesados tendrán problemas de calidad de los datos, que van desde cálculos incorrectos hasta datos asignados o vinculados a
campos inadecuados, claves o relaciones.
• Inexactitudes del modelo de datos: si los datos reales no respaldan las suposiciones dentro del modelo de datos, habrá problemas de calidad de
los datos que van desde la pérdida de datos debido a que los datos reales exceden las longitudes de los campos hasta la asignación de
datos a ID o claves incorrectas.
• Sobrecarga de campos: la reutilización de campos a lo largo del tiempo para diferentes propósitos, en lugar de cambiar el modelo de datos
o el código, puede generar conjuntos de valores confusos, significado poco claro y, potencialmente, problemas estructurales, como
claves asignadas incorrectamente.
• Discrepancias de datos temporales: en ausencia de un diccionario de datos consolidado, varios sistemas podrían implementar formatos de fecha
o tiempos dispares, lo que a su vez conduce a una discrepancia y pérdida de datos cuando la sincronización de datos tiene lugar entre
diferentes sistemas de origen.
• Gestión de datos maestros débil: la gestión de datos maestros inmadura puede llevar a elegir
fuentes de datos poco confiables, lo que puede causar problemas de calidad de datos que son muy difíciles de encontrar hasta que se
desmienta la suposición de que la fuente de datos es precisa.
• Duplicación de datos: la duplicación innecesaria de datos suele ser el resultado de una mala gestión de datos. Hay dos tipos principales de
problemas de duplicación no deseados:
o Fuente única: instancias locales múltiples: por ejemplo, instancias del mismo cliente en varias tablas (similares o idénticas) en la
misma base de datos. Saber qué instancia es la más precisa para su uso puede ser difícil sin un conocimiento específico del
sistema.
o Fuentes Múltiples – Instancia Única: Instancias de datos con múltiples fuentes autorizadas o
sistemas de registro. Por ejemplo, instancias de un solo cliente provenientes de múltiples sistemas de punto de venta. Al procesar
estos datos para su uso, puede haber áreas de almacenamiento temporal duplicadas.
Las reglas de combinación determinan qué fuente tiene prioridad sobre otras cuando se procesa en áreas de datos de producción
permanentes.
1.3.8.5 Problemas causados por solucionar problemas
Los parches de datos manuales son cambios realizados directamente en los datos de la base de datos, no a través de las reglas comerciales en las
interfaces o el procesamiento de la aplicación. Estos son scripts o comandos manuales generalmente creados a toda prisa y utilizados para "arreglar" datos
en una emergencia, como la inyección intencional de datos incorrectos, fallas en la seguridad, fraude interno o fuente externa para la interrupción del
negocio.
Como cualquier código no probado, tienen un alto riesgo de causar más errores debido a consecuencias no deseadas, al cambiar más datos de los
necesarios o al no propagar el parche a todos los datos históricos afectados por el problema original. La mayoría de estos parches también cambian los
datos en su lugar, en lugar de conservar el estado anterior y agregar
filas corregidas.
470 • DMBOK2
Por lo general, estos cambios NO se pueden deshacer sin una restauración completa desde la copia de seguridad, ya que solo existe el registro de la
base de datos para mostrar los cambios. Por lo tanto, se desaconsejan encarecidamente estos atajos: son oportunidades para brechas de seguridad e
interrupciones comerciales más largas de lo que causaría una corrección adecuada. Todos los cambios deben pasar por un proceso de gestión de
cambios gobernado.
1.3.9 Perfilado de datos
La creación de perfiles de datos es una forma de análisis de datos utilizada para inspeccionar datos y evaluar la calidad. El perfilado de datos utiliza
técnicas estadísticas para descubrir la verdadera estructura, contenido y calidad de una colección de datos (Olson, 2003). Un motor de creación de
perfiles produce estadísticas que los analistas pueden usar para identificar patrones en el contenido y la estructura de los datos. Por ejemplo:
• Recuentos de valores nulos: identifica la existencia de valores nulos y permite la inspección de si están permitidos o no • Valor máx./mín.:
identifica valores atípicos, como negativos • Longitud máx./mín.: identifica valores atípicos o no válidos para campos con requisitos de longitud
específicos • Distribución de frecuencia de valores para columnas individuales: Permite la evaluación de la razonabilidad (p. ej.,
distribución de códigos de país para transacciones, inspección de valores que ocurren con frecuencia o con poca frecuencia, así como el
porcentaje de los registros poblados con valores predeterminados)
• Tipo y formato de datos: identifica el nivel de incumplimiento de los requisitos de formato, así como
identificación de formatos inesperados (p. ej., número de decimales, espacios incrustados, valores de muestra)
La creación de perfiles también incluye análisis de columnas cruzadas, que pueden identificar columnas superpuestas o duplicadas y exponer
dependencias de valores incrustados. El análisis entre tablas explora conjuntos de valores superpuestos y ayuda a identificar las relaciones de clave
externa. La mayoría de las herramientas de creación de perfiles de datos permiten profundizar en los datos analizados para una mayor investigación.
Los resultados del motor de creación de perfiles deben ser evaluados por un analista para determinar si los datos se ajustan a las reglas y otros
requisitos. Un buen analista puede usar los resultados de la creación de perfiles para confirmar relaciones conocidas y descubrir características y
patrones ocultos dentro y entre conjuntos de datos, incluidas las reglas comerciales y las restricciones de validez. La creación de perfiles generalmente
se usa como parte del descubrimiento de datos para proyectos (especialmente proyectos de integración de datos; consulte el Capítulo 8) o para evaluar
el estado actual de los datos que se pretende mejorar. Los resultados de la elaboración de perfiles de datos se pueden utilizar para identificar
oportunidades para mejorar la calidad tanto de los datos como de los metadatos (Olson, 2003; Maydanchik, 2007).
Si bien la creación de perfiles es una forma efectiva de comprender los datos, es solo un primer paso para mejorar la calidad de los datos. Permite a las
organizaciones identificar problemas potenciales. Resolver problemas requiere otras formas de análisis, incluido el análisis de procesos comerciales, el
análisis del linaje de datos y un análisis de datos más profundo que puede ayudar a aislar las causas raíz de los problemas.
1.3.10 Calidad de datos y procesamiento de datos
Si bien el enfoque de los esfuerzos de mejora de la calidad de los datos suele estar en la prevención de errores, la calidad de los datos también se
puede mejorar a través de algunas formas de procesamiento de datos. (Consulte el Capítulo 8.)
1.3.10.1 Limpieza de datos
La limpieza o depuración de datos transforma los datos para que se ajusten a los estándares de datos y las reglas de dominio. La limpieza incluye
detectar y corregir errores de datos para llevar la calidad de los datos a un nivel aceptable.
Cuesta dinero e introduce riesgos para remediar continuamente los datos a través de la limpieza. Idealmente, la necesidad de limpieza de datos
debería disminuir con el tiempo, a medida que se resuelven las causas fundamentales de los problemas de datos. La necesidad de limpieza de datos
puede abordarse mediante:
• Implementar controles para evitar errores de entrada de datos • Corregir
los datos en el sistema de origen • Mejorar los procesos comerciales que
crean los datos
En algunas situaciones, puede ser necesario corregir de forma continua, ya que volver a procesar los datos en un sistema midstream es más
económico que cualquier otra alternativa.
1.3.10.2 Mejora de datos
La mejora o el enriquecimiento de datos es el proceso de agregar atributos a un conjunto de datos para aumentar su calidad y facilidad de uso.
Algunas mejoras se obtienen mediante la integración de conjuntos de datos internos de una organización. También se pueden comprar datos externos
para mejorar los datos de la organización (consulte el Capítulo 10). Ejemplos de mejora de datos incluyen:
• Marcas de hora/fecha: una forma de mejorar los datos es documentar la hora y la fecha en que se almacenan los elementos de datos.
creados, modificados o retirados, que pueden ayudar a rastrear eventos de datos históricos. Si se detectan problemas con los datos,
las marcas de tiempo pueden ser muy valiosas en el análisis de causa raíz, ya que permiten a los analistas aislar
el plazo de la cuestión.
• Datos de auditoría: la auditoría puede documentar el linaje de datos, lo cual es importante para el seguimiento histórico, así como para
validación.
• Vocabularios de referencia: la terminología, las ontologías y los glosarios específicos de la empresa mejoran
comprensión y control al tiempo que aporta un contexto empresarial personalizado.
• Información contextual: Agregar contexto como ubicación, entorno o métodos de acceso y
etiquetar datos para su revisión y análisis.
• Información geográfica : la información geográfica se puede mejorar a través de la estandarización de direcciones y la geocodificación, que
incluye codificación regional, municipio, mapeo de vecindarios, pares de latitud/longitud u otros tipos de datos basados en la ubicación.
• Información demográfica: los datos del cliente se pueden mejorar a través de la información demográfica, como la edad, el estado civil, el
sexo, los ingresos o la codificación étnica. Los datos de la entidad comercial se pueden asociar con los ingresos anuales, la cantidad
de empleados, el tamaño del espacio ocupado, etc.
472 • DMBOK2
• Información psicográfica: datos utilizados para segmentar las poblaciones objetivo por comportamientos, hábitos o
preferencias específicos, como preferencias de productos y marcas, membresías en organizaciones, actividades de
ocio, estilo de transporte para ir al trabajo, preferencias de tiempo de compras, etc.
• Información de valoración: utilice este tipo de mejora para la valoración, el inventario y la venta de activos.
1.3.10.3 Análisis y formateo de datos
El análisis de datos es el proceso de analizar datos utilizando reglas predeterminadas para definir su contenido o valor. El análisis de
datos permite al analista de datos definir conjuntos de patrones que alimentan un motor de reglas utilizado para distinguir entre valores
de datos válidos y no válidos. Hacer coincidir patrones específicos desencadena acciones.
El análisis de datos asigna características a los valores de datos que aparecen en una instancia de datos, y esas características
ayudan a determinar fuentes potenciales para obtener beneficios adicionales. Por ejemplo, si se puede determinar que un atributo
llamado 'nombre' tiene valores que pertenecen a 'nombre comercial' incrustados, entonces el valor de los datos se identifica como el
nombre de una empresa en lugar del nombre de una persona. Utilice el mismo enfoque para cualquier situación en la que los valores
de los datos se organicen en jerarquías semánticas, como subpiezas, piezas y ensamblajes.
Muchos problemas de calidad de los datos implican situaciones en las que la variación de los valores de los datos que representan
conceptos similares introduce ambigüedad. Extraer y reorganizar los componentes separados (comúnmente denominados "tokens")
se pueden extraer y reorganizar en una representación estándar para crear un patrón válido. Cuando se reconoce un patrón no válido,
la aplicación puede intentar transformar el valor no válido en uno que cumpla con las reglas. Realice la estandarización asignando
datos de algún patrón de origen a una representación de destino correspondiente.
Por ejemplo, considere las diferentes formas en que se formatea los números de teléfono que se espera que se ajusten a un plan de
numeración. Mientras que algunos tienen dígitos, algunos tienen caracteres alfabéticos y todos usan diferentes caracteres especiales
para la separación. Las personas pueden reconocer cada uno como un número de teléfono. Sin embargo, para determinar si estos
números son exactos (quizás comparándolos con un directorio maestro de clientes), o para investigar si existen números duplicados
cuando debería haber solo uno para cada proveedor, los valores deben analizarse en sus segmentos componentes (código de área ,
intercambio y número de línea) y luego transformado en un formato estándar.
Otro buen ejemplo es el nombre de un cliente, ya que los nombres se pueden representar en miles de formas diferentes. Una buena
herramienta de estandarización podrá analizar los diferentes componentes del nombre de un cliente, como el nombre de pila, el
segundo nombre, el apellido, las iniciales, los títulos, las designaciones generacionales, y luego reorganizar esos componentes en una
representación canónica que serán otros servicios de datos. capaz de manipular.
La capacidad humana para reconocer patrones familiares contribuye a la capacidad de caracterizar valores de datos variantes que
pertenecen a la misma clase abstracta de valores; las personas reconocen diferentes tipos de números de teléfono porque se ajustan
a patrones de uso frecuente. Un analista describe los patrones de formato que representan un objeto de datos, como el nombre de la
persona, la descripción del producto, etc. Una herramienta de calidad de datos analiza los valores de datos que se ajustan a cualquiera
de esos patrones, e incluso los transforma en una forma única y estandarizada que simplificará los procesos de evaluación, análisis de
similitud y remediación. El análisis basado en patrones puede automatizar el reconocimiento y la posterior estandarización de
componentes de valor significativos.
1.3.10.4 Transformación y estandarización de datos
Durante el procesamiento normal, las reglas de datos activan y transforman los datos en un formato que la arquitectura de destino puede
leer. Sin embargo, legible no siempre significa aceptable. Las reglas se crean directamente dentro de un flujo de integración de datos o
se basan en tecnologías alternativas integradas o accesibles desde dentro de una herramienta.
La transformación de datos se basa en este tipo de técnicas de estandarización. Guíe las transformaciones basadas en reglas asignando
valores de datos en sus formatos y patrones originales en una representación de destino. Los componentes analizados de un patrón están
sujetos a reordenamientos, correcciones o cualquier cambio según lo indiquen las reglas de la base de conocimiento. De hecho, la
estandarización es un caso especial de transformación, que emplea reglas que capturan el contexto, la lingüística y los modismos
reconocidos como comunes a lo largo del tiempo, a través de análisis repetidos por parte del analista de reglas o el proveedor de la
herramienta. (Consulte el Capítulo 3.)
2. Actividades
2.1 Definir datos de alta calidad
Muchas personas reconocen los datos de mala calidad cuando los ven. Menos son capaces de definir lo que quieren decir con datos de
alta calidad. Alternativamente, lo definen en un término muy general: “Los datos tienen que ser correctos”. “Necesitamos datos precisos”.
Los datos de alta calidad son aptos para los fines de los consumidores de datos. Antes de lanzar un programa de calidad de datos, es
beneficioso comprender las necesidades comerciales, definir los términos, identificar los puntos débiles de la organización y comenzar a
generar consenso sobre los impulsores y las prioridades para mejorar la calidad de los datos. Haga un conjunto de preguntas para
comprender el estado actual y evaluar la preparación de la organización para mejorar la calidad de los datos:
• ¿Qué quieren decir las partes interesadas con 'datos de alta
calidad'? • ¿Cuál es el impacto de los datos de baja calidad en las operaciones y estrategias
comerciales? • ¿De qué manera los datos de mayor calidad permitirán la estrategia comercial? •
¿Qué prioridades impulsan la necesidad de mejorar la calidad de los datos? • ¿Cuál es la
tolerancia para datos de baja calidad? • ¿Qué gobernanza existe para respaldar la mejora de la
calidad de los datos? • ¿Qué estructuras de gobierno adicionales se necesitarán?
Obtener una imagen completa del estado actual de la calidad de los datos en una organización requiere abordar la cuestión desde
diferentes perspectivas:
• Una comprensión de la estrategia y los objetivos comerciales •
Entrevistas con las partes interesadas para identificar los puntos débiles, los riesgos y los impulsores
comerciales • Evaluación directa de los datos, a través de perfiles y otras formas de análisis •
Documentación de las dependencias de datos en los procesos comerciales • Documentación de la
arquitectura y los sistemas técnicos apoyo a los procesos de negocio
474 • DMBOK2
Este tipo de evaluación puede revelar un número significativo de oportunidades. Estos deben priorizarse en función del beneficio potencial
para la organización. Utilizando los aportes de las partes interesadas, incluidos los administradores de datos y las pymes comerciales y
técnicas, el equipo de calidad de datos debe definir el significado de la calidad de los datos y proponer las prioridades del programa.
2.2 Definir una estrategia de calidad de datos
Mejorar la calidad de los datos requiere una estrategia que tenga en cuenta el trabajo que debe realizarse y la forma en que las personas lo
ejecutarán. Las prioridades de calidad de datos deben alinearse con la estrategia comercial. La adopción o el desarrollo de un marco y una
metodología ayudará a guiar tanto la estrategia como las tácticas, al mismo tiempo que proporciona un medio para medir el progreso y los
impactos. Un marco debe incluir métodos para:
• Comprender y priorizar las necesidades comerciales •
Identificar los datos críticos para satisfacer las necesidades
comerciales • Definir las reglas comerciales y los estándares de calidad de los datos en función de los
requisitos comerciales • Evaluar los datos frente a las expectativas • Compartir hallazgos y obtener
comentarios de las partes interesadas • Priorizar y gestionar problemas • Identificar y priorizar
oportunidades para mejorar • Medir, monitorear e informar sobre la calidad de los datos • Administrar los
metadatos producidos a través de los procesos de calidad de los datos • Integrar los controles de calidad
de los datos en los procesos comerciales y técnicos
Un marco también debe tener en cuenta cómo organizar la calidad de los datos y cómo aprovechar las herramientas de calidad de los datos.
Como se señaló en la introducción del capítulo, mejorar la calidad de los datos requiere que un equipo del programa de calidad de datos
involucre al personal comercial y técnico y defina un programa de trabajo que aborde los problemas críticos, defina las mejores prácticas y
establezca procesos operativos que respalden la gestión continua de la calidad de los datos. . A menudo, dicho equipo formará parte de la
Organización de gestión de datos. Los analistas de DQ deberán trabajar en estrecha colaboración con los administradores de datos en todos
los niveles. También deben influir en la política, incluida la política sobre procesos comerciales y desarrollo de sistemas. Sin embargo, dicho
equipo no podrá resolver todos los desafíos de calidad de datos de una organización.
El trabajo de DQ y el compromiso con los datos de alta calidad deben integrarse en las prácticas organizacionales. La estrategia DQ debe
dar cuenta de cómo extender las mejores prácticas. (Consulte el Capítulo 17.)
2.3 Identificar datos críticos y reglas comerciales
No todos los datos tienen la misma importancia. Los esfuerzos de Data Quality Management deben centrarse primero en los datos más
importantes de la organización: datos que, si fueran de mayor calidad, proporcionarían mayor valor a la organización y sus clientes. Los
datos se pueden priorizar en función de factores como los requisitos reglamentarios, el valor financiero y el impacto directo en los clientes. A
menudo, los esfuerzos de mejora de la calidad de los datos comienzan con Master Data, que es, por definición, uno de los datos más
importantes de cualquier organización. El resultado del análisis de importancia es una lista clasificada de datos, que el equipo de calidad de
datos puede utilizar para centrar sus esfuerzos de trabajo.
Habiendo identificado los datos críticos, los analistas de calidad de datos deben identificar las reglas comerciales que describen o implican
expectativas sobre las características de calidad de los datos. A menudo, las reglas en sí mismas no están explícitamente documentadas.
Es posible que deban someterse a ingeniería inversa a través del análisis de los procesos comerciales existentes, los flujos de trabajo, las
reglamentaciones, las políticas, los estándares, las ediciones del sistema, el código de software, los activadores y los procedimientos, la
asignación y el uso del código de estado y el simple sentido común. Por ejemplo, si una empresa de marketing quiere dirigir los esfuerzos a las
personas de un grupo demográfico específico, los posibles índices de calidad de los datos podrían ser el nivel y la razonabilidad de la población
en campos demográficos como la fecha de nacimiento, la edad, el sexo y los ingresos familiares.
La mayoría de las reglas comerciales están asociadas con la forma en que se recopilan o crean los datos, pero la medición de la calidad de los
datos se centra en si los datos son aptos para su uso. Los dos (creación de datos y uso de datos) están relacionados. La gente quiere usar los
datos por lo que representan y por qué se crearon. Por ejemplo, comprender el rendimiento de ventas de una organización durante un trimestre
específico o a lo largo del tiempo depende de tener datos confiables sobre el proceso de ventas (número y tipo de unidades vendidas, volumen
vendido a clientes existentes frente a nuevos clientes, etc.).
No es posible conocer todas las formas en que se pueden usar los datos, pero es posible comprender el proceso y las reglas mediante las cuales
se crearon o recopilaron los datos. Las mediciones que describen si los datos son aptos para su uso deben desarrollarse en relación con usos
conocidos y reglas medibles basadas en dimensiones de la calidad de los datos: integridad, conformidad, validez, integridad, etc. que proporcionan
la base para métricas significativas. Las dimensiones de calidad permiten a los analistas caracterizar tanto las reglas (el campo X es obligatorio y
debe completarse) como los hallazgos (p. ej., el campo no se completa en el 3 % de los registros; los datos solo están completos en un 97 %).
A nivel de campo o columna, las reglas pueden ser sencillas. Las reglas de completitud son un reflejo de si un campo es obligatorio u opcional y,
si es opcional, las condiciones bajo las cuales se debe completar. Las reglas de validez dependen de estipular el dominio de valores válidos y, en
algunos casos, la relación entre campos. Por ejemplo, un código postal de EE. UU. debe ser válido por sí mismo y estar correctamente asociado
con un código de estado de EE. UU. Las reglas también deben definirse en el nivel del conjunto de datos. Por ejemplo, cada cliente debe tener
una dirección postal válida.
Definir reglas de calidad de datos es un desafío porque la mayoría de las personas no están acostumbradas a pensar en los datos en términos
de reglas. Puede ser necesario llegar a las reglas indirectamente, preguntando a las partes interesadas sobre los requisitos de entrada y salida
de un proceso comercial. También ayuda preguntar sobre los puntos débiles, qué sucede cuando faltan datos o son incorrectos, cómo identifican
los problemas, cómo reconocen los datos incorrectos, etc. Tenga en cuenta que no es necesario conocer todas las reglas para evaluar los datos.
El descubrimiento y el perfeccionamiento de las reglas es un proceso continuo. Una de las mejores formas de llegar a las reglas es compartir los
resultados de las evaluaciones. Estos resultados a menudo brindan a las partes interesadas una nueva perspectiva sobre los datos a partir de la
cual pueden articular reglas que les dicen lo que necesitan saber sobre el
datos.
2.4 Realice una evaluación inicial de la calidad de los datos
Una vez que se han identificado las necesidades comerciales más críticas y los datos que las respaldan, la parte más importante de la evaluación
de la calidad de los datos consiste en analizar esos datos, consultarlos para comprender el contenido y las relaciones de los datos, y comparar
los datos reales con las reglas y las expectativas. La primera vez que se hace esto, los analistas descubrirán muchas cosas: relaciones y
dependencias no documentadas dentro de los datos, reglas implícitas, redundancia
476 • DMBOK2
datos, datos contradictorios, etc., así como datos que realmente se ajustan a las reglas. Con la ayuda de administradores de datos, otras pymes y
consumidores de datos, los analistas de DQ deberán clasificar y priorizar los hallazgos.
El objetivo de una evaluación inicial de la calidad de los datos es aprender sobre los datos para definir un plan de acción para la mejora. Por lo
general, es mejor comenzar con un esfuerzo pequeño y enfocado, una prueba de concepto básica, para demostrar cómo funciona el proceso de
mejora. Los pasos incluyen:
• Definir los objetivos de la evaluación; estos impulsarán el trabajo • Identificar los
datos que se evaluarán; el enfoque debe estar en un pequeño conjunto de datos, incluso en un solo elemento de datos, o en un problema
específico de calidad de datos
• Identificar los usos de los datos y los consumidores de los datos • Identificar
los riesgos conocidos con los datos que se van a evaluar, incluido el impacto potencial de los problemas de datos en
procesos organizativos •
Inspeccionar los datos en función de las reglas conocidas y propuestas •
Documentar los niveles de incumplimiento y los tipos de problemas • Realizar
análisis adicionales en profundidad en función de los hallazgos iniciales para o Cuantificar los hallazgos
o Priorizar los problemas en función del impacto en el negocio o Desarrollar hipótesis
sobre las causas fundamentales de los problemas de datos • Reúnase con los
administradores de datos, las PYMES y los consumidores de datos para confirmar los
problemas y las prioridades • Utilice los hallazgos como base para la planificación o Remediación de problemas,
idealmente en sus causas fundamentales o Controles y mejoras de procesos para evitar que los problemas recurrentes
o Controles y reportes continuos
2.5 Identificar y priorizar posibles mejoras
Habiendo demostrado que el proceso de mejora puede funcionar, el próximo objetivo es aplicarlo estratégicamente. Hacerlo requiere identificar y
priorizar posibles mejoras. La identificación se puede lograr mediante la creación de perfiles de datos a gran escala de conjuntos de datos más
grandes para comprender la amplitud de los problemas existentes. También se puede lograr por otros medios, como entrevistar a las partes
interesadas sobre los problemas de datos que los afectan y hacer un seguimiento con un análisis del impacto comercial de esos problemas. En última
instancia, la priorización requiere una combinación de análisis de datos
y debate con las partes interesadas.
Los pasos para realizar un perfilado y análisis de datos completos son esencialmente los mismos que para realizar una evaluación a pequeña escala:
definir objetivos, comprender los usos y riesgos de los datos, compararlos con las reglas, documentar y confirmar los hallazgos con las pymes, utilizar
esta información para priorizar la remediación y esfuerzos de mejora. Sin embargo, a veces existen obstáculos técnicos para la creación de perfiles a
gran escala. Y el esfuerzo deberá coordinarse a través de un equipo de analistas y los resultados generales deberán resumirse y comprenderse si se
va a implementar un plan de acción efectivo. Los esfuerzos de creación de perfiles a gran escala, como los de menor escala, aún deben centrarse en
los datos más críticos.
La elaboración de perfiles de datos es solo el primer paso en el análisis de los problemas de calidad de los datos. Ayuda a identificar problemas, pero
no identifica las causas principales ni determina el impacto de los problemas en los procesos comerciales. Determinar el impacto requiere información
de las partes interesadas a lo largo de la cadena de datos. Al planificar la creación de perfiles a gran escala, asegúrese de asignar tiempo
para compartir resultados, priorizar problemas y determinar qué problemas requieren un análisis en profundidad.
2.6 Definir objetivos para la mejora de la calidad de los datos
El conocimiento obtenido a través de las evaluaciones preliminares constituye la base de los objetivos específicos del programa de calidad de
datos. La mejora puede tomar diferentes formas, desde una simple remediación (p. ej., corrección de errores en los registros) hasta la
remediación de las causas fundamentales. Los planes de remediación y mejora deben tener en cuenta los impactos rápidos (problemas que
se pueden abordar de inmediato a bajo costo) y los cambios estratégicos a largo plazo. El enfoque estratégico de dichos planes debe ser
abordar las causas fundamentales de los problemas y establecer mecanismos para prevenir problemas en primer lugar.
Tenga en cuenta que muchas cosas pueden obstaculizar los esfuerzos de mejora: restricciones del sistema, antigüedad de los datos, trabajo
de proyecto en curso que utiliza datos cuestionables, complejidad general del panorama de datos, resistencia cultural al cambio. Para evitar
que estas restricciones detengan el programa, establezca metas específicas y alcanzables basadas en una cuantificación consistente del valor
comercial de las mejoras en la calidad de los datos.
Por ejemplo, un objetivo puede ser mejorar la integridad de los datos del cliente del 90 % al 95 % en función de las mejoras del proceso y las
ediciones del sistema. Obviamente, mostrar una mejora implicará comparar las mediciones iniciales y los resultados mejorados. Pero el valor
viene con los beneficios de la mejora: menos quejas de los clientes, menos tiempo dedicado a corregir errores, etc. Mida estas cosas para
explicar el valor del trabajo de mejora. A nadie le importan los niveles de integridad del campo a menos que haya un impacto en el negocio.
Debe haber un retorno de la inversión positivo para las mejoras en los datos. Cuando se encuentren problemas, determine el ROI de las
correcciones en función de:
• La criticidad (clasificación de importancia) de los datos afectados
• Cantidad de datos afectados
• La antigüedad de los datos
• Número y tipo de procesos comerciales afectados por el problema • Número de
clientes, clientes, proveedores o empleados afectados por el problema
• Riesgos asociados con el problema
• Costos de remediar las causas raíz • Costos
de posibles soluciones temporales
Al evaluar los problemas, especialmente aquellos en los que se identifican las causas fundamentales y se requieren cambios técnicos, siempre
busque oportunidades para evitar que los problemas vuelvan a ocurrir. Prevenir problemas generalmente cuesta menos que corregirlos, a
veces mucho menos. (Consulte el Capítulo 11.)
2.7 Desarrollar e implementar operaciones de calidad de datos
Muchos programas de calidad de datos comienzan a través de un conjunto de proyectos de mejora identificados a través de los resultados de
la evaluación de calidad de datos. Para mantener la calidad de los datos, un programa DQ debe implementar un plan que permita al equipo
administrar las reglas y los estándares de calidad de los datos, monitorear la conformidad continua de los datos con las reglas, identificar y
administrar los problemas de calidad de los datos e informar sobre los niveles de calidad. En apoyo de estas actividades, los analistas de DQ y Data
478 • DMBOK2
Los administradores también participarán en actividades como la documentación de estándares de datos y reglas comerciales y el establecimiento de
requisitos de calidad de datos para los proveedores.
2.7.1 Administrar reglas de calidad de datos
El proceso de creación de perfiles y análisis de datos ayudará a una organización a descubrir (o realizar ingeniería inversa) reglas de calidad de datos y
negocios. A medida que madura la práctica de la calidad de los datos, la captura de tales reglas debe integrarse en el proceso de desarrollo y mejora del
sistema. Definir reglas por adelantado:
• Establecer expectativas claras para las características de calidad de los datos
• Proporcionar requisitos para ediciones y controles del sistema que eviten que se introduzcan problemas de datos
• Proporcionar requisitos de calidad de datos a proveedores y otras partes externas
• Crear la base para la medición y generación de informes continuos sobre la calidad de los datos
En resumen, las reglas y estándares de calidad de datos son una forma crítica de metadatos. Para que sean efectivos, deben administrarse como metadatos.
Las reglas deben ser:
• Documentado consistentemente: Establezca estándares y plantillas para documentar reglas para que tengan
un formato y un significado consistentes.
• Definido en términos de dimensiones de calidad de datos: las dimensiones de calidad ayudan a las personas a comprender qué es
siendo medido. La aplicación consistente de dimensiones ayudará con la medición y el problema.
procesos de gestión.
• Vinculado al impacto en el negocio: si bien las dimensiones de la calidad de los datos permiten la comprensión de problemas comunes, no son
un objetivo en sí mismos. Los estándares y las reglas deben estar conectados directamente con su impacto en el éxito de la organización.
Las mediciones que no están vinculadas a los procesos de negocio no deben ser
tomado.
• Respaldado por el análisis de datos: los analistas de calidad de datos no deben adivinar las reglas. Las reglas deben ser probadas
contra datos reales. En muchos casos, las reglas mostrarán que hay problemas con los datos. Pero el análisis también puede mostrar que
las reglas mismas no están completas.
• Confirmado por las PYMES: El objetivo de las reglas es describir cómo deben verse los datos. A menudo, se necesita
conocimiento de los procesos organizacionales para confirmar que las reglas describen correctamente los datos. Este
conocimiento surge cuando los expertos en la materia confirman o explican los resultados del análisis de datos.
• Accesible para todos los consumidores de datos: Todos los consumidores de datos deben tener acceso a reglas documentadas. Semejante
el acceso les permite comprender mejor los datos. También ayuda a garantizar que las reglas sean correctas y completas. Asegúrese de
que los consumidores tengan un medio para hacer preguntas y proporcionar comentarios sobre las reglas.
2.7.2 Medir y monitorear la calidad de los datos
Los procedimientos operativos de gestión de la calidad de los datos dependen de la capacidad de medir y controlar la calidad de
los datos. Hay dos razones igualmente importantes para implementar mediciones de calidad de datos operativos:
• Informar a los consumidores de datos sobre los niveles de
calidad. • Gestionar el riesgo de que se introduzcan cambios a través de cambios en los procesos comerciales o técnicos.
Algunas medidas sirven para ambos propósitos. Las mediciones deben desarrollarse en base a los hallazgos de la evaluación de
datos y el análisis de la causa raíz. Las mediciones destinadas a informar a los consumidores de datos se centrarán en elementos
y relaciones de datos críticos que, si no son sólidos, tendrán un impacto directo en los procesos comerciales. Las mediciones
relacionadas con la gestión del riesgo deben centrarse en las relaciones que han ido mal en el pasado y pueden salir mal en el
futuro. Por ejemplo, si los datos se derivan en función de un conjunto de reglas ETL y esas reglas pueden verse afectadas por
cambios en los procesos comerciales, se deben implementar mediciones para detectar cambios en los datos.
El conocimiento de problemas pasados debe aplicarse para gestionar el riesgo. Por ejemplo, si numerosos problemas de datos
están asociados con derivaciones complejas, todas las derivaciones deben evaluarse, incluso aquellas que no se han asociado
con problemas de datos. En la mayoría de los casos, vale la pena implementar medidas que controlen funciones similares a las
que han tenido problemas.
Los resultados de la medición se pueden describir en dos niveles: el detalle relacionado con la ejecución de reglas individuales y
resultados generales agregados de las reglas. Cada regla debe tener un índice estándar, de destino o de umbral para la
comparación. Esta función suele reflejar el porcentaje de datos correctos o el porcentaje de excepciones según la fórmula utilizada.
Por ejemplo:
( ) ( )
( ) =
( )
( )
( ) =
( )
R representa la regla que se está probando. Por ejemplo, 10.000 pruebas de una regla de negocio (r) encontraron 560 excepciones.
En este ejemplo, el resultado de ValidDQ sería 9440/10 000 = 94,4 % y el resultado de Invalid DQ sería 560/10 000 =
5,6%.
Organizar las métricas y los resultados como se muestra en la Tabla 30 puede ayudar a estructurar medidas, métricas e indicadores
en todo el informe, revelar posibles resúmenes y mejorar las comunicaciones. El informe puede ser más formalizado y vinculado a
proyectos que solucionarán los problemas. Los informes filtrados son útiles para los administradores de datos que buscan
tendencias y contribuciones. La Tabla 30 proporciona ejemplos de reglas construidas de esta manera. Cuando corresponda, los
resultados de las reglas se expresan tanto en porcentajes positivos (la parte de los datos que se ajusta a las reglas y expectativas)
como en porcentajes negativos (la parte de los datos que no se ajusta a la regla).
Las reglas de calidad de los datos proporcionan la base para la gestión operativa de la calidad de los datos. Las reglas se pueden integrar en
servicios de aplicaciones o servicios de datos que complementan el ciclo de vida de los datos, ya sea a través de herramientas de calidad de
datos comerciales estándar (COTS), motores de reglas y herramientas de generación de informes para monitorear y generar informes, o
aplicaciones desarrolladas a medida.
480 • DMBOK2
Tabla 30 Ejemplos de métricas DQ
Dimensión y Medida Métrica Estado
De reglas de negocio Indicador
Lo completo Cuente el número de Divida el número obtenido de registros donde Inaceptable:
Regla de negocio 1: registros donde se se completan los datos por el número total de Por debajo del
La población del campo completan los datos, registros en la tabla o base de datos y multiplíquelo 80% de población

es obligatoria compárelo con el número por 100 para obtener el porcentaje completo Por encima
total de registros del 20% no poblado
Ejemplo 1: Recuento poblado: Medida positiva: Resultado
El código postal debe 700.000 700.000/1.000.000*100 = 70% poblado de ejemplo:
completarse en la tabla Recuento no poblado: Medida negativa: Inaceptable

de direcciones 300.000 300.000/1.000.000 *100 = 30% no poblado
Conteo total: 1,000,000
Unicidad Contar el número de Divida el número de registros duplicados por el Inaceptable:
Regla de negocio 2: registros duplicados número total de registros en la tabla o base de datos Por encima del 0%
Debe haber solo un identificados; informar sobre y multiplíquelo por 100

registro por instancia de el porcentaje de registros que
entidad en una tabla representan duplicados
Ejemplo 2: Recuento de duplicados: 10,000/1,000,000*100 = 1.0% de los códigos Resultado

Debe haber una y 1.000 postales están presentes en más de una corriente de ejemplo:
sólo una fila actual Conteo total: 1,000,000 fila Inaceptable

por código postal en
el
Lista maestra de
códigos postales
Oportunidad Cuente la cantidad de Dividir el número de transacciones Inaceptable:
Regla de negocio 3: registros que no llegan a incompletas por el número total de intentos Por debajo del
Los registros tiempo desde un servicio de de transacciones en un período de tiempo y multiplicar 99% completado
deben llegar datos para que se completen por 100 a tiempo
dentro de un plazo las transacciones comerciales Más del 1% no
programado completado a
tiempo
Ejemplo 3: Recuento de transacciones Positivo: Ejemplo
El registro del incompletas: 2000 (1 000 000 – 2000) / 1 000 000*100 = 99,8 % Resultado:
mercado de acciones Conteo de intentos de de los registros de transacciones llegaron Aceptable
debe llegar dentro transacciones: 1,000,000 dentro del plazo definido Negativo: 2000/1 000
de los 5 minutos 000*100 = 0,20 % de las transacciones no
posteriores a la transacción llegaron dentro del plazo definido Divida el
número de registros que cumplen la condición por
el número total de registros
Validez Cuente el número de Inaceptable:
Regla comercial 4: si el registros donde está la regla Por debajo del
campo X = valor 1, reunió 100% de
entonces el campo Y adherencia a la regla
debe = valor 1primo
Ejemplo 4: Recuento de registros donde Positivo: Ejemplo
Solo se deben el estado de envío = 999.000/1.000.000*100 = 99,9% de los Resultado:
facturar los pedidos Enviado y estado de registros cumplen la regla Negativo: Inaceptable
enviados facturación = Facturado: 999 000 (1.000.000999.000) / 1.000.000 *100 =
Conteo de registros totales: 0,10% no cumplen la regla
1,000,000
Proporcionar un seguimiento continuo incorporando procesos de control y medición al flujo de procesamiento de la información. El monitoreo automatizado de
la conformidad con las reglas de calidad de los datos se puede realizar en la corriente o a través de un proceso por lotes. Las mediciones se pueden tomar en
tres niveles de granularidad: el valor del elemento de datos, la instancia o registro de datos, o el conjunto de datos. La Tabla 31 describe técnicas para recolectar
mediciones de calidad de datos. Las mediciones en el flujo se pueden tomar mientras se crean datos o se transfieren datos entre etapas de procesamiento. Las
consultas por lotes se pueden realizar en colecciones de instancias de datos ensambladas en un conjunto de datos, generalmente en almacenamiento
persistente. Por lo general, las mediciones del conjunto de datos no se pueden tomar en el flujo, ya que la medición puede necesitar el conjunto completo.
La incorporación de los resultados de los procesos de control y medición tanto en los procedimientos operativos como en los marcos de informes permite el
monitoreo continuo de los niveles de calidad de los datos para retroalimentar y mejorar las actividades de generación/recopilación de datos.
Tabla 31 Técnicas de monitoreo de la calidad de los datos
granularidad Tratamiento en corriente (Flujo en proceso) Tratamiento por lotes

Elemento de datos Editar cheques en la aplicación Consultas directas
Servicios de validación de elementos de datos Herramienta de perfilado o analizador de datos
Aplicaciones especialmente programadas
Registro de datos Editar cheques en la aplicación Consultas directas
Servicios de validación de registros de datos Herramienta de perfilado o analizador de datos
Aplicaciones especialmente programadas
Conjunto de datos Inspección insertada entre etapas de procesamiento Consultas directas
Herramienta de perfilado o analizador de datos
2.7.3 Desarrollar procedimientos operativos para gestionar problemas de datos
Independientemente de las herramientas que se utilicen para monitorear la calidad de los datos, cuando los miembros del equipo de calidad de datos evalúan
los resultados, deben responder a los hallazgos de manera oportuna y efectiva. El equipo debe diseñar e implementar procedimientos operativos detallados
para:
• Diagnóstico de problemas: El objetivo es revisar los síntomas del incidente de calidad de datos, rastrear
linaje de los datos en cuestión, identificar el problema y dónde se originó, e identificar las posibles causas raíz del problema. El procedimiento debe
describir cómo el equipo de operaciones de calidad de datos:
o Revisar los problemas de datos en el contexto de los flujos de procesamiento de información apropiados y
aislar la ubicación en el proceso donde se introduce la falla
o Evaluar si ha habido algún cambio ambiental que pudiera causar errores al ingresar
en el sistema
o Evaluar si hay o no otros problemas de proceso que contribuyeron a la calidad de los datos
incidente
o Determinar si hay problemas con datos externos que hayan afectado la calidad de los datos
NOTA: El trabajo de análisis de causa raíz requiere el aporte de las PYMES técnicas y comerciales. Si bien el equipo de DQ puede liderar y
facilitar este tipo de esfuerzo de trabajo, el éxito requiere
colaboración
482 • DMBOK2
• Formular opciones de remediación: Con base en el diagnóstico, evaluar alternativas para abordar el problema. Estos pueden incluir:
o Abordar las causas fundamentales no técnicas, como la falta de capacitación, la falta de apoyo de liderazgo,
responsabilidad y propiedad poco claras, etc.
o Modificación de los sistemas para eliminar las causas técnicas raíz o Desarrollo de
controles para prevenir el problema o Introducción de inspección y monitoreo adicionales
o Corrección directa de datos defectuosos o No tomar ninguna acción basada en el
costo y el impacto de la corrección versus el valor de los datos
corrección
• Resolución de problemas: una vez identificadas las opciones para resolver el problema, el equipo de calidad de datos debe consultar con
los propietarios de los datos comerciales para determinar la mejor manera de resolver el problema. Estos procedimientos deben detallar
cómo los analistas:
o Evaluar los costos relativos y los méritos de las alternativas
o Recomendar una de las alternativas planificadas o Proporcionar
un plan para desarrollar e implementar la resolución o Implementar la resolución
Las decisiones tomadas durante el proceso de gestión de problemas deben rastrearse en un sistema de seguimiento de incidentes. Cuando los datos
en un sistema de este tipo se administran bien, pueden proporcionar información valiosa sobre las causas y los costos de los problemas de datos.
Incluya una descripción del problema y las causas fundamentales, las opciones de remediación y la decisión sobre cómo
para resolver el problema.
El sistema de seguimiento de incidentes recopilará datos de rendimiento relacionados con la resolución de problemas, asignaciones de trabajo,
volumen de problemas, frecuencia de ocurrencia, así como el tiempo para responder, diagnosticar, planificar una solución y resolver problemas.
Estas métricas pueden proporcionar información valiosa sobre la eficacia del flujo de trabajo actual, así como sobre la utilización de los sistemas y
los recursos, y son puntos de datos de gestión importantes que pueden impulsar la mejora operativa continua para el control de calidad de los datos.
Los datos de seguimiento de incidentes también ayudan a los consumidores de datos. Las decisiones basadas en datos remediados deben tomarse
sabiendo que se han cambiado, por qué se han cambiado y cómo se han cambiado. Esa es una de las razones por las que es importante registrar
los métodos de modificación y la justificación de los mismos. Ponga esta documentación a disposición de los consumidores de datos y los
desarrolladores que investigan cambios en el código. Si bien los cambios pueden ser obvios para las personas que los implementan, el historial de
cambios se perderá para los futuros consumidores de datos a menos que esté documentado. El seguimiento de incidentes de calidad de datos
requiere que el personal esté capacitado sobre cómo se deben clasificar, registrar y rastrear los problemas. Para respaldar un seguimiento efectivo:
• Estandarice las actividades y los problemas de calidad de los datos: Dado que los términos utilizados para describir los problemas de datos
pueden variar según las líneas de negocio, es valioso definir un vocabulario estándar para los conceptos utilizados. Si lo hace,
simplificará la clasificación y la presentación de informes. La estandarización también facilita medir el volumen de problemas y
actividades, identificar patrones e interdependencias entre sistemas y participantes, y
informar sobre el impacto general de las actividades de calidad de datos. La clasificación de un problema puede cambiar a medida que se
profundiza la investigación y se exponen las causas fundamentales.
• Proporcionar un proceso de asignación de problemas de datos: Los procedimientos operativos dirigen a los analistas a asignar incidentes
de calidad de datos a las personas para el diagnóstico y para proporcionar alternativas de resolución.
Impulse el proceso de asignación dentro del sistema de seguimiento de incidentes sugiriendo a aquellas personas con áreas específicas
de experiencia.
• Gestionar los procedimientos de escalamiento de problemas: el manejo de problemas de calidad de datos requiere un sistema bien definido
de escalamiento basado en el impacto, la duración o la urgencia de un problema. Especifique la secuencia de escalamiento dentro del
Acuerdo de nivel de servicio de calidad de datos. El sistema de seguimiento de incidentes implementará los procedimientos de
escalamiento, lo que ayuda a acelerar el manejo y la resolución eficientes de los problemas de datos.
• Administrar el flujo de trabajo de resolución de calidad de datos: el SLA de calidad de datos especifica objetivos para el monitoreo, control y
resolución, los cuales definen una colección de flujos de trabajo operativos. El sistema de seguimiento de incidentes puede admitir la gestión
del flujo de trabajo para realizar un seguimiento del progreso con el diagnóstico y la resolución de problemas.
2.7.4 Establecer acuerdos de nivel de servicio de calidad de datos
Un acuerdo de nivel de servicio (SLA) de calidad de datos especifica las expectativas de una organización para la respuesta y la corrección de problemas
de calidad de datos en cada sistema. Las inspecciones de calidad de datos programadas en el SLA ayudan a identificar los problemas que se deben
solucionar y, con el tiempo, reducen la cantidad de problemas. Si bien permite el aislamiento y el análisis de la causa principal de las fallas de datos,
existe la expectativa de que los procedimientos operativos proporcionen un esquema para remediar las causas principales dentro de un plazo acordado.
Tener la inspección y el monitoreo de la calidad de los datos aumenta la probabilidad de detección y corrección de un problema de calidad de los datos
antes de que ocurra un impacto comercial significativo. El control de calidad de datos operativos definido en un SLA de calidad de datos incluye:
• Elementos de datos cubiertos por el acuerdo • Impactos
comerciales asociados con fallas de datos • Dimensiones de
calidad de datos asociadas con cada elemento de datos • Expectativas de calidad
para cada elemento de datos para cada una de las dimensiones identificadas en cada aplicación
o sistema en la cadena de valor de los datos
• Métodos para medir contra esas expectativas • Umbral de aceptabilidad
para cada medición • Administrador(es) a ser notificado(s) en caso de que
no se alcance el umbral de aceptabilidad • Plazos y plazos para la resolución esperada o remediación
del problema • Estrategia de escalada y posibles recompensas y sanciones
El SLA de calidad de datos también define las funciones y responsabilidades asociadas con el desempeño de los procedimientos de calidad de datos
operativos. Los procedimientos de calidad de datos operativos brindan informes de conformidad con las reglas comerciales definidas, así como también
monitorean el desempeño del personal al reaccionar ante incidentes de calidad de datos. Los administradores de datos y el personal de calidad de datos
operativos, al mismo tiempo que mantienen el nivel de servicio de calidad de datos, deben considerar sus limitaciones de SLA de calidad de datos y
conectar la calidad de datos con los planes de rendimiento individuales.
484 • DMBOK2
Cuando los problemas no se abordan dentro de los tiempos de resolución especificados, debe existir un proceso de escalamiento para comunicar el
incumplimiento del nivel de servicio en la cadena de gestión y gobierno. El SLA de calidad de datos establece los límites de tiempo para la generación de
notificaciones, los nombres de aquellos en esa cadena de gestión y cuándo debe ocurrir la escalada. Dado el conjunto de reglas de calidad de datos, los
métodos para medir la conformidad, los umbrales de aceptabilidad definidos por los clientes comerciales y los acuerdos de nivel de servicio, el equipo de
calidad de datos puede monitorear el cumplimiento de los datos con las expectativas comerciales, así como la calidad de los datos. El equipo de calidad
realiza los procedimientos asociados con los errores de datos.
Los informes de SLA pueden programarse según los requisitos comerciales y operativos. Se prestará especial atención al análisis de tendencias de
informes en casos centrados en recompensas y sanciones periódicas si tales conceptos están integrados en
el marco SLA.
2.7.5 Desarrollar informes de calidad de datos
El trabajo de evaluar la calidad de los datos y gestionar los problemas de datos no beneficiará a la organización a menos que la información se comparta
a través de informes para que los consumidores de datos comprendan la condición de los datos. Informes
debe centrarse en:
• Cuadro de mando de calidad de datos, que proporciona una vista de alto nivel de las puntuaciones asociadas con varias métricas, informadas a
diferentes niveles de la organización dentro de umbrales establecidos. • Tendencias de calidad de datos, que muestran cómo se mide la
calidad de los datos a lo largo del tiempo y si se observan es
arriba o abajo
• Métricas de SLA, como si el personal de calidad de datos operativos diagnostica y responde a los incidentes de calidad de datos de
manera oportuna
• Gestión de problemas de calidad de datos, que supervisa el estado de los problemas y las resoluciones • Conformidad
del equipo de calidad de datos con las políticas de gobierno • Conformidad de los equipos de TI y comerciales con las
políticas de calidad de datos • Efectos positivos de los proyectos de mejora
Los informes deben alinearse con las métricas en el SLA de calidad de datos tanto como sea posible, para que los objetivos del equipo estén alineados
con los de sus clientes. El programa de calidad de datos también debe informar sobre los efectos positivos de los proyectos de mejora. Es mejor hacer
esto en términos comerciales para recordar continuamente a la organización el impacto directo
efecto que los datos tienen sobre los clientes.
3. Herramientas
Las herramientas deben seleccionarse y las arquitecturas de herramientas deben establecerse en la fase de planificación del programa de calidad de datos
de la empresa. Las herramientas proporcionan un kit de inicio de conjunto de reglas parciales, pero las organizaciones deben crear e ingresar sus propias
reglas y acciones específicas del contexto en cualquier herramienta.
3.1 Herramientas de perfilado de datos
Las herramientas de creación de perfiles de datos producen estadísticas de alto nivel que permiten a los analistas identificar patrones en los datos y realizar una
evaluación inicial de las características de calidad. Algunas herramientas se pueden utilizar para realizar un seguimiento continuo de los datos.
Las herramientas de creación de perfiles son particularmente importantes para los esfuerzos de descubrimiento de datos porque permiten la evaluación de
grandes conjuntos de datos. Las herramientas de creación de perfiles aumentadas con capacidades de visualización de datos ayudarán en el proceso de
descubrimiento. (Consulte los Capítulos 5 y 8 y la Sección 1.3.9.)
3.2 Herramientas de consulta de datos
La creación de perfiles de datos es solo el primer paso en el análisis de datos. Ayuda a identificar problemas potenciales. Los miembros del equipo de calidad de
datos también necesitan consultar los datos con mayor profundidad para responder a las preguntas planteadas por los resultados de los perfiles y encontrar
patrones que brinden información sobre las causas fundamentales de los problemas de datos. Por ejemplo, realizar consultas para descubrir y cuantificar otros
aspectos de la calidad de los datos, como la singularidad y la integridad.
3.3 Herramientas de modelado y ETL
Las herramientas utilizadas para modelar datos y crear procesos ETL tienen un impacto directo en la calidad de los datos. Si se utilizan teniendo en cuenta los
datos, estas herramientas pueden permitir obtener datos de mayor calidad. Si se utilizan sin el conocimiento de los datos, pueden tener efectos perjudiciales. Los
miembros del equipo de DQ deben trabajar con los equipos de desarrollo para garantizar que se aborden los riesgos de calidad de los datos y que la organización
aproveche al máximo las formas en que el modelado y el procesamiento de datos efectivos pueden permitir datos de mayor calidad. (Consulte los capítulos 5, 8
y 11).
3.4 Plantillas de reglas de calidad de datos
Las plantillas de reglas permiten al analista capturar las expectativas de los datos. Las plantillas también ayudan a cerrar la brecha de comunicación entre los
equipos comerciales y técnicos. La formulación coherente de reglas facilita la traducción de las necesidades comerciales en código, ya sea que ese código esté
incrustado en un motor de reglas, el componente analizador de datos de una herramienta de creación de perfiles de datos o una herramienta de integración de
datos. Una plantilla puede tener varias secciones, una para cada tipo de regla de negocio a implementar.
3.5 Repositorios de metadatos
Como se señaló en la Sección 1.3.4, definir la calidad de los datos requiere Metadatos y las definiciones de datos de alta calidad son un tipo valioso de Metadatos.
Los equipos de DQ deben trabajar en estrecha colaboración con los equipos que administran los metadatos para garantizar que los requisitos de calidad de los
datos, las reglas, los resultados de las mediciones y la documentación de los problemas estén disponibles para los datos.
consumidores
486 • DMBOK2
4. Técnicas
4.1 Acciones Preventivas
La mejor manera de crear datos de alta calidad es evitar que los datos de baja calidad entren en una organización.
Las acciones preventivas evitan que se produzcan errores conocidos. Inspeccionar los datos después de que estén en producción no mejorará su
calidad. Los enfoques incluyen:
• Establezca controles de ingreso de datos: cree reglas de ingreso de datos que eviten que se ingresen datos inválidos o inexactos.
entrar en un sistema.
• Capacite a los productores de datos: Asegúrese de que el personal en los sistemas upstream comprenda el impacto de sus datos en
usuarios intermedios. Ofrezca incentivos o base las evaluaciones en la precisión e integridad de los datos, en lugar de solo en la
velocidad.
• Defina y aplique reglas: cree un 'cortafuegos de datos', que tiene una tabla con toda la calidad de los datos comerciales
reglas utilizadas para verificar si la calidad de los datos es buena, antes de ser utilizados en una aplicación como un almacén de
datos. Un firewall de datos puede inspeccionar el nivel de calidad de los datos procesados por una aplicación y, si el nivel de calidad
está por debajo de los niveles aceptables, se puede informar a los analistas sobre el problema.
• Exija datos de alta calidad de los proveedores de datos: Examine los procesos de un proveedor de datos externo para
verifique sus estructuras, definiciones y fuente(s) de datos y procedencia de los datos. Hacerlo permite evaluar qué tan bien
se integrarán sus datos y ayuda a prevenir el uso de datos no autorizados o datos adquiridos sin el permiso del propietario.
• Implementar el gobierno y la administración de datos: Garantizar que se definan roles y responsabilidades que
describir y hacer cumplir las reglas de compromiso, los derechos de decisión y las responsabilidades para la gestión eficaz
de los datos y los activos de información (McGilvray, 2008). Trabaje con los administradores de datos para revisar el proceso y los
mecanismos para generar, enviar y recibir datos.
• Instituya un control de cambios formal: asegúrese de que todos los cambios en los datos almacenados se definan y prueben antes de
implementarlos. Impedir cambios directamente en los datos fuera del procesamiento normal mediante el establecimiento de puertas
procesos.
4.2 Acciones Correctivas
Las acciones correctivas se implementan después de que se ha producido y detectado un problema. Los problemas de calidad de los datos deben
abordarse sistémicamente y en sus causas fundamentales para minimizar los costos y riesgos de las acciones correctivas. 'Resolver el problema
donde ocurre' es la mejor práctica en la gestión de calidad de datos. Esto generalmente significa que las acciones correctivas deben incluir la
prevención de la recurrencia de las causas de los problemas de calidad.
Realice la corrección de datos de tres maneras generales:
• Corrección automatizada: las técnicas de corrección automatizadas incluyen estandarización basada en reglas,
normalización y corrección. Los valores modificados se obtienen o generan y comprometen sin intervención manual. Un ejemplo
es la corrección de direcciones automatizada, que envía las direcciones de entrega a un estandarizador de direcciones que ajusta
y corrige las direcciones de entrega mediante reglas, análisis, estandarización y tablas de referencia. La corrección automatizada
requiere un entorno con estándares bien definidos, reglas comúnmente aceptadas y patrones de error conocidos. La cantidad de
corrección automatizada se puede reducir con el tiempo si este entorno está bien administrado y los datos corregidos se comparten
con
sistemas aguas arriba.
• Corrección dirigida manualmente: use herramientas automatizadas para remediar y corregir datos, pero requiera una revisión manual
antes de enviar las correcciones al almacenamiento persistente. Aplique corrección de nombre y dirección, resolución de identidad
y correcciones basadas en patrones automáticamente, y utilice algún mecanismo de puntuación para proponer un nivel de
confianza en la corrección. Las correcciones con puntajes por encima de un nivel particular de confianza se pueden realizar sin
revisión, pero las correcciones con puntajes por debajo del nivel de confianza se presentan al administrador de datos para su
revisión y aprobación. Confirme todas las correcciones aprobadas y revise las no aprobadas para comprender si se deben ajustar
las reglas subyacentes aplicadas. Los entornos en los que los conjuntos de datos confidenciales requieren supervisión humana
(p. ej., MDM) son buenos ejemplos de dónde puede ser adecuada la corrección manual.
• Corrección manual: A veces, la corrección manual es la única opción en ausencia de herramientas o
automatización o si se determina que el cambio se maneja mejor a través de la supervisión humana. Las correcciones
manuales se realizan mejor a través de una interfaz con controles y ediciones, que proporcionan una pista de auditoría para los
cambios. La alternativa de hacer correcciones y commitear los registros actualizados directamente en ambientes de producción
es extremadamente riesgosa. Evite usar este método.
4.3 Módulos de control de calidad y código de auditoría
Cree módulos de código compartibles, enlazables y reutilizables que ejecuten controles de calidad de datos repetidos y procesos de auditoría
que los desarrolladores pueden obtener de una biblioteca. Si es necesario cambiar el módulo, se actualizará todo el código vinculado a ese
módulo. Dichos módulos simplifican el proceso de mantenimiento. Los bloques de código bien diseñados pueden evitar muchos problemas de
calidad de datos. Y lo que es más importante, garantizan que los procesos se ejecuten de forma coherente. Cuando las leyes o las políticas
exigen la presentación de informes de resultados de calidad específicos, a menudo es necesario describir el linaje de los resultados.
Los módulos de control de calidad pueden proporcionar esto. Para los datos que tengan alguna dimensión de calidad cuestionable y que
tengan una calificación alta, califique la información en los entornos compartidos con notas de calidad y calificaciones de confianza.
4.4 Métricas efectivas de calidad de datos
Un componente fundamental de la gestión de la calidad de los datos es el desarrollo de métricas que informen a los consumidores de datos
sobre las características de calidad que son importantes para sus usos de los datos. Se pueden medir muchas cosas, pero no todas valen el
tiempo y el esfuerzo. Al desarrollar métricas, los analistas de DQ deben tener en cuenta estas características:
488 • DMBOK2
• Mensurabilidad: una métrica de calidad de datos debe ser medible; debe ser algo que se pueda medir.
contado Por ejemplo, la relevancia de los datos no se puede medir, a menos que se establezcan criterios claros sobre lo que
hace que los datos sean relevantes. Incluso la integridad de los datos debe definirse objetivamente para medirse.
Los resultados esperados deben ser cuantificables dentro de un rango discreto.
• Relevancia comercial: si bien muchas cosas se pueden medir, no todas se traducen en métricas útiles.
Las mediciones deben ser relevantes para los consumidores de datos. El valor de la métrica es limitado si no puede ser
relacionado con algún aspecto de las operaciones o el desempeño del negocio. Cada métrica de calidad de datos debe
correlacionarse con la influencia de los datos en las expectativas comerciales clave.
• Aceptabilidad: las dimensiones de la calidad de los datos enmarcan los requisitos comerciales para la calidad de los datos.
La cuantificación a lo largo de la dimensión identificada proporciona pruebas sólidas de los niveles de calidad de los datos.
Determinar si los datos cumplen con las expectativas comerciales en función de los umbrales de aceptabilidad especificados.
Si la puntuación es igual o supera el umbral, la calidad de los datos cumple con las expectativas comerciales. Si la puntuación
está por debajo del umbral, no lo hace.
• Responsabilidad / Administración: Las métricas deben ser entendidas y aprobadas por las partes interesadas clave (p. ej., propietarios
de negocios y administradores de datos). Se les notifica cuando la medición de la métrica muestra que la calidad no cumple con
las expectativas. El propietario de los datos comerciales es responsable, mientras que un administrador de datos toma las medidas
correctivas adecuadas.
• Controlabilidad: una métrica debe reflejar un aspecto controlable del negocio. En otras palabras, si el
la métrica está fuera de rango, debería desencadenar una acción para mejorar los datos. Si no hay forma de responder, es
probable que la métrica no sea útil.
• Tendencias: las métricas permiten a una organización medir la mejora de la calidad de los datos a lo largo del tiempo. El seguimiento
ayuda a los miembros del equipo de calidad de datos a monitorear las actividades dentro del alcance de un SLA de calidad de
datos y un acuerdo de intercambio de datos, y demostrar la efectividad de las actividades de mejora. Una vez que un proceso de
información es estable, se pueden aplicar técnicas de control de procesos estadísticos para detectar cambios en la previsibilidad
de los resultados de la medición y los procesos comerciales y técnicos sobre los que proporciona información.
4.5 Control Estadístico de Procesos
El control estadístico de procesos (SPC) es un método para administrar procesos mediante el análisis de mediciones de variación en las
entradas, salidas o pasos del proceso. La técnica se desarrolló en el sector manufacturero en la década de 1920 y se ha aplicado en otras
industrias, en metodologías de mejora como Six Sigma y en la gestión de calidad de datos.87 Definido de manera simple, un proceso es una
serie de pasos ejecutados para convertir entradas en salidas . SPC se basa en la suposición de que cuando un proceso con entradas
consistentes se ejecuta de manera consistente, producirá salidas consistentes. Utiliza medidas de tendencia central (cómo los valores se
agrupan alrededor de un valor central, como una media,
87 Véase Redman (1996 y 2001), Loshin (2000), SebastianColeman (2013), Jugulum (2014).
mediana o moda) y de la variabilidad en torno a un valor central (p. ej., rango, varianza, desviación estándar), para establecer tolerancias de
variación dentro de un proceso.
La herramienta principal utilizada para el SPC es el gráfico de control (Figura 95), que es un gráfico de serie temporal que incluye una línea central
para el promedio (la medida de tendencia central) y muestra los límites de control superior e inferior calculados (variabilidad en torno a un valor
central). ). En un proceso estable, los resultados de medición fuera de los límites de control indican una causa especial.
Ejemplo de datos de un proceso estable (en control)
0,21 UCL=0,21061
0,20
0,19 x=0.1885
incumplimientos
Porcentaje
carga
por
de
0,18
0,17
LCL=0,16639
0,16
TGT_TBL_ETL_DT
Figura 95 Gráfico de Control de un Proceso en Control Estadístico
SPC mide la previsibilidad de los resultados del proceso al identificar la variación dentro de un proceso. Los procesos tienen variaciones de dos
tipos: Causas Comunes que son inherentes al proceso y Causas Especiales que son impredecibles o intermitentes. Cuando las únicas fuentes de
variación son causas comunes, se dice que un sistema está bajo control (estadístico) y se puede establecer un rango de variación normal. Esta es
la línea de base contra la cual el cambio
puede ser detectado.
La aplicación de SPC a la medición de la calidad de los datos se basa en la suposición de trabajo de que, al igual que un producto fabricado, los
datos son el producto de un proceso. A veces, el proceso que crea los datos es muy simple (por ejemplo, una persona llena un formulario). Otras
veces, los procesos son bastante complejos: un conjunto de algoritmos agrega datos de reclamos médicos para seguir tendencias relacionadas con
la efectividad de protocolos clínicos particulares. Si dicho proceso tiene entradas consistentes y se ejecuta de manera consistente, producirá
resultados consistentes cada vez que se ejecute. Sin embargo, si las entradas o la ejecución cambian, también lo harán las salidas. Cada uno de
estos componentes se puede medir. Las mediciones se pueden utilizar para detectar causas especiales. El conocimiento de las causas especiales
se puede utilizar para mitigar los riesgos asociados con la recopilación o el procesamiento de datos.
SPC se utiliza para control, detección y mejora. El primer paso es medir el proceso para identificar y eliminar las causas especiales. Esta actividad
establece el estado de control del proceso. Lo siguiente es poner en su lugar
490 • DMBOK2
mediciones para detectar variaciones inesperadas tan pronto como sea detectable. La detección temprana de problemas simplifica la investigación
de sus causas fundamentales. Las mediciones del proceso también se pueden usar para reducir los efectos no deseados de las causas comunes
de variación, lo que permite una mayor eficiencia.
4.6 Análisis de causa raíz
Una causa raíz de un problema es un factor que, si se elimina, eliminaría el problema mismo. El análisis de causa raíz es un proceso de comprensión
de los factores que contribuyen a los problemas y las formas en que contribuyen. Su propósito es identificar las condiciones subyacentes que, si se
eliminan, significarían que los problemas desaparecerían.
Un ejemplo de gestión de datos puede aclarar la definición. Digamos que un proceso de datos que se ejecuta cada mes requiere como entrada un
archivo de información del cliente. La medición de los datos muestra que en abril, julio, octubre y enero, la calidad de los datos baja. La inspección
de la fecha de entrega muestra que en marzo, junio, septiembre y diciembre, el expediente se entrega el día 30 del mes, mientras que el resto de
los días se entrega el día 25. Un análisis más detallado muestra que el equipo responsable de entregar el archivo también es responsable de cerrar
los procesos financieros trimestrales. Estos procesos tienen prioridad sobre otros trabajos y los archivos se entregan tarde durante esos meses, lo
que afecta la calidad. La causa raíz del problema de la calidad de los datos resulta ser un retraso en el proceso causado por una prioridad en
competencia. Se puede abordar programando la entrega de archivos y asegurándose de que
los recursos pueden entregar dentro del cronograma.
Las técnicas comunes para el análisis de la causa raíz incluyen el análisis de Pareto (la regla 80/20), el análisis del diagrama de espina de pescado,
el seguimiento y la localización, el análisis de procesos y los cinco porqués (McGilvray, 2008).
Mejorar la calidad de los datos dentro de una organización no es una tarea fácil, incluso cuando los esfuerzos de mejora de la calidad de los datos
se lanzan desde dentro de un programa de gobierno de datos y con el apoyo de la alta dirección. Una discusión académica clásica es si es mejor
implementar un programa de calidad de datos de arriba hacia abajo o de abajo hacia arriba.
Por lo general, un enfoque híbrido funciona mejor: de arriba hacia abajo para el patrocinio, la consistencia y los recursos, pero de abajo hacia arriba
para descubrir qué es lo que realmente no funciona y lograr éxitos incrementales.
Mejorar la calidad de los datos requiere cambios en la forma en que las personas piensan y se comportan con respecto a los datos. El cambio
cultural es un reto. Requiere planificación, entrenamiento y refuerzo. (Consulte el Capítulo 17). Si bien los detalles del cambio cultural diferirán de
una organización a otra, la mayoría de las implementaciones del programa de calidad de datos deben planificarse.
por:
• Métricas sobre el valor de los datos y el costo de los datos de mala calidad: una forma de aumentar la
la conciencia de la necesidad de la gestión de la calidad de los datos es a través de métricas que describen el valor de los datos y el
retorno de la inversión de las mejoras. Estas métricas (que difieren de los puntajes de calidad de los datos) brindan la base para
financiar mejoras y cambiar el comportamiento tanto del personal como de la gerencia. (Consulte el Capítulo 11.)
• Modelo operativo para las interacciones TI/negocios: la gente de negocios sabe cuáles son los datos importantes y qué significan. Los custodios
de datos de TI entienden dónde y cómo se almacenan los datos, por lo que están bien posicionados para traducir las definiciones de
calidad de datos en consultas o códigos que identifican registros específicos que no cumplen. (Consulte el Capítulo 11.)
• Cambios en la forma en que se ejecutan los proyectos: la supervisión del proyecto debe garantizar que el financiamiento del proyecto incluya
pasos relacionados con la calidad de los datos (p. ej., elaboración de perfiles y evaluación, definición de expectativas de calidad,
remediación, prevención y corrección de problemas de datos, construcción de controles y mediciones). Es prudente asegurarse de que
los problemas se identifiquen temprano y crear expectativas de calidad de datos por adelantado en los proyectos.
• Cambios en los procesos comerciales: la mejora de la calidad de los datos depende de la mejora de los procesos mediante los cuales se
producen los datos. El equipo de calidad de datos debe poder evaluar y recomendar cambios en los procesos no técnicos (así como
técnicos) que afectan la calidad de los datos.
• Financiamiento para proyectos de remediación y mejora: Algunas organizaciones no planean
remediación de datos, incluso cuando son conscientes de los problemas de calidad de los datos. Los datos no se arreglarán solos.
Los costos y beneficios de los proyectos de remediación y mejora deben documentarse para que se pueda priorizar el trabajo de
mejora de los datos.
• Financiamiento para operaciones de calidad de datos: mantener la calidad de los datos requiere operaciones continuas para
monitorear la calidad de los datos, informar sobre los hallazgos y continuar administrando los problemas a medida que se descubren.
La mayoría de las organizaciones que dependen de los datos tienen muchas oportunidades de mejora. Qué tan formal y bien respaldado será un
programa de calidad de datos depende de qué tan madura sea la organización desde una perspectiva de gestión de datos. (Consulte el Capítulo 15).
La disposición organizacional para adoptar prácticas de calidad de datos se puede evaluar considerando las siguientes características:
• Compromiso de la gerencia con la gestión de datos como un activo estratégico: como parte de la solicitud de apoyo para un programa de
calidad de datos, es importante determinar qué tan bien la alta gerencia comprende el papel que juegan los datos en la organización.
¿Hasta qué punto la alta dirección reconoce el valor de los datos para los objetivos estratégicos? ¿Qué riesgos asocian con datos de
mala calidad? ¿Qué tan informados están sobre los beneficios del gobierno de datos? ¿Cuán optimista sobre la capacidad de cambiar la
cultura para apoyar la mejora de la calidad?
• La comprensión actual de la organización sobre la calidad de sus datos: Antes que la mayoría de las organizaciones
comienzan su viaje de mejora de la calidad, generalmente entienden los obstáculos y puntos débiles que significan datos de mala
calidad. Adquirir conocimiento de estos es importante. A través de ellos, los datos de mala calidad pueden asociarse directamente
con efectos negativos, incluidos los costos directos e indirectos, en la organización.
La comprensión de los puntos débiles también ayuda a identificar y priorizar los proyectos de mejora.
• El estado real de los datos: Encontrar una manera objetiva de describir la condición de los datos que está causando
puntos débiles es el primer paso para mejorar los datos. Los datos se pueden medir y describir a través de
492 • DMBOK2
perfiles y análisis, así como a través de la cuantificación de problemas conocidos y puntos débiles. Si el equipo de DQ no
conoce el estado real de los datos, será difícil priorizar y actuar sobre las oportunidades de mejora.
• Riesgos asociados con la creación, el procesamiento o el uso de datos: Identificar lo que puede salir mal con los datos y el daño
potencial a una organización debido a datos de baja calidad proporciona la base para mitigar los riesgos. Si la organización
no reconoce estos riesgos, puede ser un desafío obtener apoyo para el programa de calidad de datos.
• Preparación cultural y técnica para el monitoreo escalable de la calidad de los datos: la calidad de los datos puede verse afectada
negativamente por los procesos comerciales y técnicos. Mejorar la calidad de los datos depende de la cooperación entre el
negocio y los equipos de TI. Si la relación entre la empresa y los equipos de TI no es colaborativa, será difícil avanzar.
Los hallazgos de una evaluación de preparación ayudarán a determinar por dónde empezar y qué tan rápido proceder. Los hallazgos
también pueden proporcionar la base para los objetivos del programa de mapeo de rutas. Si existe un fuerte apoyo para la mejora de la
calidad de los datos y la organización conoce sus propios datos, entonces puede ser posible lanzar un programa estratégico completo. Si la
organización no conoce el estado real de sus datos, entonces puede ser necesario centrarse en desarrollar ese conocimiento antes de
desarrollar una estrategia completa.
La calidad de los datos no se mejorará a través de una colección de herramientas y conceptos, sino a través de una mentalidad que ayude
a los empleados y partes interesadas a actuar pensando siempre en la calidad de los datos y en lo que la empresa y sus clientes necesitan.
Lograr que una organización sea consciente de la calidad de los datos a menudo requiere un cambio cultural significativo. Tal cambio
requiere visión y liderazgo. (Consulte el Capítulo 17.)
El primer paso es promover la conciencia sobre el papel y la importancia de los datos para la organización. Todos los empleados deben
actuar de manera responsable y plantear problemas de calidad de los datos, solicitar datos de buena calidad como consumidores y
proporcionar información de calidad a los demás. Cada persona que toca los datos puede afectar la calidad de esos datos. La calidad de
los datos no es solo responsabilidad de un equipo de DQ o un grupo de TI.
Así como los empleados deben comprender el costo de adquirir un nuevo cliente o retener a un cliente existente, también deben conocer
los costos organizacionales de los datos de mala calidad, así como las condiciones que hacen que los datos sean de mala calidad. Por
ejemplo, si los datos del cliente están incompletos, un cliente puede recibir el producto equivocado, creando costos directos e indirectos para
una organización. El cliente no solo devolverá el producto, sino que también puede llamar y quejarse, utilizando el tiempo del centro de
llamadas, con el potencial de dañar la reputación de la organización. Si los datos del cliente están incompletos porque la organización no ha
establecido requisitos claros, todos los que usan estos datos tienen interés en aclarar los requisitos y seguir los estándares.
En última instancia, los empleados deben pensar y actuar de manera diferente si quieren producir datos de mejor calidad y administrar los
datos de manera que garanticen la calidad. Esto requiere entrenamiento y refuerzo. La formación debe centrarse en:
• Causas comunes de problemas de datos
• Relaciones dentro del ecosistema de datos de la organización y por qué mejorar la calidad de los datos requiere un
enfoque empresarial •
Consecuencias de la mala calidad de los datos •
Necesidad de mejora continua (por qué la mejora no es una cosa de una sola vez) • Convertirse en 'lenguaje
de datos', a punto de articular el impacto de los datos en la estrategia y el éxito de la organización,
informes reglamentarios, satisfacción del cliente
La capacitación también debe incluir una introducción a cualquier cambio en el proceso, con afirmaciones sobre cómo los cambios mejoran la calidad
de los datos.
6. Calidad de datos y gobierno de datos
Un programa de calidad de datos es más efectivo cuando forma parte de un programa de gobierno de datos. A menudo, los problemas de calidad
de los datos son la razón para establecer un gobierno de datos en toda la empresa (consulte el Capítulo 3). La incorporación de esfuerzos de calidad
de datos en el esfuerzo general de gobernanza permite que el equipo del programa de calidad de datos trabaje con una variedad de partes
interesadas y habilitadores:
• Personal de riesgo y seguridad que puede ayudar a identificar vulnerabilidades organizacionales relacionadas con los datos. •
Personal de capacitación e ingeniería de procesos comerciales que puede ayudar a los equipos a implementar mejoras en los procesos. •
Administradores de datos comerciales y operativos, y propietarios de datos que pueden identificar datos críticos, definir
estándares y expectativas de calidad, y priorizar la remediación de problemas de datos
Una Organización de Gobernanza puede acelerar el trabajo de un programa de Calidad de Datos al:
• Establecer prioridades •
Identificar y coordinar el acceso a aquellos que deberían participar en diversos asuntos relacionados con la calidad de los datos
decisiones y actividades
• Desarrollar y mantener estándares para la calidad de los datos • Informar
mediciones relevantes de la calidad de los datos en toda la empresa • Brindar orientación
que facilite la participación del personal • Establecer mecanismos de comunicación para
compartir conocimientos • Desarrollar y aplicar políticas de cumplimiento y calidad de los
datos • Supervisar e informar sobre el desempeño • Compartir resultados de inspección de
calidad de datos para crear conciencia, identificar oportunidades de mejora,
y generar consenso para las mejoras • Resolver
variaciones y conflictos; proporcionando dirección
6.1 Política de calidad de datos
Los esfuerzos de calidad de datos deben estar respaldados y deben respaldar las políticas de gobierno de datos. Por ejemplo, las políticas de
gobierno pueden autorizar auditorías de calidad periódicas y exigir el cumplimiento de los estándares y mejores prácticas.
494 • DMBOK2
practicas Todas las áreas de conocimiento de gestión de datos requieren cierto nivel de política, pero las políticas de calidad de datos son particularmente
importantes ya que a menudo tocan los requisitos reglamentarios. Cada política debe incluir:
• Objeto, alcance y aplicabilidad de la política
• Definición de términos
• Responsabilidades del programa de calidad de datos •
Responsabilidades de otras partes interesadas • Informes •
Implementación de la política, incluidos enlaces a riesgos, medidas
preventivas, cumplimiento, datos
protección y seguridad de datos
6.2 Métricas
Gran parte del trabajo de un equipo de calidad de datos se centrará en medir e informar sobre la calidad. Las categorías de alto nivel de métricas de calidad
de datos incluyen:
• Retorno de la inversión: Declaraciones sobre el costo de los esfuerzos de mejora frente a los beneficios de los datos mejorados
calidad
• Niveles de calidad: Mediciones del número y porcentaje de errores o violaciones de requisitos
dentro de un conjunto de datos o entre conjuntos de datos
• Tendencias de la calidad de los datos: mejora de la calidad a lo largo del tiempo (es decir, una tendencia) frente a umbrales y objetivos, o
incidencias de calidad por periodo
• Métricas de gestión de problemas de datos:
o Recuento de problemas por dimensiones de la calidad de los datos o
Problemas por función empresarial y sus estados (resueltos, pendientes, escalados) o Problema por prioridad y
gravedad
o Tiempo para resolver problemas
• Conformidad con los niveles de servicio: Unidades organizacionales involucradas y personal responsable, proyecto
intervenciones para evaluaciones de calidad de datos, conformidad general del proceso
• Implementación del plan de calidad de datos: tal como está y hoja de ruta para la expansión
Batini, Carlo y Monica Scannapieco. Calidad de Datos: Conceptos, Metodologías y Técnicas. Springer, 2006. Imprimir.
Brackett, Michael H. Calidad de los recursos de datos: convertir los malos hábitos en buenas prácticas. AddisonWesley, 2000. Imprimir.
Deming, W.Edwards. Fuera de la Crisis. La prensa del MIT, 2000. Imprimir.
Inglés, Larry. Mejora del almacén de datos y la calidad de la información comercial: métodos para reducir costos y aumentar las ganancias. John Wiley and
Sons, 1999. Imprimir.
Inglés, Larry. Calidad de la información aplicada: mejores prácticas para mejorar la información, los procesos y los sistemas comerciales.
Wiley Publishing, 2009. Imprimir.
Evans, Nina y Price, James. "Barreras para el despliegue efectivo de activos de información: una perspectiva de gestión ejecutiva". Revista
Interdisciplinaria de Información, Conocimiento y Gestión Volumen 7, 2012. Acceso desde http://bit.ly/2sVwvG4.
Fisher, Craig, Eitel Lauría, Shobha ChengalurSmith and Richard Wang. Introducción a la Calidad de la Información. MIT
Publicaciones del Programa de Calidad de la Información, 2006. Impreso. Libro Avances en la Calidad de la Información Ser.
Gottesdiener, Ellen. Requerimientos por Colaboración: Talleres de Definición de Necesidades. AddisonWesley Professional, 2002.
Imprimir.
Hass, Kathleen B. y Rosemary Hossenlopp. Descubriendo los requisitos comerciales: herramientas y técnicas de elicitación.
Management Concepts, Inc, 2007. Imprimir. Biblioteca esencial de análisis empresarial.
Huang, KuanTsae, Yang W. Lee y Richard Y. Wang. Información y Conocimiento de Calidad. Prentice Hall, 1999. Imprimir.
Jugulum, Rajesh. Competir con datos de alta calidad. Wiley, 2014. Imprimir.
Lee, Yang W., Leo L. Pipino, James D. Funk y Richard Y. Wang. Viaje a la calidad de los datos. La prensa del MIT, 2006. Imprimir.
Loshin, David. Gestión del conocimiento empresarial: el enfoque de calidad de datos. Morgan Kaufmann, 2001. Imprimir.
Loshin, David. Gestión de datos maestros. Morgan Kaufmann, 2009. Imprimir.
Maydanchik, Arkadi. Evaluación de la calidad de los datos. Publicaciones de Technics, LLC, 2007 Imprimir.
McCallum, Ethan. Manual de datos erróneos: Limpiar los datos para que pueda volver al trabajo. 1ra Edición. O´Reilly, 2012.
McGilvray, Danette. Ejecución de proyectos de calidad de datos: diez pasos para obtener datos de calidad e información confiable. Morgan
Myers, Dan. “El valor de utilizar las dimensiones de la calidad de los datos”, Gestión de la información, agosto de 2013. http://bit.ly/
2tsMYiA.
Olson, Jack E. Calidad de datos: la dimensión de precisión. Morgan Kaufmann, 2003. Imprimir.
Redman, Thomas. Calidad de datos: la guía de campo. Prensa Digital, 2001. Impreso.
Robertson, Suzanne y James Robertson. Dominar el proceso de requisitos: obtener los requisitos correctos. 3ra ed.
AddisonWesley Professional, 2012. Imprimir.
SebastiánColeman, Laura. Medición de la calidad de los datos para la mejora continua: un marco de evaluación de la calidad de los datos.
Morgan Kaufmann, 2013. Imprimir. La serie de Morgan Kaufmann sobre inteligencia empresarial.
Tavares, Rossano. Qualidade de Dados em Gerenciamento de Clientes (CRM) e Tecnologia da Informação [Calidad de Datos en la Gestión de Clientes y
Tecnologías de la Información]. São Paulo: Catálise. 2006. Imprimir.
Witt, Graham. Redacción de reglas comerciales efectivas: un método práctico. Morgan Kaufmann, 2012. Imprimir.
CAPÍTULO 1 4
Big Data y ciencia de datos
1. Introducción
S
esde principios de la década de 2000, los términos Big Data y Data Science , lamentablemente, se han difundido como
palabras de moda Los conceptos y sus implicaciones se malinterpretan o, al menos, existe una comprensión limitada.
consenso sobre su significado. Incluso el significado de 'Grande' es relativo. Dicho esto, tanto Big Data como Data Science
están conectados a cambios tecnológicos significativos que han permitido a las personas generar, almacenar y analizar cantidades
cada vez mayores de datos. Más importante aún, las personas pueden usar esos datos para predecir e influir en el comportamiento,
así como para obtener información sobre una variedad de temas importantes, como las prácticas de atención médica, la gestión de
los recursos naturales y el desarrollo económico.
Big Data se refiere no solo al volumen de datos, sino también a su variedad (estructurados y no estructurados, documentos,
archivos, audio, video y transmisión de datos, etc.) y la velocidad a la que se producen (velocidad). Las personas que extraen y
desarrollan modelos y análisis predictivos, de aprendizaje automático y prescriptivos a partir de estos y despliegan los resultados
para que las partes interesadas los analicen se denominan científicos de datos.
Data Science existe desde hace mucho tiempo; solía llamarse 'estadística aplicada'. Pero la capacidad de explorar patrones de
datos ha evolucionado rápidamente en el siglo XXI con el advenimiento de Big Data y las tecnologías que lo respaldan. Business
Intelligence tradicional proporciona informes de 'espejo retrovisor': análisis de datos estructurados para describir tendencias
pasadas. En algunos casos, los patrones de BI se utilizan para predecir el comportamiento futuro, pero no con mucha confianza.
Hasta hace poco, la tecnología limitaba el análisis en profundidad de enormes conjuntos de datos. Los análisis se han basado en
el muestreo u otros medios de abstracción para aproximar patrones. A medida que ha crecido la capacidad para recopilar y analizar
grandes conjuntos de datos, los científicos de datos han integrado métodos de matemáticas, estadísticas, ciencias de la
computación, procesamiento de señales, modelado de probabilidad, reconocimiento de patrones, aprendizaje automático, modelado
de incertidumbre y visualización de datos para obtener información y predecir comportamientos basados en conjuntos de Big Data.
En resumen, Data Science ha encontrado nuevas formas de analizar y obtener valor de los datos.
Dado que Big Data se ha incorporado a los entornos de almacenamiento de datos e inteligencia comercial, las técnicas de ciencia
de datos se utilizan para proporcionar una visión prospectiva ("parabrisas") de la organización. Las capacidades predictivas, en
tiempo real y basadas en modelos, que utilizan diferentes tipos de fuentes de datos, ofrecen a las organizaciones una mejor
comprensión de hacia dónde se dirigen. (Consulte la Figura 96.)
497
498 • DMBOK2
Disminuir
Información
Datos sin procesar DATOS Triángulo
Datos con contexto básico
INFORMACIÓN
Datos
maestr (metadatos asociativos)
datos con negocios
Contexto o función
CONOCIMIENTO
Inteligencia de Negocio
Almacenamiento detallado
Visualizaciones de datos
Informe de excepción
Pasado
Entendiendo la pregunta VISIÓN
Contexto comercial, función e
información relacionada Regalo
DATOS INTELIGENTES
Fuente confiable para
Decisiones comerciales Futuro de la ciencia de datos
GRANDES DATOS Análisis predictivo
Analítica prescriptiva
Ciencia de datos: Aprendizaje automático
encontrar patrones/grupos en la
información; proporcionar información
donde uno no sabría buscar
Figura 96 Triángulo de información de reducción
Sin embargo, para aprovechar Big Data se requiere un cambio en la forma en que se gestionan los datos. La mayoría de los almacenes
de datos se basan en modelos relacionales. Big Data generalmente no está organizado en un modelo relacional. La mayor parte del
almacenamiento de datos depende del concepto de ETL (Extracción, Transformación y Carga). Las soluciones de Big Data, como los
lagos de datos, dependen del concepto de ELT : cargar y luego transformar. De igual importancia, la velocidad y el volumen de los datos
presentan desafíos que requieren diferentes enfoques para los aspectos críticos de la gestión de datos, como la integración, la gestión
de metadatos y la evaluación de la calidad de los datos.
El mayor impulsor comercial para desarrollar capacidades organizacionales en torno a Big Data y Data Science es el deseo de encontrar
y actuar sobre oportunidades comerciales que pueden descubrirse a través de conjuntos de datos generados a través de una gama
diversificada de procesos. Big Data puede estimular la innovación al hacer que más y más grandes conjuntos de datos estén disponibles
para la exploración. Estos datos se pueden utilizar para definir modelos predictivos que anticipen las necesidades del cliente y permitan
una presentación personalizada de productos y servicios. La ciencia de datos puede mejorar las operaciones. Los algoritmos de
aprendizaje automático pueden automatizar actividades complejas que consumen mucho tiempo, mejorando así la eficiencia
organizacional, reduciendo costos y mitigando riesgos.
BIG DATA Y CIENCIA DE DATOS • 499
Big Data y ciencia de datos
Definición: la recopilación (Big Data) y el análisis (ciencia de datos, análisis y visualización) de muchos tipos
diferentes de datos para encontrar respuestas e información para preguntas que no se conocen al comienzo del
análisis.
Objetivos: 1. Descubrir las relaciones entre los datos y el negocio.
2. Apoyar la integración iterativa de fuentes de datos en la empresa.
3. Descubrir y analizar nuevos factores que puedan afectar al negocio.
4. Publicar datos usando técnicas de visualización de manera apropiada, confiable y ética.
Negocio
Conductores
Entradas: Actividades: 1. Entregables:

•
• Estrategia de negocio Definir la estrategia de Big Data y las necesidades Estrategia de Big Data y
y Objetivos comerciales (P) Estándares
• Construir/Comprar/Alquilar
2. Elija fuentes de datos (P) • Plan de obtención de
Árbol de decisión 3. Adquirir e ingerir fuentes de datos (D) datos • Datos adquiridos
4. Desarrollar hipótesis y métodos (D) Fuentes
• Estándares de
•
5. Integrar/alinear datos para análisis (D) Análisis de datos iniciales
TI • Fuentes de datos
6. Explorar datos usando modelos (D) e hipótesis
7. Implementar y monitorear (O) • Perspectivas de
datos y hallazgos •
Plan de mejora
Proveedores: Participantes: Consumidores:

• • • Compañeros de negocio
Plataforma de grandes datos Arquitectos de plataformas de Big Data
Arquitectos • • Ejecutivos de negocios
Arquitectos de ingestión
• Científicos de datos • Pymes de datos • Ejecutivos de TI
• Productores de datos • Científicos de datos
• •
Proveedores de datos Líder de diseño analítico •
• Consumidores de información Gerentes de DM
• Especialistas en Metadatos
Técnico
Conductores
Técnicas: Herramientas: Métrica:

• • Soluciones basadas en archivos distribuidos •
Combinaciones de datos Métricas de uso de datos
•
Aprendizaje automático • Compresión en columnas • Arquitecturas MPP • Métricas de respuesta y rendimiento
Técnicas • SharedNothing
• •
Avanzado Supervisado Informática en memoria y Carga y escaneo de datos
Aprendizaje bases de datos métrica
• •
Algoritmos en base de datos Aprendizajes e Historias
• Conjuntos de herramientas de visualización de datos
Figura 97 Diagrama de contexto: Big Data y ciencia de datos
500 • DMBOK2
1.2 Principios
La promesa de Big Data, que proporcionará un tipo diferente de información, depende de poder administrar Big Data. En muchos sentidos, debido a la gran
variedad de fuentes y formatos, la gestión de Big Data requerirá más disciplina que la gestión de datos relacionales. Los principios relacionados con la gestión
de Big Data aún no se han formado por completo, pero uno es muy claro: las organizaciones deben gestionar cuidadosamente los metadatos relacionados con
las fuentes de Big Data para tener un inventario preciso de los archivos de datos, sus orígenes y su valor.
1.3.1 Ciencia de datos
Como se señaló en la introducción del capítulo, Data Science combina la extracción de datos, el análisis estadístico y el aprendizaje automático con capacidades
de integración y modelado de datos para crear modelos predictivos que exploran patrones de contenido de datos. El desarrollo de modelos predictivos a veces
se denomina ciencia de datos porque el analista de datos, o científico de datos, utiliza el método científico para desarrollar y evaluar un modelo.
El científico de datos desarrolla una hipótesis sobre el comportamiento que se puede observar en los datos antes de una acción particular. Por ejemplo, la
compra de un tipo de artículo suele ir seguida de la compra de otro tipo de artículo (la compra de una casa suele ir seguida de la compra de muebles). Luego,
el científico de datos analiza grandes cantidades de datos históricos para determinar con qué frecuencia la hipótesis ha sido cierta en el pasado y para verificar
estadísticamente la precisión probable del modelo. Si una hipótesis es válida con suficiente frecuencia y si el comportamiento que predice es útil, entonces el
modelo puede convertirse en la base de un proceso de inteligencia operativa para predecir el comportamiento futuro, incluso posiblemente en tiempo real, como
anuncios de venta sugerentes.
El desarrollo de soluciones de ciencia de datos implica la inclusión iterativa de fuentes de datos en modelos que desarrollan conocimientos. La ciencia de datos
depende de:
• Fuentes ricas de datos: Datos con el potencial de mostrar patrones invisibles en la organización o
comportamiento del cliente
• Alineación y análisis de la información: técnicas para comprender el contenido de los datos y combinar conjuntos de datos para
formular hipótesis y probar patrones significativos
• Entrega de información: Ejecutar modelos y algoritmos matemáticos contra los datos y producir
visualizaciones y otros resultados para obtener información sobre el comportamiento
• Presentación de hallazgos y perspectivas de datos: Análisis y presentación de hallazgos para que las perspectivas puedan
ser compartido
La Tabla 32 compara el papel de DW/BI tradicional con el análisis predictivo y prescriptivo que se puede lograr a través de técnicas de ciencia de datos.
GRANDES DATOS Y CIENCIA DE DATOS • 501
Tabla 32 Progresión de análisis
DW / BI tradicional Ciencia de los datos
Retrospectiva Profético Preceptivo
descriptiva Visión Previsión
Basada en la historia: Basado en escenarios:
Basado en modelos predictivos:
¿Qué pasó? ¿Qué debemos hacer para que las
¿Qué es probable que suceda?
¿Por qué sucedió? cosas sucedan?
1.3.2 El proceso de ciencia de datos
La Figura 98 ilustra las fases iterativas del proceso de ciencia de datos. Las salidas de cada paso se convierten en las entradas del siguiente.
(Consulte la Sección 2).
1. Definir la
estrategia de Big
Data y las
necesidades comerciales
7. Implementar 2. Elija la(s)
& fuente(s)
Monitor
de datos
6. Explora 3. Adquirir e
datos usando ingerir fuentes
modelos de datos
4. Desarrollar
5. Integrar/
hipótesis y
alinear datos
métodos de
para análisis
ciencia de datos
Figura 98 Proceso de ciencia de datos
El proceso de ciencia de datos sigue el método científico de refinar el conocimiento al hacer observaciones, formular y probar hipótesis,
observar resultados y formular teorías generales que explican los resultados.
Dentro de Data Science, este proceso toma la forma de observar datos y crear y evaluar modelos de comportamiento:
• Definir la estrategia de Big Data y las necesidades comerciales: definir los requisitos que identifican los resultados deseados
con beneficios tangibles medibles.
• Elija fuentes de datos: identifique los vacíos en la base de activos de datos actual y encuentre fuentes de datos para llenar esos
brechas.
502 • DMBOK2
• Adquirir e ingerir fuentes de datos: Obtenga conjuntos de datos e incorpórelos.
• Desarrollar hipótesis y métodos de ciencia de datos: explorar fuentes de datos a través de perfiles, visualización, minería,
etc.; perfeccionar los requisitos. Definir entradas de algoritmos del modelo, tipos o hipótesis del modelo y métodos de
análisis (es decir, agrupaciones de datos encontrados por agrupamiento, etc.).
• Integre y alinee los datos para el análisis: la viabilidad del modelo depende en parte de la calidad de la fuente
datos. Aproveche fuentes confiables y creíbles. Aplicar técnicas apropiadas de integración y limpieza de datos
para aumentar la calidad y la utilidad de los conjuntos de datos aprovisionados.
• Explorar datos usando modelos: aplicar análisis estadísticos y algoritmos de aprendizaje automático contra la
datos integrados. Valide, entrene y, con el tiempo, evolucione el modelo. El entrenamiento implica ejecuciones repetidas
del modelo contra datos reales para verificar suposiciones y hacer ajustes, como identificar valores atípicos.
A través de este proceso, se perfeccionarán los requisitos. Las métricas iniciales de factibilidad guían la evolución del
modelo. Se pueden introducir nuevas hipótesis que requieran conjuntos de datos adicionales y los resultados de esta
exploración darán forma al modelado y los resultados futuros (incluso cambiando los requisitos).
• Implementar y monitorear: Aquellos modelos que producen información útil pueden implementarse en producción para un
monitoreo continuo de valor y efectividad. A menudo, los proyectos de Data Science se convierten en proyectos de
almacenamiento de datos donde se implementan procesos de desarrollo más vigorosos (ETL, DQ, Master Data, etc.).
1.3.3 Grandes datos
Los primeros esfuerzos para definir el significado de Big Data lo caracterizaron en términos de las Tres V: Volumen, Velocidad, Variedad
(Laney, 2001). A medida que más organizaciones comienzan a aprovechar el potencial de Big Data, la lista de V se ha ampliado:
• Volumen: Se refiere a la cantidad de datos. Big Data a menudo tiene miles de entidades o elementos en miles de millones
de registros
• Velocidad: se refiere a la velocidad a la que se capturan, generan o comparten los datos. Big Data es a menudo
generados y también pueden ser distribuidos e incluso analizados en tiempo real.
• Variedad/Variabilidad: Se refiere a las formas en que se capturan o entregan los datos. Big Data requiere el almacenamiento
de múltiples formatos; la estructura de datos a menudo es inconsistente dentro o entre conjuntos de datos.
• Viscosidad: se refiere a la dificultad de usar o integrar los datos.
• Volatilidad: se refiere a la frecuencia con la que se producen cambios en los datos y, por lo tanto, durante cuánto tiempo son útiles los datos.
• Veracidad: Se refiere a cuán confiables son los datos.
Los volúmenes de Big Data son excepcionalmente grandes (más de 100 terabytes y, a menudo, en el rango de petabytes y exabytes).
En soluciones analíticas y de almacenamiento, grandes volúmenes de datos plantean desafíos para la carga, el modelado, la limpieza y
el análisis de datos. Estos desafíos a menudo se resuelven utilizando procesamiento paralelo masivo, o
procesamiento paralelo y soluciones de datos distribuidos. Sin embargo, tienen implicaciones mucho más amplias. El tamaño de los
conjuntos de datos requiere cambios en la forma general en que se almacenan y acceden a los datos, así como en cómo se entienden
los datos (p. ej., gran parte de nuestra forma actual de pensar sobre los datos se basa en estructuras de bases de datos relacionales),
así como en cómo se gestionan los datos (Adams, 2009). La Figura 99 presenta un resumen visual de la variedad de datos que están
disponibles a través de las tecnologías Big Data y las implicaciones en las opciones de almacenamiento de datos.
exabyte Internet de las Cosas
Sitios sociales
Sensores/escáneres
Audio Video
Archivos de registro
Petabyte Mercadotecnia
Móvil
web 2.0
comercio electrónico
Volumen
Registros web
Terabyte EDW/BW blogs/wikis
GPS
Colaboración
Publicidad
Gigabyte Clientes
productos Textos/Imágenes
Velocidad Variedad Veracidad
Almacenamiento EDW/BW web 2.0 Internet de las Cosas
Figura 99 Desafíos de almacenamiento de datos 88
1.3.4 Componentes de la arquitectura de Big Data
La selección, instalación y configuración de un entorno de Big Data y Data Science requiere experiencia especializada. Las
arquitecturas de extremo a extremo deben desarrollarse y racionalizarse frente a las herramientas de exploración de datos existentes
y las nuevas adquisiciones.
La Figura 100 describe la arquitectura DW/BI y Big Data. (Los detalles sobre los componentes DW/BI se describen en el Capítulo 11).
La mayor diferencia entre DW/BI y el procesamiento de Big Data es que en un almacén de datos tradicional, los datos se integran a
medida que se introducen en el almacén (extracción, TRANSFORMACIÓN, carga) ; mientras que en un entorno de Big Data, los datos
se ingieren y cargan antes de integrarlos (extraer, CARGAR, transformar). En algunos casos, los datos pueden no estar integrados en
absoluto, en el sentido tradicional. En lugar de integrarse en preparación para el uso, a menudo se integra a través de usos particulares
(p. ej., el proceso de creación de modelos predictivos impulsa la integración de conjuntos de datos particulares).
88 Obtenido y utilizado con permiso de Robert Abate/EMC Corporation.
504 • DMBOK2
Arquitectura Conceptual DW/BI y Big Data
Fuentes Almacén de datos BI
Solicitud Dominio de datos
Operacional Intervención de calidad de datos
Informes Enriquecimiento y Aumento
Dependiente
Informes operativos
Área de ensayo
Intera
Apre
Pred
Com
Eval
Infor DaaS
Operacional
Sistemas
Grandes datos
Resultados
MDM
Limpio
Integrar
Enriquecer
Estandarizar
Referencia &
Datos maestros
Conformado
Dimensiones
Almacén Central
Orientado al sujeto
No volátil
Variante de tiempo
Atómico
Información histórica
Almacenes de datos
SAO
Mercado de datos
Cubos
y análisis
Geoespacial y
Análisis demográfico
Actuación
Gestión
Visualización de datos
Minería de datos y texto
no estructurado
Analítica
Grandes datos
Email
Multimedia
© DATALEADERS.ORG
Sensores Análisis predictivo
Evaluar
IoT
Ingerir Lago de datos Integrar Explorar
Sociel Network Modelo
Web DaaS DW Aprendizaje automático
Figura 100 Arquitectura Conceptual DW/BI y Big Data
La diferencia entre ETL y ELT tiene implicaciones significativas sobre cómo se gestionan los datos. Por ejemplo, el proceso de
integración no se basa necesariamente en un modelo de datos empresariales ni lo produce. El riesgo es que se puede perder
mucho conocimiento sobre los datos si los procesos de ingestión y uso se ejecutan de forma ad hoc. Existe la necesidad de recopilar
y gestionar los metadatos relacionados con estos procesos, si se quieren comprender y aprovechar.
Con el tiempo.
Las siguientes secciones describirán las fuentes de Big Data y la construcción del lago de datos. Las actividades (Ingerir, Integrar,
Explorar, Evaluar modelo) se exploran en la sección Actividades.
1.3.5 Fuentes de Big Data
Debido a que gran parte de la actividad humana se ejecuta electrónicamente, se acumulan cantidades masivas de datos todos los
días a medida que nos movemos por el mundo, interactuamos entre nosotros y realizamos transacciones comerciales. Big Data se
produce a través del correo electrónico, las redes sociales, los pedidos en línea e incluso los videojuegos en línea. Los datos son
generados no solo por teléfonos y dispositivos de punto de venta, sino también por sistemas de vigilancia, sensores en sistemas de
transporte, sistemas de monitoreo médico, sistemas de monitoreo industrial y de servicios públicos, satélites y equipos militares.
Por ejemplo, un vuelo de una aerolínea puede generar un terabyte de datos. Los dispositivos que interactúan directamente con
Internet generan una gran parte de Big Data. Las conexiones entre dispositivos e Internet a veces se denominan Internet de las
cosas (IoT).
1.3.6 Lago de datos
Un lago de datos es un entorno en el que se puede ingerir, almacenar, evaluar y analizar una gran cantidad de datos de diversos tipos y estructuras.
Los lagos de datos pueden servir para muchos propósitos. Por ejemplo, proporcionando
• Un entorno para que los científicos de datos extraigan y analicen datos. • Un área de
almacenamiento central para datos sin procesar, con una transformación mínima, si la hay. •
Almacenamiento alternativo para datos de almacén de datos históricos detallados.
• Un archivo en línea para registros
• Un entorno para ingerir datos de transmisión con identificación de patrones automatizada
Un lago de datos se puede implementar como una configuración compleja de herramientas de manejo de datos, incluidos Hadoop u otros sistemas de
almacenamiento de datos, servicios de clúster, transformación de datos e integración de datos. Estos controladores han facilitado software de
facilitación analítica entre infraestructuras para unir la configuración.
El riesgo de un lago de datos es que puede convertirse rápidamente en un pantano de datos: desordenado, sucio e inconsistente. Para establecer un
inventario de lo que hay en un lago de datos, es fundamental administrar los metadatos a medida que se ingieren los datos. Para comprender cómo se
asocian o conectan los datos en un lago de datos, los arquitectos de datos o los ingenieros de datos a menudo usan claves únicas u otras técnicas
(modelos semánticos, modelos de datos, etc.) para que los científicos de datos y otros desarrolladores de visualización sepan cómo usar la información
almacenada en el lago de datos. (Consulte el Capítulo 9.)
1.3.7 Arquitectura basada en servicios
La arquitectura basada en servicios (SBA) está surgiendo como una forma de proporcionar datos inmediatos (si no completamente precisos o
completos), así como actualizar un conjunto de datos históricos completos y precisos, utilizando la misma fuente (Abate, Aiken, Burke, 1997) . La
arquitectura SBA es similar a las arquitecturas DW que envían datos directamente a un ODS para acceso inmediato, así como al DW para acumulación
histórica. Las arquitecturas SBA tienen tres principales
componentes, una capa por lotes, una capa de velocidad y una capa de servicio. (Consulte la Figura 101.)
• Capa de lote: un lago de datos sirve como capa de lote y contiene datos recientes e históricos • Capa de velocidad: contiene
solo datos en tiempo real • Capa de servicio: proporciona una interfaz para unir datos de las capas de lote y velocidad
Los datos se cargan en las capas de lote y velocidad. Todos los cálculos analíticos se realizan en datos tanto en la capa de lotes como en la de
velocidad, lo que probablemente requiera implementación en dos sistemas separados. Las organizaciones abordan los problemas de sincronización a
través de compensaciones entre la integridad, la latencia y la complejidad de las vistas fusionadas definidas en la capa de servicio. Se requiere una
evaluación de costo/beneficio para determinar si la reducción de la latencia o la mejora de la integridad de los datos valen el costo y la complejidad
asociados.
La capa de lote a menudo se denomina componente de estructura a lo largo del tiempo (aquí cada transacción es una inserción), mientras que en la
capa de velocidad (a menudo denominada Almacén de datos operativos u ODS), todas las transacciones son actualizaciones (o inserciones solamente).
si es requerido). De esta manera, la arquitectura evita problemas de sincronización mientras crea simultáneamente un estado actual y una capa de
historial. Esta arquitectura suele proporcionar sus datos a través de un
506 • DMBOK2
servicio o capa de servicios de datos que abstrae los datos utilizando metadatos. Esta capa de servicios determina desde dónde se
"servirán" los datos y proporciona los datos solicitados de manera adecuada.
Capa de velocidad
En tiempo real, sin historial
Fuente Capa de servicio
Datos
vista fusionada
Capa por lotes
Historial completamente
procesado
Figura 101 Arquitectura basada en servicios
1.3.8 Aprendizaje automático
Machine Learning explora la construcción y el estudio de algoritmos de aprendizaje. Puede verse como una unión de métodos de
aprendizaje no supervisados, más comúnmente conocidos como minería de datos, y métodos de aprendizaje supervisados
profundamente arraigados en la teoría matemática, específicamente estadística, combinatoria y optimización. Ahora se está formando
una tercera rama llamada aprendizaje de refuerzo, en la que se obtiene el rendimiento de la meta pero no se reconoce específicamente
al maestro, por ejemplo, conducir un vehículo. La programación de máquinas para aprender rápidamente de las consultas y adaptarse
a conjuntos de datos cambiantes dio lugar a un campo completamente nuevo dentro de Big Data conocido como aprendizaje
automático . la
resultados.
Machine Learning explora la construcción y el estudio de algoritmos de aprendizaje. Estos algoritmos se dividen en tres
tipos:
• Aprendizaje supervisado: Basado en reglas generalizadas; por ejemplo, separando SPAM de no SPAM
Email
• Aprendizaje no supervisado: basado en la identificación de patrones ocultos (es decir, minería de
datos) • Aprendizaje por refuerzo: basado en el logro de un objetivo (p. ej., vencer a un oponente en el ajedrez)
El modelado estadístico y el aprendizaje automático se han empleado para automatizar proyectos de investigación y desarrollo que de
otro modo serían costosos, mediante la realización de varias pruebas y errores en un amplio conjunto de datos, repitiendo las pruebas
con los resultados recopilados, analizados y corregidos los errores. Este enfoque puede reducir drásticamente el tiempo de respuesta y
89 Consulte la tabla periódica de recursos de aprendizaje automático en http://bit.ly/1DpTrHC para obtener una guía interactiva de las diferentes
plataformas disponibles para el desarrollador, científico y profesional del aprendizaje automático.
guíe las iniciativas organizacionales con conocimientos basados en procesos rentables y repetibles. Por ejemplo, CIVDDD utiliza
aprendizaje automático y técnicas complejas de visualización de datos científicos para ayudar a las agencias gubernamentales y las
fuerzas de mantenimiento de la paz a enfrentar el desafío de lidiar con las masas de información relacionada con amenazas.90
Si bien aprovecha los datos de nuevas formas, el aprendizaje automático tiene implicaciones éticas, especialmente con respecto al
principio de transparencia. La evidencia muestra que las redes neuronales de aprendizaje profundo (DLNN) funcionan. Aprenden cosas.
Sin embargo, no siempre está claro cómo aprenden. A medida que los algoritmos que impulsan estos procesos se vuelven más
complejos, también se vuelven más opacos y funcionan como "cajas negras". Como dan cuenta de un mayor número de variables y
como esas variables en sí mismas son más abstractas, los algoritmos ponen a prueba los límites de la capacidad humana para
interpretar la máquina (Davenport, 2017). La necesidad de transparencia, la capacidad de ver cómo se toman las decisiones,
probablemente aumentará a medida que esta funcionalidad evolucione y se utilice en una gama más amplia de situaciones. (Consulte
el Capítulo 2.)
1.3.9 Análisis de sentimiento
El monitoreo de medios y el análisis de texto son métodos automatizados para recuperar información de grandes datos no estructurados
o semiestructurados, como datos de transacciones, redes sociales, blogs y sitios web de noticias. Esto se usa para comprender lo que
la gente dice y siente sobre marcas, productos o servicios, u otro tipo de temas. Mediante el procesamiento del lenguaje natural (NLP)
o mediante el análisis de frases u oraciones, el análisis semántico puede detectar sentimientos y también revelar cambios en los
sentimientos para predecir posibles escenarios.
Considere el caso de buscar palabras clave en una publicación. Si las palabras bueno o excelente están presentes, esta podría ser
una respuesta positiva, mientras que ver horrible o malo podría ser una señal de que podría ser una respuesta negativa.
Categorizando los datos en los tipos de respuestas, se expone el 'sentimiento' de toda la comunidad o publicación (redes sociales
como Twitter, blogs, etc.). Dicho esto, el sentimiento no se obtiene fácilmente, ya que las palabras por sí solas no cuentan toda la
historia (es decir, tuve un gran problema con su servicio al cliente). El sentimiento debe interpretar las palabras en su contexto. Esto
requiere una comprensión del significado de la publicación; esta interpretación a menudo requiere trabajar con funciones NLP que se
encuentran en sistemas como Watson de IBM.
1.3.10 Minería de datos y texto
La minería de datos es un tipo particular de análisis que revela patrones en los datos utilizando varios algoritmos. Comenzó como una
rama del aprendizaje automático, un subcampo de la inteligencia artificial. La teoría es un subconjunto del análisis estadístico conocido
como aprendizaje no supervisado donde los algoritmos se aplican a un conjunto de datos sin conocimiento o intención del resultado
deseado. Mientras que las herramientas estándar de consulta e informes hacen preguntas específicas, las herramientas de minería de
datos ayudan a descubrir relaciones desconocidas al revelar patrones. La minería de datos es una actividad clave durante la fase de
exploración, ya que facilita la identificación rápida de los elementos de datos estudiados, identifica nuevas relaciones previamente
desconocidas, poco claras o sin clasificar, y proporciona una estructura para la clasificación de los elementos de datos estudiados.
90
CIVDDD, el Centro para la Innovación en Información y Diseño Basado en Datos, es una subvención de investigación en análisis y visualización
de big data para desarrollar técnicas de visualización, diseño y descubrimiento de datos de próxima generación para nuevas herramientas
computacionales, estrategias de representación e interfaces.
508 • DMBOK2
La minería de texto analiza documentos con técnicas de análisis de texto y minería de datos para clasificar el contenido automáticamente en ontologías
guiadas por flujo de trabajo y dirigidas a SME. Por lo tanto, los medios de texto electrónicos se pueden analizar sin reestructurar o reformatear. Las
ontologías se pueden vincular a los motores de búsqueda, lo que permite realizar consultas habilitadas para la web en estos documentos. (Consulte el
Capítulo 9.)
La minería de datos y texto utiliza una variedad de técnicas, que incluyen:
• Elaboración de perfiles: la elaboración de perfiles intenta caracterizar el comportamiento típico de un individuo, grupo o población.
La creación de perfiles se utiliza para establecer normas de comportamiento para las aplicaciones de detección de anomalías,
como la detección de fraudes y el control de intrusiones en los sistemas informáticos. Los resultados del perfil son entradas para
muchos componentes de aprendizaje no supervisados.
• Reducción de datos : la reducción de datos reemplaza un gran conjunto de datos con un conjunto de datos más pequeño que contiene gran
parte de la información importante en el conjunto más grande. El conjunto de datos más pequeño puede ser más fácil de analizar o procesar.
• Asociación: La asociación es un proceso de aprendizaje no supervisado para encontrar relaciones entre elementos estudiados en base a
transacciones que los involucran. Los ejemplos de asociación incluyen: minería de conjuntos de elementos frecuentes, descubrimiento
de reglas y análisis basado en el mercado. Los sistemas de recomendación en Internet también utilizan este proceso.
• Agrupación: Agrupación de elementos de grupo en un estudio por sus características compartidas. La segmentación de clientes es un
ejemplo de agrupamiento.
• Mapas autoorganizados: los mapas autoorganizados son un método de red neuronal de análisis de conglomerados.
A veces denominados Mapas de Kohonen, o mapas ordenados topológicamente, tienen como objetivo reducir la dimensionalidad
en el espacio de evaluación mientras preservan las relaciones de distancia y proximidad tanto como sea posible, similar a la escala
multidimensional. Reducir la dimensionalidad es como eliminar una variable de la ecuación sin violar el resultado. Esto hace que sea más
fácil de resolver y visualizar.
1.3.11 Análisis predictivo
El análisis predictivo es el subcampo del aprendizaje supervisado donde los usuarios intentan modelar elementos de datos y predecir resultados futuros a
través de la evaluación de estimaciones de probabilidad. Arraigado profundamente en las matemáticas, específicamente en las estadísticas, el análisis
predictivo comparte muchos componentes con el aprendizaje no supervisado, con la diferencia prescrita para la medición de un resultado predictivo
deseado.
La Analítica Predictiva es el desarrollo de modelos de probabilidad basados en variables, incluyendo datos históricos, relacionados con posibles eventos
(compras, cambios de precio, etc.). Cuando recibe otras piezas de información, el modelo provoca una reacción por parte de la organización. El factor
desencadenante puede ser un evento, como que un cliente agregue un producto a un carrito de compras en línea, o pueden ser datos en un flujo de
datos, como noticias o datos de sensores de servicios públicos, o un mayor volumen de solicitudes de servicio. . El factor desencadenante puede ser un
evento externo. Las noticias que se informan sobre una empresa son un gran predictor de un cambio en el precio de las acciones. Predecir el movimiento
de las acciones debe incluir el seguimiento de las noticias y determinar si es probable que las noticias sobre una empresa sean buenas o malas para el
precio de las acciones.
Con frecuencia, el factor desencadenante es la acumulación de un gran volumen de datos en tiempo real, como un número extremadamente alto
de operaciones o solicitudes de servicio o la volatilidad del entorno. El monitoreo de un flujo de eventos de datos incluye la construcción incremental
en los modelos poblados hasta que se alcanza un umbral como se define en el modelo.
La cantidad de tiempo que proporciona un modelo predictivo entre la predicción y el evento predicho suele ser muy pequeña (segundos o menos
de un segundo). La inversión en soluciones tecnológicas de muy baja latencia, como bases de datos de memoria, redes de alta velocidad e incluso
proximidad física a la fuente de los datos, optimiza la capacidad de una organización para reaccionar ante la predicción.
La forma más simple de modelo predictivo es el pronóstico. Existen muchas técnicas para generar tendencias o pronósticos basadas en el análisis
de regresión y se benefician del suavizado. La forma más sencilla de suavizar los datos es mediante una media móvil o incluso una media móvil
ponderada. Pueden ser útiles técnicas más avanzadas, como la media móvil exponencial, que introduce un factor de suavizado que se debe
aplicar. Minimizar el error residual de los mínimos cuadrados puede ser un punto de partida, pero se necesitan varias ejecuciones para determinar
y optimizar el factor de suavizado.
Existen modelos de suavizado exponencial doble y triple para abordar los componentes de tendencia y estacionalidad.
1.3.12 Analítica prescriptiva
El análisis prescriptivo lleva el análisis predictivo un paso más allá para definir acciones que afectarán los resultados, en lugar de simplemente
predecir los resultados de las acciones que han ocurrido. El análisis prescriptivo anticipa lo que sucederá, cuándo sucederá e implica por qué
sucederá. Debido a que el análisis prescriptivo puede mostrar las implicaciones de varias decisiones, puede sugerir cómo aprovechar una
oportunidad o evitar un riesgo.
El análisis prescriptivo puede incorporar continuamente nuevos datos para volver a predecir y volver a prescribir. Este proceso puede mejorar la
precisión de la predicción y dar como resultado mejores prescripciones.
1.3.13 Análisis de datos no estructurados
El análisis de datos no estructurados combina minería de texto, asociación, agrupación y otras técnicas de aprendizaje no supervisado para
codificar grandes conjuntos de datos. Las técnicas de aprendizaje supervisado también se pueden aplicar para proporcionar orientación, supervisión
y guía en el proceso de codificación aprovechando la intervención humana para resolver la ambigüedad cuando
necesario.
El análisis de datos no estructurados se está volviendo más importante a medida que se generan más datos no estructurados. Algunos análisis
son imposibles sin la capacidad de incorporar datos no estructurados en modelos analíticos. Sin embargo, los datos no estructurados son difíciles
de analizar sin alguna forma de aislar los elementos de interés de los elementos extraños.
Escanear y etiquetar es una forma de agregar "ganchos" a los datos no estructurados que permiten filtrar y vincular datos estructurados
relacionados. Sin embargo, saber qué etiquetas generar en función de qué condiciones es difícil. Es un proceso iterativo, desde que se identifican
las condiciones de etiqueta propuestas, se asignan etiquetas a medida que se ingieren los datos, luego el análisis usa esas etiquetas para validar
la condición de etiqueta y analizar los datos etiquetados, lo que luego conduce a condiciones de etiqueta potencialmente modificadas, o más.
etiquetas
510 • DMBOK2
1.3.14 Analítica operativa
El concepto de análisis operativo (también conocido como BI operativo o análisis de transmisión) surgió de la integración del análisis en tiempo real
en las operaciones. El análisis operativo incluye actividades como segmentación de usuarios, análisis de sentimientos, geocodificación y otras
técnicas aplicadas a conjuntos de datos para análisis de campañas de marketing, penetración de ventas, adopción de productos, optimización de
activos y gestión de riesgos.
El análisis operativo implica rastrear e integrar flujos de información en tiempo real, derivar conclusiones basadas en modelos predictivos de
comportamiento y desencadenar respuestas y alertas automáticas. El diseño del modelo, los disparadores y las respuestas necesarias para un
análisis exitoso requiere más análisis de los datos en sí. Una solución de análisis operativo incluye la preparación de datos históricos para el llenado
previo de los modelos de comportamiento. Por ejemplo, en un modelo de producto minorista, completar un análisis de la cesta de la compra que
identifique los productos que a menudo se compran juntos. Para predecir el comportamiento de los mercados financieros, la información de precios
históricos y la tasa de cambio de precios históricos se utilizan regularmente. Los cálculos de prepoblación generalmente se realizan con anticipación
para permitir respuestas oportunas a los eventos desencadenantes.
Una vez que se ha determinado que los modelos predictivos son útiles y rentables, se implementan soluciones que integran datos históricos y
actuales (incluidos datos en tiempo real y de transmisión, estructurados y no estructurados) para completar los modelos predictivos y desencadenar
acciones basadas en las predicciones. La solución debe garantizar que los flujos de datos en tiempo real que utilizan las reglas del modelo se
procesen correctamente y que las respuestas automáticas a eventos significativos en los datos se generen correctamente.
1.3.15 Visualización de datos 91
La visualización es el proceso de interpretar conceptos, ideas y hechos mediante el uso de imágenes o representaciones gráficas. La visualización
de datos facilita la comprensión de los datos subyacentes al presentarlos en un resumen visual, como un cuadro o gráfico. Las visualizaciones de
datos condensan y encapsulan datos de características, haciéndolos más fáciles de ver. Al hacerlo, pueden sacar a la luz oportunidades, identificar
riesgos o resaltar mensajes.
Las visualizaciones de datos se pueden entregar en un formato estático, como un informe publicado, o un formato en línea más interactivo; y algunos
admiten la interacción del usuario final donde las capacidades de exploración o filtrado facilitan el análisis de datos dentro de la visualización. Otros
permiten que el usuario cambie la visualización a pedido a través de pantallas innovadoras, como mapas de datos y paisajes de datos en movimiento
a lo largo del tiempo.
La visualización ha sido durante mucho tiempo fundamental para el análisis de datos. Las herramientas de BI tradicionales incluyen opciones de
visualización como tablas, gráficos circulares, gráficos de líneas, gráficos de áreas, gráficos de barras, histogramas y cuadros llave en mano
(candelabros). Para satisfacer la creciente necesidad de comprender los datos, se ha incrementado el número de herramientas de visualización y se
han mejorado las técnicas.
91 La visualización de datos es un campo en evolución. Los principios aplicados en la visualización de datos se basan en principios de
diseño. Ver Tufte, 2001 y McCandless 2012. Existen numerosos recursos basados en la web con ejemplos y contraejemplos. Consulte la
tabla periódica de métodos de visualización en Visual Literacy.Org http://bit.ly/IX1bvI.
A medida que madure el análisis de datos, visualizar los datos de nuevas formas ofrecerá ventajas estratégicas. Ver nuevos patrones en los
datos puede generar nuevas oportunidades comerciales. A medida que la visualización de datos continúa evolucionando, las organizaciones
tendrán que hacer crecer sus equipos de Business Intelligence para competir en un mundo cada vez más impulsado por los datos. Los
departamentos analíticos de negocios buscarán expertos en datos con habilidades de visualización, incluidos científicos de datos, artistas de
datos y expertos en visión de datos, además de arquitectos de información tradicionales y modeladores de datos, especialmente dados los
riesgos asociados con la visualización engañosa. (Consulte el Capítulo 2.)
1.3.16 Combinaciones de datos
Los mashups combinan datos y servicios para crear visualizaciones para obtener información o análisis. Muchas herramientas de virtualización
permiten mashups a través de la funcionalidad que relaciona fuentes de datos por elementos de datos comunes, originalmente utilizados para
relacionar un nombre o texto descriptivo con un código almacenado. Esta técnica de mashup de presentación del cliente es ideal durante las
fases de descubrimiento o exploración, ya que proporciona beneficios inmediatos. Esta técnica se puede aplicar fácilmente a la web, donde
los mashups de datos seguros permiten compartir información personal o confidencial entre proveedores o proveedores. Estos pueden
combinarse con algoritmos de aprendizaje de inteligencia artificial para exponer servicios basados en Internet con interfaces de lenguaje
natural.
2. Actividades
2.1 Definir la estrategia de Big Data y las necesidades comerciales
La estrategia de Big Data de una organización debe estar alineada y respaldar su estrategia comercial general y los requisitos comerciales y
ser parte de su estrategia de datos. Una estrategia de Big Data debe incluir criterios para evaluar:
• Qué problemas está tratando de resolver la organización. Para qué necesita el análisis: mientras uno
La ventaja de Data Science es que puede proporcionar una nueva perspectiva sobre una organización, la organización aún
necesita tener un punto de partida. Una organización puede determinar que los datos se utilizarán para comprender el negocio o
el entorno comercial; probar ideas sobre el valor de nuevos productos; explorar algo que se desconoce; o inventar una nueva
forma de hacer negocios. Es importante establecer un proceso de selección para evaluar estas iniciativas en varias fases durante
la implementación. El valor y la viabilidad de las iniciativas deben evaluarse en varios momentos.
• Qué fuentes de datos usar o adquirir: las fuentes internas pueden ser fáciles de usar, pero también pueden tener un alcance limitado.
Las fuentes externas pueden ser útiles, pero están fuera del control operativo (administradas por otros o no controladas por nadie,
como en el caso de las redes sociales). Muchos proveedores compiten en este espacio y, a menudo, existen múltiples fuentes
para los elementos o conjuntos de datos deseados. La adquisición de datos que se integren con los elementos de ingesta
existentes puede reducir los costos generales de inversión.
512 • DMBOK2
• La puntualidad y el alcance de los datos a proporcionar: muchos elementos se pueden proporcionar en tiempo real
feeds, instantáneas en un punto en el tiempo, o incluso integrado y resumido. Los datos de baja latencia son ideales, pero a
menudo se obtienen a expensas de las capacidades de aprendizaje automático: existe una gran diferencia entre los algoritmos
computacionales dirigidos a datos en reposo y la transmisión. No minimice el nivel de integración requerido para el uso posterior.
• El impacto y la relación con otras estructuras de datos: puede ser necesario que haya una estructura o contenido
cambios en otras estructuras de datos para que sean adecuadas para la integración con conjuntos de Big Data.
• Influencias en los datos modelados existentes: incluida la ampliación del conocimiento sobre clientes, productos y enfoques de
marketing.
La estrategia impulsará el alcance y el momento de la hoja de ruta de capacidad de Big Data de una organización.
2.2 Elegir fuentes de datos
Al igual que con cualquier proyecto de desarrollo, la elección de las fuentes de datos para el trabajo de Data Science debe estar impulsada por
los problemas que la organización está tratando de resolver. La diferencia con el desarrollo de Big Data / Data Science es que la gama de
fuentes de datos es más amplia. No está limitado por el formato y puede incluir datos tanto externos como internos a una organización. La
capacidad de incorporar estos datos en una solución también conlleva riesgos. Es necesario evaluar la calidad y la fiabilidad de los datos y
establecer un plan de uso a lo largo del tiempo. Los entornos de Big Data permiten ingerir rápidamente una gran cantidad de datos, pero para
usar esos datos y administrarlos a lo largo del tiempo, aún es necesario conocer los hechos básicos:
• Su origen
• Su formato
• Qué representan los elementos de datos
• Cómo se conecta con otros datos
• Con qué frecuencia se actualizará
A medida que haya más datos disponibles (como las estadísticas de la Oficina del Censo de EE. UU., datos demográficos de compras, datos
de satélites meteorológicos, conjuntos de datos de investigación), es necesario evaluar el valor y la confiabilidad de los datos. Revise las
fuentes de datos disponibles y los procesos que crean esas fuentes y administre el plan para nuevas fuentes.
• Datos fundamentales: Considere los componentes de datos fundamentales como POS (punto de venta) en un punto de venta.
análisis.
• Granularidad: lo ideal es obtener datos en su forma más granular (no agregada). De esa manera puede ser
agregados para una variedad de propósitos.
• Coherencia: si es posible, seleccione los datos que aparecerán de forma adecuada y coherente en todas las
visualizaciones, o reconozca las limitaciones.
• Confiabilidad: elija fuentes de datos que sean significativas y creíbles a lo largo del tiempo. Use confiable, autorizado
fuentes.
• Inspeccionar/perfilar nuevas fuentes: pruebe los cambios antes de agregar nuevos conjuntos de datos. Pueden ocurrir cambios
significativos o materiales inesperados en los resultados de la visualización con la inclusión de nuevas fuentes de datos.
Los riesgos asociados con las fuentes de datos incluyen problemas de privacidad. La capacidad de ingerir e integrar rápidamente datos de una
variedad de fuentes a escala brinda a las comunidades la capacidad de recombinar conjuntos de datos que de otro modo estarían protegidos.
De manera similar, el análisis publicado puede describir, a través de estados resumidos, agregados o modelados, un subconjunto del público
que lo hace súbitamente identificable; este es un efecto secundario de la capacidad de realizar cálculos masivos en poblaciones muy grandes,
pero publicar en una región o localidad muy específica. Por ejemplo, cuando los datos demográficos calculados a nivel nacional o de país
rápidamente se vuelven no identificables, pero no cuando se publican después de filtrar por código postal o nivel de hogar.92
Los criterios utilizados para seleccionar o filtrar datos también presentan un riesgo. Estos criterios deben gestionarse de manera objetiva para
evitar sesgos o sesgos. El filtrado puede tener un impacto material en la visualización. La discreción es necesaria al eliminar valores atípicos,
restringir conjuntos de datos a un dominio limitado o eliminar elementos dispersos. Es una práctica común enfocar los datos proporcionados
para enfatizar los resultados del aislamiento, pero debe hacerse de manera objetiva y uniforme.93 (Consulte el Capítulo 2).
2.3 Adquirir e Ingerir Fuentes de Datos
Una vez que se identifican las fuentes, es necesario encontrarlas, a veces comprarlas e incorporarlas (cargarlas) en el entorno de Big Data.
Durante este proceso, capture Metadatos críticos sobre la fuente, como su origen, tamaño, moneda y conocimiento adicional sobre el contenido.
Muchos motores de ingestión perfilan los datos a medida que se ingieren, proporcionando a los analistas metadatos al menos parciales. Una
vez que los datos están en un lago de datos, se puede evaluar su idoneidad para múltiples esfuerzos de análisis. Dado que la creación de
modelos de ciencia de datos es un proceso iterativo, también lo es la ingestión de datos.
Identifique de forma iterativa las lagunas en la base de activos de datos actual e incorpore esas fuentes. Explore estas fuentes de datos
utilizando la creación de perfiles, la visualización, la minería u otros métodos de ciencia de datos para definir las entradas del algoritmo del
modelo o las hipótesis del modelo.
Antes de integrar los datos, evalúe su calidad. La evaluación puede ser una simple consulta para averiguar cuántos campos contienen valores
nulos, o tan compleja como ejecutar un conjunto de herramientas de calidad de datos o una utilidad de análisis de datos contra los datos para
perfilar, clasificar e identificar relaciones entre elementos de datos. Dicha evaluación proporciona información sobre si los datos proporcionan
una muestra válida a partir de la cual trabajar y, de ser así, cómo se pueden almacenar y acceder a los datos (dispersos en unidades de
procesamiento lógico [MPP], federados, distribuidos por clave, etc.). Este trabajo involucra a pymes (generalmente los propios científicos de
datos) e ingenieros de plataformas.
El proceso de evaluación proporciona información valiosa sobre cómo se pueden integrar los datos con otros conjuntos de datos, como datos
maestros o datos históricos del almacén. También proporciona información que se puede utilizar en conjuntos de entrenamiento modelo.
y actividades de validación.
92 Véase Martin Fowler, Datensparsamkeit. Blog, 12 de diciembre de 2013. Fowler cuestiona la suposición de que siempre
debemos capturar la mayor cantidad de datos posible. Señala que el enfoque de "capturarlo todo" plantea riesgos de
privacidad. En su lugar, presenta la idea de minimización de datos o escasez de datos (del término alemán
Datensparsamkeit) http://bit.ly/1f9Nq8K.
93 Para obtener más información sobre el impacto del sesgo, que puede afectar profundamente la interpretación de los resultados
científicos, consulte los siguientes sitios web: INFORMS es la principal asociación internacional de profesionales de análisis e
investigación operativa. http://bit.ly/2sANQRW, Sociedad de Estadística de Canadá: http://bit.ly/2oz2o5H y Asociación Estadounidense
de Estadística: http://bit.ly/1rjAmHX.
514 • DMBOK2
2.4 Desarrollar hipótesis y métodos de datos
La ciencia de datos se trata de crear conjuntos de respuestas que puedan encontrar significado o información dentro de los datos. El
desarrollo de soluciones de ciencia de datos implica la construcción de modelos estadísticos que encuentren correlaciones y tendencias
dentro y entre elementos de datos y conjuntos de datos. Habrá múltiples respuestas a una pregunta basadas en las entradas de un
modelo. Por ejemplo, se debe elegir una tasa de rendimiento para calcular el valor futuro de una cartera financiera. Los modelos a menudo
tienen más de una variable, por lo que la mejor práctica es encontrar resultados deterministas o, en otras palabras, utilizar las mejores
conjeturas en cuanto a los valores esperados. Sin embargo, las mejores conjeturas deben ser educadas. Cada modelo operará
dependiendo del método de análisis elegido. Debe probarse para una variedad de resultados, incluso los que parecen menos probables.
Los modelos dependen tanto de la calidad de los datos de entrada como de la solidez del propio modelo. Los modelos de datos a menudo
pueden dar una idea de cómo correlacionar la información encontrada. Un ejemplo de esto es usar el agrupamiento de KMeans para
determinar la cantidad de agrupaciones de datos para analizar más a fondo. (Consulte el Capítulo 13.)
2.5 Integrar/alinear datos para análisis
La preparación de los datos para el análisis implica comprender qué hay en los datos, encontrar vínculos entre los datos de las diversas
fuentes y alinear los datos comunes para su uso.
En muchos casos, unir fuentes de datos es más un arte que una ciencia. Por ejemplo, considere un conjunto de datos basado en
actualizaciones diarias y otro basado en actualizaciones mensuales. Los datos diarios, para estar alineados, tendrían que agregarse para
que hubiera un patrón de alineación que pudiera usarse en la investigación de ciencia de datos.
Un método es usar un modelo común que integre los datos usando una clave común. Otra forma es escanear y unir datos usando índices
dentro de los motores de base de datos para similitud y registrar métodos y algoritmos de vinculación.
A menudo, los datos se inspeccionan durante las fases iniciales para comprender cómo podrían analizarse. La agrupación ayuda a
determinar la agrupación de las salidas de datos. Otros métodos pueden encontrar correlaciones que se usarán para construir el modelo
para mostrar los resultados. Considere el uso de técnicas durante las fases iniciales que ayudarán a comprender cómo el modelo mostrará
los resultados una vez que se publique.
La mayoría de las soluciones requieren la integración de datos maestros y datos de referencia para interpretar los resultados de los
análisis. (Consulte el Capítulo 10.)
2.6 Explorar datos usando modelos
2.6.1 Poblar modelo predictivo
La configuración de modelos predictivos incluye rellenar previamente el modelo con información histórica sobre el cliente, el mercado, los
productos u otros factores que se incluyen en el modelo distintos del factor desencadenante. Los cálculos previos al llenado generalmente
se realizan con anticipación para permitir la respuesta más rápida a los eventos desencadenantes. Para
Por ejemplo, se necesitaría el historial de compras del cliente para completar previamente un modelo de recomendación de canasta de
mercado minorista. Al predecir el comportamiento de los mercados minoristas, la información histórica de precios y cambios de precios se
combina con información de clientes, demográfica y meteorológica.
2.6.2 Entrenar el modelo
Ejecute el modelo contra los datos para 'entrenar' el modelo. El entrenamiento incluye ejecuciones repetidas del modelo contra los datos para
verificar las suposiciones. La formación dará lugar a cambios en el modelo. El entrenamiento requiere equilibrio.
Evite el ajuste excesivo entrenando contra un pliegue de datos limitado.
La validación del modelo debe estar completa antes de pasar a la producción. Aborde cualquier desequilibrio de población o sesgo de datos
con compensaciones de modelo entrenadas y validadas; esto se puede ajustar en la producción a medida que la compensación inicial se
ajusta gradualmente a través de las interacciones reales de la población. La optimización de la combinación de funciones se puede lograr
con la coselección bayesiana, la inversión del clasificador o la inducción de reglas. Los modelos también se pueden combinar para el
aprendizaje conjunto, donde el modelo de predicción se construye combinando las fortalezas recopiladas de modelos más simples.
La identificación de valores atípicos o anomalías (objetos de datos que no cumplen con el comportamiento general exhibido por los elementos
estudiados) es fundamental para evaluar el modelo. Para conjuntos de datos más volátiles, aplique una prueba de varianza basada en el
promedio y la desviación estándar. Ambas pruebas se pueden aplicar fácilmente en resultados perfilados. Puede ser que los valores atípicos
sean el objetivo del ejercicio, en lugar de encontrar y validar tendencias en la mayoría de los datos.
Para el análisis predictivo, utilice un flujo de datos en tiempo real para finalizar la población del modelo predictivo y desencadenar una
respuesta, que puede ser una alerta o un evento. El flujo de datos puede requerir un enfoque especial en el diseño y desarrollo de una
capacidad de procesamiento de latencia extremadamente baja. En algunos modelos, la diferencia en el valor de las predicciones entre
fracciones de segundo es extrema y las soluciones pueden requerir tecnología innovadora con limitaciones de velocidad de la luz.
Los modelos pueden usar muchas funciones y técnicas estadísticas que están disponibles en bibliotecas de código abierto, una de las cuales
es 'R.' R Project for Statistical Computing es un entorno de software libre para computación estadística; contiene muchas funciones como
llamadas de servicio.94 Se pueden desarrollar funciones personalizadas aprovechando el lenguaje de secuencias de comandos y compartirlas
entre herramientas, plataformas y organizaciones.
Una vez que se ha creado el diseño de la solución y se ha estimado el desarrollo y la operación, la organización puede decidir si desarrolla
la solución para predecir el comportamiento. Las soluciones de análisis operativo en tiempo real con frecuencia requieren cantidades
sustanciales de nueva arquitectura y desarrollo y posiblemente no sean rentables.
2.6.3 Evaluar modelo
Una vez que los datos se colocan en una plataforma y están listos para el análisis, comienza la ciencia de datos. El modelo se construye, se
evalúa frente a conjuntos de entrenamiento y se valida. Los refinamientos a los requisitos comerciales son
94 Para obtener más información, visite el sitio web de RProject: http://bit.ly/19WExR5.
516 • DMBOK2
esperado en este punto y las primeras métricas de factibilidad pueden guiar los esfuerzos de gestión hacia un mayor procesamiento o descarte. Es muy
posible que probar una nueva hipótesis requiera conjuntos de datos adicionales.
Los científicos de datos ejecutan consultas y algoritmos contra los datos para ver si se hace evidente alguna información. A menudo, se ejecutarán varias
funciones matemáticas diferentes para ver si se encuentra alguna información (agrupaciones en los datos, patrones que comienzan a surgir entre períodos de
elementos de datos, etc.). Durante este período, los científicos de datos a menudo se basan en los conocimientos encontrados en lotes iterativos. A partir de
estos, se pueden desarrollar modelos que muestren la correlación entre los elementos de datos y los conocimientos.
Hay un componente ético en la práctica de la ciencia de datos y debe aplicarse al evaluar modelos.
Los modelos pueden tener resultados inesperados o reflejar involuntariamente las suposiciones y los sesgos de las personas que los crean. Debería exigirse
formación ética a todos los profesionales de la inteligencia artificial (IA). Idealmente, el plan de estudios para cada estudiante que aprende IA, informática o
ciencia de datos debe incluir temas de ética y seguridad. Sin embargo, la ética por sí sola no es suficiente. La ética puede ayudar a los profesionales a
comprender sus responsabilidades con todas las partes interesadas, pero la capacitación ética debe complementarse con la capacidad técnica para poner en
práctica las buenas intenciones tomando precauciones técnicas a medida que se construye y prueba un sistema (Oficina Ejecutiva, 2016). (Consulte el
Capítulo 2.)
2.6.4 Crear visualizaciones de datos
La visualización de datos basada en el modelo debe satisfacer las necesidades específicas relacionadas con el propósito del modelo. Cada visualización debe
responder a una pregunta o proporcionar una idea. Establezca el propósito y los parámetros para la visualización: un punto en el estado del tiempo, tendencias
frente a excepciones, relaciones entre partes móviles, diferencias geográficas o algún otro punto.
Seleccione la imagen adecuada para cumplir ese propósito. Asegúrese de que la visualización se dirija a una audiencia; ajuste el diseño y la complejidad para
resaltar y simplificar en consecuencia. No todos los públicos están preparados para un gráfico interactivo complejo. Admite visualizaciones con texto explicativo.
Las visualizaciones deben contar una historia. La "narración de historias" de los datos puede vincular nuevas preguntas al contexto de la exploración de datos.
Las historias de datos deben estar respaldadas por visualizaciones de datos relacionados para tener el mejor efecto.
2.7 Implementar y monitorear
Un modelo que satisfaga las necesidades comerciales de manera factible se puede implementar en producción para un monitoreo continuo.
Dichos modelos requerirán refinamiento y mantenimiento. Varias técnicas de modelado están disponibles para su implementación. Los modelos pueden servir
procesos por lotes, así como mensajes de integración en tiempo real. También se pueden integrar en el software de análisis como entrada en los sistemas de
gestión de decisiones, análisis históricos o paneles de gestión del rendimiento.
2.7.1 Exponer ideas y hallazgos
La presentación de hallazgos y conocimientos de datos, generalmente a través de la visualización de datos, es el paso final en una investigación de ciencia de
datos. Las ideas deben estar conectadas a elementos de acción para que la organización se beneficie de la
Trabajo de ciencia de datos.
Se pueden explorar nuevas relaciones a través de técnicas de visualización de datos. A medida que se utiliza un modelo, pueden surgir cambios en los datos
subyacentes y las relaciones, lo que cuenta una nueva historia sobre los datos.
2.7.2 Iterar con fuentes de datos adicionales
La presentación de los hallazgos y la comprensión de los datos suele generar preguntas que inician un nuevo proceso de investigación.
La ciencia de datos es iterativa, por lo que el desarrollo de Big Data es iterativo para respaldarlo. Este proceso de aprender de un conjunto específico de fuentes de
datos a menudo conduce a la necesidad de fuentes de datos diferentes o adicionales para respaldar las conclusiones encontradas y agregar información a los
modelos existentes.
3. Herramientas
Los avances en tecnología (Ley de Moore, la proliferación de dispositivos portátiles, IOT, por nombrar algunos) han creado la industria de Big Data y Data Science.
Para entender la industria, uno debe entender sus impulsores.
Esta sección explicará las herramientas y tecnologías que han permitido que surja Big Data Science.
La llegada de Massively Parallel Processing (MPP) fue uno de los primeros habilitadores de Big Data y Data Science, ya que proporcionó los medios para analizar
grandes volúmenes de información en períodos de tiempo relativamente cortos. Lo que estamos haciendo hoy es encontrar la aguja en el pajar de información o
usar maquinaria para abrirse paso entre toneladas de tierra para encontrar las pepitas de oro. Esta tendencia continuará.
Otros avances que han cambiado la forma en que vemos los datos y la información incluyen:
• Análisis avanzado en base de datos • Análisis de
datos no estructurados (Hadoop, MapReduce) • Integración de resultados analíticos
con sistemas operativos • Visualizaciones de datos a través de múltiples medios y
dispositivos • Vinculación de información estructurada y no estructurada usando
semántica • Nuevas fuentes de datos usando IOT • Capacidades de visualización avanzadas •
Capacidades de enriquecimiento de datos • Tecnologías y conjuntos de herramientas de colaboración
Los almacenes de datos, los data marts y los almacenes de datos operativos (ODS) existentes se están aumentando para llevar la carga de trabajo de Big Data.
Las tecnologías NoSQL permiten el almacenamiento y la consulta de datos no estructurados y semiestructurados.
518 • DMBOK2
El acceso a datos no estructurados solía ocurrir principalmente a través de una interfaz de consulta por lotes que resultó en una ejecución programada lenta y
tiempos de respuesta deficientes. Varias bases de datos NoSQL ahora están disponibles con diseños que abordan limitaciones específicas en este proceso de
adquisición. Las bases de datos distribuidas escalables proporcionan automáticamente capacidades de fragmentación (la capacidad de escalar entre servidores de
forma nativa) para la ejecución de consultas en paralelo. Por supuesto, como con cualquier otra base de datos, la definición estructural y el mapeo de conjuntos de
datos no estructurados siguen siendo en gran medida procesos manuales.
Las capacidades inmediatas de consulta, generación de informes y análisis se pueden satisfacer con las tecnologías en memoria de Big Data que permiten a los
usuarios finales construir consultas similares a SQL para acceder a datos no estructurados. También hay adaptadores a SQL para algunas herramientas que
transmitirán un proceso NoSQL y devolverán una consulta compatible con SQL, con limitaciones y advertencias. Las tecnologías de adaptador pueden permitir que
las herramientas existentes se utilicen para consultas de datos no estructurados.
Los conjuntos de herramientas de criterios de decisión, las herramientas de implementación de procesos y las ofertas de servicios profesionales pueden facilitar y
acelerar el proceso de elección de un conjunto inicial de herramientas. Al igual que cuando se adquieren herramientas de BI, es fundamental evaluar todas las
opciones: construir, comprar o alquilar (aprovisionado como software como servicio). Como se señaló en el Capítulo 11, las herramientas de abastecimiento en la
nube y la experiencia asociada deben sopesarse frente al costo de construir desde cero o implementar productos comprados a los proveedores. También se deben
considerar la actualización continua y los posibles costos de reemplazo.
La alineación con un OLA establecido puede salvar los costos previstos y proporcionar información para establecer tarifas y sanciones convincentes.
por violaciones de términos.
3.1 MPP Tecnologías y arquitectura de nada compartido
Las tecnologías de base de datos sin nada compartido de procesamiento paralelo masivo (MPP) se han convertido en la plataforma estándar para el análisis de
conjuntos de Big Data orientado a la ciencia de datos. En las bases de datos MPP, los datos se dividen (distribuyen lógicamente) en varios servidores de
procesamiento (nodos computacionales), y cada servidor tiene su propia memoria dedicada para procesar los datos localmente. La comunicación entre los servidores
de procesamiento suele estar controlada por un host maestro y se produce a través de una interconexión de red. No se comparte el disco o la contención de la
memoria, de ahí el nombre, "no se comparte nada".
MPP ha evolucionado porque los paradigmas informáticos tradicionales (índices, conjuntos de datos distribuidos, etc.) no proporcionaban tiempos de respuesta
aceptables en tablas masivas. Incluso la más poderosa de las plataformas informáticas (computadora Cray) tardaría muchas horas o incluso días en calcular un
algoritmo complejo en una tabla de un billón de filas.
Considere ahora una serie de servidores de hardware básicos, todos alineados en una fila y controlados a través de un host. A cada uno se le envía parte de la
consulta para que se ejecute en esta tabla segmentada o distribuida de un billón de filas. Si hay, por ejemplo, 1000 servidores de procesamiento, la consulta cambia
de acceder a un billón de filas en una tabla a acceder a 1000 mil millones de tablas de filas. Este tipo de arquitectura informática es linealmente escalable, lo que se
suma al atractivo para los científicos de datos y los usuarios de Big Data que requieren una plataforma escalable para incorporar el crecimiento.
Esta tecnología también habilitó funciones analíticas en la base de datos: la capacidad de ejecutar funciones analíticas (como Kmeans Clustering, Regresión, etc.)
a nivel de procesador. La distribución de la carga de trabajo al nivel del procesador acelera en gran medida las consultas analíticas, lo que impulsa la innovación en
la ciencia de datos.
Un sistema que distribuye automáticamente los datos y paraleliza las cargas de trabajo de consulta en todo el hardware disponible (localizado) es la solución óptima
para el análisis de Big Data.
BIG DATA Y CIENCIA DE DATOS • 51 9
sql
Mapa reducido
Maestro
Servidores
Interconectar
Autobús
Segmento
Servidores
Externo
Fuentes
Figura 102 Arquitectura de dispositivo en columna 95
Los volúmenes de datos están creciendo rápidamente. Las empresas pueden aumentar la capacidad y el rendimiento de sus sistemas con
el tiempo agregando nuevos nodos. MPP facilita la expansión del paralelismo de cientos o miles de núcleos en un grupo de máquinas en
constante crecimiento. Una arquitectura masivamente paralela y sin nada compartido utiliza completamente cada núcleo, con escalabilidad
lineal y mayor rendimiento de procesamiento en grandes conjuntos de datos.
3.2 Bases de datos basadas en archivos distribuidos
Las tecnologías de soluciones basadas en archivos distribuidos, como Hadoop de código abierto, son una forma económica de almacenar
grandes cantidades de datos en diferentes formatos. Hadoop almacena archivos de cualquier tipo: estructurados, semiestructurados y no
estructurados. Con una configuración similar a MPP Sharednothing (una base de MPP para el almacenamiento de archivos), comparte
archivos entre servidores de procesamiento. Es ideal para almacenar datos de forma segura (ya que se realizan muchas copias), pero
presenta desafíos cuando se trata de permitir el acceso a los datos a través de un mecanismo estructurado o analítico (como SQL).
Debido a su costo relativamente bajo, Hadoop se ha convertido en la zona de aterrizaje elegida por muchas organizaciones. Desde Hadoop,
los datos se pueden mover a bases de datos MPP Sharednothing para ejecutar algoritmos en su contra. Algunas organizaciones ejecutan
consultas de ciencia de datos complejas en Hadoop y no les preocupan los tiempos de respuesta en el orden de horas y días (en lugar de
minutos para la arquitectura anterior).
El lenguaje utilizado en las soluciones basadas en archivos se llama MapReduce. Este lenguaje tiene tres pasos principales:
• Mapa: Identificar y obtener los datos a analizar • Barajar:
Combinar los datos según los patrones analíticos deseados
95 Fuente de la imagen: "Greenplum Database 4.0: Critical Mass Innovation", White Paper, agosto de 2010.
520 • DMBOK2
• Reducir: elimine la duplicación o realice la agregación para reducir el tamaño de los datos resultantes
establecer solo lo que se requiere
Estos pasos se pueden combinar en muchas herramientas diferentes de diferentes maneras, tanto en secuencia como en paralelo, para realizar
manipulaciones complejas.
3.3 Algoritmos en base de datos
Un algoritmo en la base de datos utiliza el principio de que cada uno de los procesadores en una plataforma MPP Sharednothing puede ejecutar
consultas de forma independiente, por lo que se podría lograr una nueva forma de procesamiento analítico proporcionando funciones matemáticas y
estadísticas a nivel de nodo informático. Se diseñaron bibliotecas de código abierto de algoritmos en base de datos escalables para aprendizaje
automático, estadísticas y otras tareas analíticas para la ejecución dentro y fuera del núcleo, y para el paralelismo de nada compartido que ofrecen los
motores de bases de datos paralelos modernos, asegurando que el cálculo se realiza cerca de los datos. Al acercar el cómputo a los datos, el tiempo de
cómputo se reduce drásticamente para algoritmos complejos (como agrupamiento de medios K, regresión logística o lineal, prueba U de MannWhitney,
gradiente conjugado, análisis de cohortes, etc.).
3.4 Soluciones de Big Data en la nube
Hay proveedores que brindan almacenamiento en la nube e integración para Big Data, incluidas capacidades analíticas.
Según estándares definidos, los clientes cargan sus datos en un entorno de nube. El proveedor mejora los datos, ya sea como conjuntos de datos
abiertos o proporcionados por otras organizaciones. El cliente puede realizar análisis y ciencia de datos utilizando el conjunto de datos combinado. Una
aplicación utiliza ofertas minoristas como tema de los datos, las combina con datos geográficos y de ventas y ofrece millas aéreas a los clientes que
aceptan que sus datos se utilicen de esta manera.
3.5 Computación Estadística y Lenguajes Gráficos
R es un lenguaje y entorno de secuencias de comandos de código abierto para computación estadística y gráficos. Proporciona una amplia variedad de
técnicas estadísticas, como modelos lineales y no lineales, pruebas estadísticas clásicas, análisis de series temporales, clasificación y agrupación.
Debido a que es un lenguaje de secuencias de comandos, los modelos desarrollados en R se pueden implementar en una variedad de entornos,
diferentes plataformas y desarrollo colaborativo a través de múltiples límites geográficos y organizacionales. El entorno R también puede producir
gráficos con calidad de publicación, incluidos símbolos y fórmulas matemáticos, bajo el control del usuario final.
3.6 Herramientas de visualización de datos
Las herramientas tradicionales de visualización de datos tienen tanto un componente gráfico como de datos. Las herramientas avanzadas de visualización
y descubrimiento utilizan una arquitectura en memoria para permitir que los usuarios interactúen con los datos. Patrones en un gran conjunto de datos
puede ser difícil de reconocer en una pantalla de números. Un patrón visual se puede captar rápidamente cuando se cargan miles de puntos
de datos en una pantalla sofisticada.
Los gráficos de información o infografías son representaciones gráficas estilizadas para una interacción y comprensión efectivas. Marketing
los adoptó para proporcionar un atractivo visual a las presentaciones. Los periodistas, blogueros y profesores encontraron útiles las infografías
para el análisis, la presentación y la distribución de tendencias. Muchos conjuntos de herramientas ahora admiten métodos de visualización
de información como gráficos de radar, gráficos de coordenadas paralelas, gráficos de etiquetas, mapas de calor y mapas de datos. Estos
permiten a los usuarios discernir rápidamente los cambios en los datos a lo largo del tiempo, obtener información sobre los elementos
relacionados y comprender las posibles relaciones de causa y efecto antes de que ocurran los impactos. Estas herramientas tienen varios beneficios.
sobre las herramientas de visualización tradicionales:
• Tipos de análisis y visualización sofisticados, como múltiplos pequeños, líneas de chispa, mapas de calor,
histogramas, gráficos de cascada y gráficos de viñetas •
Cumplimiento integrado de las mejores prácticas de visualización
• Interactividad que permite el descubrimiento visual
4. Técnicas
4.1 Modelado analítico
Varias herramientas de código abierto están disponibles para el desarrollo, así como el procesamiento de datos en la nube para el desarrollo
de modelos, para el proceso de desarrollo visual, para el web scraping y para la optimización de la programación lineal. Para compartir y
ejecutar modelos con otras aplicaciones, busque herramientas que admitan el lenguaje de marcado de modelos predictivos (PMML), un
formato de archivo basado en XML.
El acceso en tiempo real puede resolver muchos problemas de latencia del procesamiento por lotes. Apache Mahout es un proyecto de
código abierto destinado a crear una biblioteca de aprendizaje automático. Mahout está posicionado para automatizar la exploración de Big
Data a través de la extracción de recomendaciones, la clasificación de documentos y la agrupación de elementos. Esta rama de los esfuerzos
de desarrollo pasa por alto las técnicas tradicionales de acceso a datos MapReduce de consulta por lotes. Al aprovechar una interfaz API
directamente en la capa de almacenamiento HDFS, se puede proporcionar una variedad de técnicas de acceso a datos, como SQL,
transmisión de contenido, aprendizaje automático y bibliotecas de gráficos para la visualización de datos.
Los modelos analíticos están asociados a diferentes profundidades de análisis:
• El modelado descriptivo resume o representa las estructuras de datos de manera compacta. Esto
El enfoque no siempre valida una hipótesis causal ni predice resultados. Sin embargo, utiliza algoritmos para definir o
refinar las relaciones entre variables de una manera que podría proporcionar información para dicho análisis.
• El modelado explicativo es la aplicación de modelos estadísticos a los datos para probar hipótesis causales.
sobre construcciones teóricas. Si bien utiliza técnicas similares a la minería de datos y el análisis predictivo,
522 • DMBOK2
su propósito es diferente. No predice resultados; busca hacer coincidir los resultados del modelo solo con los existentes
datos.
La clave del análisis predictivo es aprender con el ejemplo a través del entrenamiento del modelo. El rendimiento de un método de aprendizaje
relaciona sus capacidades predictivas con datos de pruebas independientes. La evaluación guía la elección del aprendizaje y mide la calidad del
modelo elegido. La selección del modelo estima el rendimiento donde la evaluación evalúa el error de generalización en nuevos datos.
Evite el sobreajuste: una situación que ocurre cuando el modelo se entrena con conjuntos de datos no representativos, es demasiado complejo
en relación con sus datos o tiene ruido descrito en lugar de las relaciones subyacentes. Utilice técnicas adicionales, como la validación de Kfold,
para indicar cuándo el entrenamiento ya no genera una mejor generalización.
El error de entrenamiento disminuye constantemente con la complejidad del modelo y puede llegar a cero. Por lo tanto, no es una estimación útil
del error de prueba. Divida aleatoriamente el conjunto de datos en tres partes para formar conjuntos de entrenamiento, prueba y validación. El
conjunto de entrenamiento se usa para ajustar el modelo, el conjunto de validación se usa para predecir el error de selección y el conjunto de
prueba se usa para evaluar el error de generalización del modelo final.
Reutilizar el mismo conjunto de prueba repetidamente puede subestimar el verdadero error de prueba. Idealmente, realice una validación cruzada
dividiendo aleatoriamente el conjunto de datos en un conjunto de Kpliegues o grupos de validación cruzada. Realice un entrenamiento en todos
los conjuntos de datos excepto en uno basado en variables predictoras fuertemente correlacionadas. Pruebe el modelo en la pieza restante y
determine el error de generalización basado en todos los pliegues en K. Se pueden aplicar y realizar varias pruebas estadísticas para evaluar
numéricamente la validez del modelo contextual.
4.2 Modelado de grandes datos
Modelar Big Data es un desafío técnico pero crítico si una organización quiere describir y gobernar sus datos. Se aplican los principios
tradicionales de la arquitectura de datos empresariales; los datos deben integrarse, especificarse y administrarse.
El principal impulsor para modelar físicamente un almacén de datos es habilitar la población de datos para el rendimiento de las consultas.
Este controlador no está en juego para Big Data. Esto no es una excusa para abandonar el proceso de modelado o dejárselo a un desarrollador.
El valor de modelar los datos es que permite a las personas comprender el contenido de los datos. Aplique técnicas probadas de modelado de
datos teniendo en cuenta la variedad de fuentes. Desarrolle el modelo del área temática, al menos de forma resumida, para que pueda
relacionarse con las entidades contextuales adecuadas y colocarse en la hoja de ruta general, como cualquier otro tipo de datos. El desafío es
crear una imagen comprensible y útil a partir de estos grandes conjuntos de datos y por un costo justificable.
Comprender cómo se vinculan los datos entre conjuntos de datos. Para datos de diferente granularidad, evite combinaciones que cuenten
elementos de datos o valores más de una vez; por ejemplo, no combine conjuntos atómicos y agregados.
Muchos de los principios generales de la gestión de datos de almacén se aplican a la gestión de Big Data: garantizar que las fuentes de datos
sean confiables, tener suficientes metadatos para permitir el uso de datos, administrar la calidad de los datos, descubrir cómo integrar datos de
diferentes fuentes y garantizar que los datos están seguros y protegidos. (Consulte los Capítulos 6, 7 y 8). Las diferencias en la implementación
de un entorno de Big Data están conectadas a un conjunto de incógnitas: cómo se usarán los datos, qué datos serán valiosos, cuánto tiempo
deben conservarse.
La velocidad de los datos puede hacer que las personas piensen que no tienen tiempo para implementar controles. Esta es una suposición
peligrosa. Con conjuntos de datos más grandes, la gestión de la ingesta y el inventario de datos en un lago es fundamental para evitar que se
convierta en un pantano.
Es posible que la ingestión no siempre requiera la propiedad o el compromiso de la organización con el conjunto de datos que se está estudiando.
Considere alquilar una plataforma de Big Data por períodos finitos para explorar datos de interés. La exploración puede determinar rápidamente
qué áreas muestran un valor potencial. Haga esto antes de realizar la ingesta en el lago de datos de la organización, el almacén de datos o el
área de preparación de datos; una vez aterrizado, puede ser difícil de quitar.
5.1 Alineación de la estrategia
Cualquier programa de Big Data / Data Science debe estar estratégicamente alineado con los objetivos organizacionales.
Establecer una estrategia de Big Data impulsa las actividades relacionadas con la comunidad de usuarios, la seguridad de los datos, la gestión de
metadatos, incluido el linaje, y la gestión de la calidad de los datos.
La estrategia debe documentar los objetivos, el enfoque y los principios de gobernanza. La capacidad de aprovechar Big Data requiere desarrollar
habilidades y capacidades organizacionales. Utilice la gestión de capacidades para alinear las iniciativas comerciales y de TI y proyecte una hoja
de ruta. Los entregables de la estrategia deben dar cuenta de la gestión de:
• Ciclo de vida de la información
• Metadatos
• Calidad de datos •
Adquisición de datos •
Acceso y seguridad de datos •
Gobernanza de datos • Privacidad de
datos • Aprendizaje y adopción •
Operaciones
Al igual que con cualquier proyecto de desarrollo, la implementación de una iniciativa de Big Data o Data Science debe alinearse con las
necesidades comerciales reales. Evaluar la preparación organizacional en relación con los factores críticos de éxito:
524 • DMBOK2
• Relevancia comercial: ¿Qué tan bien se alinean las iniciativas de Big Data/Data Science y sus casos de uso correspondientes con el
negocio de la empresa? Para tener éxito, deben hacer cumplir firmemente una función comercial.
o proceso.
• Preparación comercial: ¿Está el socio comercial preparado para una entrega incremental a largo plazo? ¿Se han comprometido a
establecer centros de excelencia para sustentar el producto en versiones futuras?
¿Qué tan amplia es la brecha promedio de conocimientos o habilidades dentro de la comunidad objetivo y se puede cruzar en un solo
incremento?
• Viabilidad económica: ¿La solución propuesta ha considerado conservadoramente los aspectos tangibles e intangibles?
¿beneficios? ¿La evaluación de los costos de propiedad ha tenido en cuenta la opción de comprar o arrendar artículos frente a construir
desde cero? • Prototipo: ¿Se puede crear un prototipo de la solución propuesta para un subconjunto de la comunidad de usuarios finales
durante un período de tiempo finito para demostrar el valor propuesto? Las implementaciones big bang pueden causar grandes impactos
económicos y un campo de pruebas puede mitigar estos riesgos de entrega.
Probablemente, las decisiones más desafiantes estarán relacionadas con la adquisición de datos, el desarrollo de plataformas y los recursos.
• Existen muchas fuentes para almacenar datos digitales y no es necesario que todas sean de propiedad y operación internas. Algunos
se pueden adquirir, mientras que otros se pueden arrendar.
• Múltiples herramientas y técnicas están en el mercado; adaptarse a las necesidades generales será un desafío. • Asegurar
personal con habilidades específicas de manera oportuna y retener a los mejores talentos durante una implementación puede requerir la
consideración de alternativas que incluyen servicios profesionales, abastecimiento en la nube o colaboración.
• El tiempo para desarrollar talento interno bien puede exceder la ventana de entrega.
Los empresarios deben estar totalmente comprometidos para obtener los beneficios de los análisis avanzados. Se requiere un programa de
comunicación y educación para lograr esto. Un Centro de Excelencia puede proporcionar capacitación, conjuntos de inicio, mejores prácticas de
diseño, consejos y trucos de fuentes de datos y otras soluciones puntuales o artefactos para ayudar a empoderar a los usuarios comerciales hacia
un modelo de autoservicio. Además de la gestión del conocimiento, este centro puede proporcionar comunicaciones oportunas entre las comunidades
de desarrolladores, diseñadores, analistas y consumidores de datos.
Al igual que con DW/BI, una implementación de Big Data reunirá una serie de roles multifuncionales clave, que incluyen:
• Arquitecto de plataformas de Big Data: hardware, sistemas operativos, sistemas de archivos y servicios. • Ingestion
Architect: análisis de datos, sistemas de registro, modelado de datos y mapeo de datos. proporciona o
admite el mapeo de fuentes al clúster de Hadoop para consultas y análisis. • Especialista en
metadatos: interfaces de metadatos, arquitectura de metadatos y contenidos. • Líder de diseño analítico:
Diseño analítico del usuario final, implementación de guías de mejores prácticas en conjuntos de herramientas relacionados y facilitación
del conjunto de resultados del usuario final.
• Científico de datos: Brinda consultoría de arquitectura y diseño de modelos basada en el conocimiento teórico de
estadística y computabilidad, entrega de herramientas adecuadas y aplicación técnica a requerimientos funcionales.
6. Gobernanza de Big Data y Data Science
Big Data, como otros datos, requiere gobernanza. Los procesos de abastecimiento, análisis de fuentes, ingestión, enriquecimiento y publicación
requieren controles comerciales y técnicos, que aborden cuestiones como:
• Abastecimiento: qué obtener, cuándo obtenerlo, cuál es la mejor fuente de datos para un estudio en particular • Compartir: qué
acuerdos y contratos de intercambio de datos celebrar, términos y condiciones tanto dentro como fuera de la organización • Metadatos: qué
significan los datos en el lado de la fuente, cómo interpretar los resultados en el lado de la salida • Enriquecimiento: si enriquecer los
datos, cómo enriquecer los datos y los beneficios de enriquecer los datos • Acceso: qué publicar, a quién, cómo y cuándo
Una vista empresarial de los datos debe impulsar las decisiones sobre el manejo de datos.
6.1 Gestión de Canales de Visualización
Un factor crítico de éxito en la implementación de un enfoque de ciencia de datos es la alineación de las herramientas de visualización adecuadas para
la comunidad de usuarios. Según el tamaño y la naturaleza de la organización, es probable que se apliquen muchas herramientas de visualización
diferentes en una variedad de procesos. Asegúrese de que los usuarios comprendan la complejidad relativa de las herramientas de visualización. Los
usuarios sofisticados tendrán demandas cada vez más complejas.
Será necesaria la coordinación entre la arquitectura empresarial, la gestión de la cartera y los equipos de mantenimiento para controlar los canales de
visualización dentro y a través de la cartera. Tenga en cuenta que cambiar los proveedores de datos o los criterios de selección probablemente tendrá
impactos posteriores en los elementos disponibles para la visualización, lo que puede afectar la efectividad de las herramientas.
6.2 Estándares de visualización y ciencia de datos
Es una mejor práctica establecer una comunidad que defina y publique estándares y pautas de visualización y revise artefactos dentro de un método
de entrega específico; esto es particularmente vital para el contenido orientado al cliente y normativo. Los estándares pueden incluir:
• Estándares de herramientas por paradigma analítico, comunidad de usuarios, área temática •
Solicitudes de nuevos datos • Estándar de proceso de conjuntos de datos
526 • DMBOK2
• Procesos de presentación neutral y experta para evitar resultados sesgados y garantizar que todos los elementos
incluidos se han hecho de manera justa y consistente, incluyendo:
o Inclusión y exclusión de datos
o Supuestos en los modelos o Validez
estadística de los resultados o Validez
de la interpretación de los resultados o Métodos
apropiados aplicados
6.3 Seguridad de los datos
Tener un proceso confiable para proteger los datos es en sí mismo un activo organizacional. Se deben establecer y monitorear políticas
para manejar y asegurar Big Data. Estas políticas deben explicar cómo evitar el uso indebido de los datos personales y protegerlos
durante todo su ciclo de vida.
Proporcione de forma segura los niveles adecuados de datos para el personal autorizado y haga que los datos de suscripción sean
accesibles de acuerdo con los niveles acordados. Alinee los servicios con las comunidades de usuarios para que se puedan crear
servicios especiales para proporcionar datos privados para aquellas comunidades a las que se les permite ingerirlos y enmascarar los
datos para otros. A menudo, las organizaciones crean políticas para el acceso a la información que no deben violarse (como no
acceder por nombre, dirección o número de teléfono). Para proteger la información que es altamente confidencial (número de seguro
social, números de tarjetas de crédito, etc.), los datos se almacenarán mediante técnicas de encriptación que ofuscan la información.
Se puede elegir un cifrado que, por ejemplo, tenga el mismo "contenido" cuando se cifra, de modo que los patrones puedan quedar
expuestos sin conocer los valores reales.
La recombinación mide la capacidad de reconstituir datos confidenciales o privados. Esta capacidad debe gestionarse como parte de
la práctica de seguridad de Big Data. Los resultados del análisis pueden violar la privacidad, aunque los elementos de datos reales
solo se pueden inferir. Comprender los resultados en el nivel de gestión de metadatos es fundamental para evitar esta y otras posibles
violaciones de seguridad. Esto requiere conocer el consumo previsto o el análisis a realizar y por qué rol. Algunas personas de
confianza dentro de la organización tendrán la capacidad de leer estos datos cuando sea necesario, pero no todos, y ciertamente no
para un análisis profundo. (Consulte los capítulos 2 y 7).
6.4 Metadatos
Como parte de una iniciativa de Big Data, una organización reunirá conjuntos de datos que se crearon utilizando diferentes enfoques y
estándares. La integración de tales datos es un desafío. Los metadatos relacionados con estos conjuntos de datos son fundamentales
para su uso exitoso. Los metadatos deben administrarse cuidadosamente como parte de la ingestión de datos, o el lago de datos se
convertirá rápidamente en un pantano de datos. La comunidad de usuarios debe tener herramientas que les permitan crear una lista
maestra de conjuntos de datos con metadatos que caracterice la estructura, el contenido y la calidad de los datos, incluida la fuente y
el linaje de los datos y la definición y los usos previstos de las entidades y los datos. elementos. Los metadatos técnicos se pueden
recopilar de una variedad de herramientas de Big Data que incluyen capas de almacenamiento de datos, integración de datos, MDM y
incluso los sistemas de archivos de origen. Es necesario considerar las fuentes en tiempo real frente a los datos en reposo frente a los elementos
de datos computacionales para completar el linaje del lado de la fuente.
6.5 Calidad de los datos
La calidad de los datos es una medida de la desviación de un resultado esperado: cuanto menor sea la diferencia, mejor cumplirán los datos con
las expectativas y mayor será la calidad. En un entorno diseñado, los estándares de calidad deberían ser fáciles de definir (aunque la práctica
demuestra que no lo son o que muchas organizaciones no se toman el tiempo para definirlos). Algunas personas han planteado la cuestión de si
la calidad de los datos es importante para Big Data. El sentido común dice que sí. Para que el análisis sea confiable, los datos subyacentes deben
ser confiables. En los proyectos de Big Data, puede parecer muy difícil determinar la calidad de los datos, pero es necesario hacer un esfuerzo
para evaluar la calidad para tener confianza en el análisis. Esto se puede hacer a través de una evaluación inicial, que es necesaria para
comprender los datos y, a través de ella, la identificación de mediciones para instancias posteriores del conjunto de datos. La evaluación de la
calidad de los datos producirá Metadatos valiosos que serán la entrada necesaria para cualquier esfuerzo por integrar los datos.
Considere que las organizaciones de Big Data más maduras escanean las fuentes de entrada de datos utilizando conjuntos de herramientas de
calidad de datos para comprender la información contenida en ellas. Los conjuntos de herramientas de calidad de datos más avanzados ofrecen
una funcionalidad que permite a una organización probar suposiciones y generar conocimiento sobre sus datos. Por ejemplo:
• Descubrimiento: dónde reside la información dentro del conjunto de datos •
Clasificación: qué tipos de información están presentes en función de patrones estandarizados • Perfilado: cómo se
completan y estructuran los datos • Mapeo: qué otros conjuntos de datos pueden coincidir con estos valores
Al igual que en DW/BI, es tentador poner la evaluación de la calidad de los datos en último lugar. Sin embargo, sin él, puede ser difícil saber qué
representa Big Data o cómo hacer conexiones entre conjuntos de datos. La integración será necesaria, y la probabilidad de que las fuentes de
datos se aprovisionen con estructuras y elementos idénticos es casi nula.
Esto significa, por ejemplo, que los códigos y otros posibles datos de vinculación probablemente variarán de un proveedor de datos a otro. Sin una
evaluación inicial, tales condiciones pasarán desapercibidas hasta que se exprese una necesidad analítica que intente fusionar o combinar esos
proveedores.
6.6 Métricas
Las métricas son vitales para cualquier proceso de gestión; no solo cuantifican la actividad, sino que pueden definir la variación
entre lo que se observa y lo que se desea.
6.6.1 Métricas de uso técnico
Muchas de las herramientas de Big Data ofrecen capacidades de informes de administrador perspicaces que interactúan directamente con los
contenidos consultados por la comunidad de usuarios. El análisis de uso técnico busca puntos calientes de datos (más frecuentemente
528 • DMBOK2
datos accedidos) para administrar la distribución de datos y preservar el rendimiento. Las tasas de crecimiento también alimentan la
planificación de la capacidad.
6.6.2 Métricas de carga y exploración
Las métricas de carga y escaneo definen la tasa de ingesta y la interacción con la comunidad de usuarios. A medida que se adquiere cada
nueva fuente de datos, se espera que las métricas de carga aumenten y luego se nivelen a medida que esa fuente se ingiere por completo.
Los feeds en tiempo real se pueden servir a través de consultas de servicio, pero también pueden aparecer a medida que se procesan los extractos
programados; para estos feeds, espere un aumento constante en la carga de datos.
Es probable que las capas de la aplicación proporcionen las mejores métricas de uso de datos de los registros de ejecución. Supervise el
consumo o el acceso a través de los metadatos disponibles, que pueden guiar el análisis de uso al mostrar los planes de ejecución de
consultas que se han producido con mayor frecuencia.
Las métricas de escaneo deben combinarse con cualquier procesamiento de consultas que pueda ocurrir fuera del procesamiento analítico
en sí. Las herramientas administrativas deberían poder proporcionar este nivel de informes, así como un servicio general.
salud.
6.6.3 Aprendizajes e historias
Para mostrar valor, el programa Big Data / Data Science debe medir resultados tangibles que justifiquen el costo de desarrollar soluciones
y administrar cambios en los procesos. Las métricas pueden incluir la cuantificación de los beneficios, la prevención o evitación de costos,
así como el tiempo transcurrido entre el inicio y los beneficios obtenidos. Común
las medidas incluyen
• Recuentos y precisión de los modelos y patrones desarrollados •
Realización de ingresos a partir de oportunidades identificadas • Reducción
de costos al evitar amenazas identificadas
A veces, los resultados de los análisis cuentan historias que pueden conducir a la redirección, revitalización y nuevas oportunidades de la
organización. Una medida puede ser un recuento de nuevos proyectos e iniciativas generados por marketing.
y altos ejecutivos.
Abate, Robert, Peter Aiken y Joseph Burke. Integración de aplicaciones empresariales utilizando una arquitectura basada en servicios.
John Wiley and Sons, 1997. Imprimir.
Arturo, Lisa. Big Data Marketing: Involucre a sus clientes de manera más efectiva y genere valor. Wiley, 2013. Imprimir.
Barlow, Mike. Análisis de Big Data en tiempo real: arquitectura emergente. O'Reilly Media, 2013. Kindle.
Davenport, Thomas H. "Más allá de la caja negra en análisis y cognición". DataInformed (sitio web), 27 de febrero de 2017. http://bit.ly/2sq8uG0 Web.
Davenport, Thomas H. Big Data en el trabajo: disipar los mitos, descubrir las oportunidades. Harvard Business Review Press, 2014. Imprimir.
Servicios educativos de EMC, ed. Ciencia de datos y análisis de Big Data: descubrimiento, análisis, visualización y presentación de datos. Wiley, 2015.
Imprimir.
Oficina Ejecutiva del Presidente, Comité de Tecnología del Consejo Nacional de Ciencia y Tecnología. Preparándose para el futuro de la inteligencia
artificial. Octubre de 2016. http://bit.ly/2j3XA4k.
Inmon, WH y Dan Linstedt. Arquitectura de datos: un manual básico para el científico de datos: Big Data, almacén de datos y bóveda de datos. 1ra
Edición. Morgan Kaufmann, 2014.
Jacobs, Adán. “Patologías del Big Data”. AMCQUEU, Volumen 7, Número 6. 6 de julio de 2009. http://bit.ly/1vOqd80. Web
Janssens, Jeroen. Ciencia de datos en la línea de comandos: afrontar el futuro con herramientas probadas en el tiempo. O'Reilly Media, 2014.
Imprimir.
Cocina, Rob. La Revolución de los Datos: Big Data, Open Data, Infraestructuras de Datos y sus Consecuencias. SAGE Publications Ltd,
2014. Imprimir.
Krishnan, Krish. Almacenamiento de datos en la era de Big Data. Morgan Kaufmann, 2013. Imprimir. La serie de Morgan Kaufmann sobre inteligencia
empresarial.
Lake, Peter y Robert Drake. Gestión de sistemas de información en la era de Big Data. Springer, 2015. Imprimir. Procesamiento Avanzado de
Información y Conocimiento.
Lago, Pedro. Una guía para el manejo de datos con Hadoop: una exploración de Hadoop, Hive, Pig, Sqoop y Flume. Peter Lake, 2015. Kindle. Procesamiento
Avanzado de Información y Conocimiento.
Laney, Doug. "Gestión de datos 3D: control del volumen, la velocidad y la variedad de datos". El Grupo Meta [Gartner]. 6 de febrero de 2001. http://
gtnr.it/1bKflKH.
Loshin, David. Big Data Analytics: desde la planificación estratégica hasta la integración empresarial con herramientas, técnicas, NoSQL y Graph. Morgan
Lublinsky, Boris, Kevin T. Smith, Alexey Yakubovich. Soluciones profesionales de Hadoop. Wrox, 2013. Imprimir.
Luisi, James. Arquitectura empresarial pragmática: estrategias para transformar los sistemas de información en la era de Big Data.
Morgan Kaufmann, 2014. Imprimir.
Marz, Nathan y James Warren. Big Data: Principios y mejores prácticas de sistemas de datos escalables en tiempo real. Publicaciones de Manning,
2014. Imprimir.
McCandless, David. La información es hermosa. Collins, 2012.
Provost, Foster y Tom Fawcett. Ciencia de datos para empresas: lo que necesita saber sobre la minería de datos y el pensamiento analítico de datos.
O'Reilly Media, 2013. Imprimir.
Salminen, Joni y Valtteri Kaartemo, eds. Big Data: definiciones, lógicas comerciales y mejores prácticas para aplicar en su negocio. Amazon Digital
Services, Inc., 2014. Kindle. Libros para Gerentes Libro 2.
Sathi, Arvind. Big Data Analytics: tecnologías disruptivas para cambiar el juego. Mc Press, 2013. Imprimir.
Sawant, Nitin y Himanshu Shah. Preguntas y respuestas sobre la arquitectura de aplicaciones de big data: un problema: enfoque de solución. Prensa, 2013.
Imprimir. Voz de Experto en Big Data.
Slovic, Scott, Paul Slovic, eds. Números y nervios: información, emoción y significado en un mundo de datos. Prensa de la Universidad Estatal de Oregón,
2015. Imprimir.
530 • DMBOK2
Star Bird, Michael. Significado de los datos: estadísticas aclaradas (Los grandes cursos, partes 1 y 2). La Compañía Docente, 2006.
Imprimir.
Tufte, Edward R. La presentación visual de información cuantitativa. 2ª ed. Gráficos Pr., 2001. Imprimir.
Van der Lans, Rick. Virtualización de datos para sistemas de inteligencia comercial: revolucionando la integración de datos para
almacenes de datos. Morgan Kaufmann, 2012. Imprimir. La serie de Morgan Kaufmann sobre inteligencia empresarial.
van Rijmenam, Mark. Piense en grande: desarrollo de una estrategia exitosa de Big Data para su empresa. AMACOM, 2014. Imprimir.
CAPÍTULO 1 5
Evaluación de la madurez de la gestión de datos
1. Introducción
C
Apability Maturity Assessment (CMA) es un enfoque para la mejora de procesos basado en un marco:
un modelo de madurez de la capacidad (CMM), que describe cómo evolucionan las características de un proceso a partir del anuncio
hoc al óptimo. El concepto CMA surgió de los esfuerzos del Departamento de Defensa de los Estados Unidos para establecer
criterios a través de los cuales evaluar a los contratistas de software. A mediados de la década de 1980, el Instituto de Ingeniería de Software de
la Universidad CarnegieMellon publicó el Modelo de Madurez de Capacidad para Software. Si bien se aplicaron por primera vez al desarrollo de
software, las CMM se han desarrollado para una variedad de otros campos, incluidos los datos
administración.
Los modelos de madurez se definen en términos de una progresión a través de niveles que describen las características del proceso. Cuando
una organización obtiene una comprensión de las características del proceso, puede evaluar su nivel de madurez y poner en marcha un plan
para mejorar sus capacidades. También puede medir la mejora y compararse con competidores o socios, guiado por los niveles del modelo. Con
cada nuevo nivel, la ejecución del proceso se vuelve más consistente, predecible y confiable. Los procesos mejoran a medida que adquieren
características de los niveles. La progresión ocurre en un orden establecido. No se puede saltar ningún nivel. Los niveles comúnmente incluyen:
96
• Nivel 0: Ausencia de capacidad • Nivel 1:
Inicial o Ad Hoc: El éxito depende de la competencia de las personas • Nivel 2: Repetible: Existe una
disciplina de proceso mínima
• Nivel 3: Definido: Se establecen y utilizan estándares
• Nivel 4: Gestionado: Los procesos están cuantificados y controlados • Nivel 5:
Optimizado: Los objetivos de mejora de procesos están cuantificados
Dentro de cada nivel, los criterios se describen a través de las características del proceso. Por ejemplo, un modelo de madurez puede incluir
criterios relacionados con la forma en que se ejecutan los procesos, incluido el nivel de automatización de esos procesos. Puede centrarse en
políticas y controles, así como en detalles del proceso.
96Adaptado de Select Business Solutions, "¿Qué es el modelo de madurez de la capacidad?" http://bit.ly/IFMJI8 (Consultado el
10112016).
531
532 • DMBOK2
Tal evaluación ayuda a identificar qué funciona bien, qué no funciona bien y dónde tiene brechas una organización. Con base en los
hallazgos, la organización puede desarrollar una hoja de ruta para apuntar a:
• Oportunidades de mejora de alto valor relacionadas con procesos, métodos, recursos y automatización • Capacidades
que se alinean con la estrategia comercial • Procesos de gobierno para la evaluación periódica del progreso organizacional
en función de las características en el
modelo
Se puede usar una evaluación de madurez de la gestión de datos (DMMA) para evaluar la gestión de datos en general, o se puede usar
para centrarse en una sola área de conocimiento o incluso en un solo proceso. Cualquiera que sea el enfoque, un DMMA puede ayudar
a cerrar la brecha entre las perspectivas comerciales y de TI sobre la salud y la eficacia de las prácticas de gestión de datos. Un DMMA
proporciona un lenguaje común para representar cómo se ve el progreso en las áreas de conocimiento de gestión de datos y ofrece un
camino hacia la mejora basado en etapas, que se puede adaptar a las prioridades estratégicas de una organización.97 Por lo tanto, se
puede usar tanto para establecer como para medir objetivos de la organización, así como para comparar la propia organización con
otras organizaciones o puntos de referencia de la industria.
Antes de comenzar cualquier DMMA, una organización debe establecer una comprensión básica de sus capacidades, activos, objetivos
y prioridades del estado actual. Se requiere un cierto nivel de madurez organizacional para realizar la evaluación en primer lugar, así
como para responder de manera efectiva a los resultados de la evaluación al establecer objetivos, establecer una hoja de ruta y
monitorear el progreso.
Las organizaciones realizan evaluaciones de la madurez de la capacidad por varias razones:
• Regulación: La supervisión regulatoria requiere niveles mínimos de madurez en la gestión de datos. • Gobierno de
datos: la función de gobierno de datos requiere una evaluación de madurez para fines de planificación y cumplimiento. •
Preparación organizacional para la mejora de procesos: una organización reconoce la necesidad de mejorar sus
prácticas y comienza evaluando su estado actual. Por ejemplo, se compromete a administrar datos maestros y necesita evaluar
su preparación para implementar procesos y herramientas de MDM. • Cambio organizacional: un cambio organizacional,
como una fusión, presenta la gestión de datos
retos Un DMMA proporciona información para la planificación para enfrentar estos desafíos.
• Nueva tecnología: Los avances en tecnología ofrecen nuevas formas de administrar y usar datos. Él
La organización quiere comprender la probabilidad de una adopción exitosa. •
Problemas de gestión de datos: es necesario abordar los problemas de calidad de los datos u otros problemas de gestión de datos.
desafíos y la organización quiere establecer una línea de base de su estado actual para tomar mejores decisiones
sobre cómo implementar el cambio.
97 http://bit.ly/1Vev9xx 18 de julio de 2015.
EVALUACIÓN DE LA MADUREZ DE LA GESTIÓN DE DATOS • 533
Evaluación de la madurez de la gestión de datos
Definición: Un método para clasificar las prácticas para el manejo de datos dentro de una organización para
caracterizar el estado actual de la gestión de datos y su impacto en la organización.
Metas:
1. Para descubrir y evaluar exhaustivamente las actividades críticas de gestión de datos en toda una organización.
2. Educar a las partes interesadas sobre conceptos, principios y prácticas de gestión de datos, así como identificar
sus roles y responsabilidades en un contexto más amplio como creadores y administradores de datos.
3. Establecer o mejorar un programa sostenible de gestión de datos en toda la empresa en apoyo de las operaciones
y objetivos estratégicos.
Negocio
Conductores
Entradas: Actividades: Entregables:

• •
Estrategia de negocios & 1. Planificar las actividades de evaluación (P) Calificaciones y rangos
Metas •
1. Establecer el alcance y el enfoque Línea base de vencimiento
• Cultura y 2. Planificar las comunicaciones • Evaluación de preparación
tolerancia al riesgo • Evaluación de riesgos
2. Realizar evaluación de madurez (C)
• 1. Reunir información •
Madurez Capacidad de dotación de personal
Marcos y 2. Realizar la evaluación 3. • Inversión y

DAMADMBOK Interpretar los resultados resultados Opciones
• 3. Desarrollar recomendaciones (D) • Recomendaciones
Políticas, procesos,
estándares, modelos 4. Crear un programa específico para • Mapa vial
operativos •
mejoras (P) Sesiones informativas ejecutivas
• Puntos de referencia 5. Reevaluar la madurez (C)
Proveedores: Participantes: Consumidores:

• Ejecutivos • CDO/CIO • Ejecutivos
• Administradores de datos • •
Administración de Empresas Auditoría / Cumplimiento
• Ejecutivos de MD • Ejecutivos de DM y órganos de gobierno de datos •
Reguladores
• • Oficina de Gobierno de Datos • Administradores de datos
Expertos en la materia
• • • Dato de governancia
Empleados Evaluadores de madurez
• Cuerpos
Empleados
• Organizativo
Grupo de Efectividad
Técnico
Conductores
Técnicas: Herramientas: Métrica:

• • • DMMA Local y Total
Gestión de datos Madurez de la gestión de datos
Marcos de madurez Marcos Calificaciones
Selección • Plan de Comunicaciones • Utilización de recursos

• Herramientas de colaboración •
• Compromiso con la comunidad • Exposición al
DAMADMBOK • Gestión del Conocimiento y riesgo • Gestión de gastos
• •
Puntos de referencia existentes Repositorios de metadatos Entradas a DMMA
•
Herramientas de creación de perfiles de datos • Tasa de cambio
Figura 103 Diagrama de contexto: evaluación de la madurez de la gestión de datos
534 • DMBOK2
El objetivo principal de una evaluación de la capacidad de gestión de datos es evaluar el estado actual de las actividades críticas de gestión de
datos para planificar la mejora. La evaluación coloca a la organización en la escala de madurez al aclarar fortalezas y debilidades específicas.
Ayuda a la organización a identificar, priorizar e implementar oportunidades de mejora.
Al cumplir con su objetivo principal, una DMMA puede tener un impacto positivo en la cultura. Ayuda:
• Educar a las partes interesadas sobre conceptos, principios y prácticas de gestión de datos • Aclarar las
funciones y responsabilidades de las partes interesadas en relación con los datos de la organización •
Resaltar la necesidad de gestionar los datos como un activo crítico • Ampliar el reconocimiento de las
actividades de gestión de datos en toda la organización • Contribuir a mejorar la colaboración necesarios
para un gobierno de datos eficaz
Según los resultados de la evaluación, una organización puede mejorar su programa de gestión de datos para que respalde la dirección
operativa y estratégica de la organización. Por lo general, los programas de gestión de datos se desarrollan en silos organizacionales. Rara vez
comienzan con una vista empresarial de los datos. Un DMMA puede equipar a la organización para desarrollar una visión cohesiva que respalde
la estrategia organizacional general. Un DMMA permite a la organización aclarar prioridades, cristalizar objetivos y desarrollar un plan integrado
para la mejora.
1.3.1 Niveles de evaluación y características
Los CMM suelen definir cinco o seis niveles de madurez, cada uno con sus propias características que van desde inexistentes o ad hoc hasta
optimizados o de alto rendimiento. Consulte la Figura 104 para ver una visualización de muestra.
El siguiente es un resumen genérico de estados macro de madurez de gestión de datos. Una evaluación detallada incluiría criterios para
subcategorías como estrategia, política, estándares, definición de funciones, etc. dentro de cada una de las áreas de conocimiento.
• Nivel 0: sin capacidad: sin prácticas organizadas de gestión de datos ni procesos empresariales formales para la gestión de datos.
Muy pocas organizaciones existen en un Nivel 0. Este nivel se reconoce en un modelo de madurez para fines de definición.
• Nivel 1 Inicial / Ad Hoc: Gestión de datos de uso general utilizando un conjunto de herramientas limitado, con poca o ninguna
gobernanza. El manejo de datos depende en gran medida de unos pocos expertos. Los roles y responsabilidades se definen
dentro de los silos. Cada propietario de datos recibe, genera y envía datos de forma autónoma. Los controles, si existen, se aplican
de manera inconsistente. Las soluciones para la gestión de datos son limitadas. Los problemas de calidad de los datos son
generalizados pero no se abordan. Los soportes de infraestructura están a nivel de unidad de negocio.
• Altamente predecible
procesos
•Reducción del riesgo
• Planificación y gobierno
•Bien entendido
centralizados • Gestión de
• Datos vistos como un riesgos relacionados con los métricas para gestionar la
facilitador organizacional datos • Métricas de rendimiento calidad de los datos y la

• Procesos y herramientas de la gestión de datos • Medibles calidad del proceso
• emergentes escalables; reducción de
gobernanza procesos manuales
• Pequeño o no
•Introducción de un
gobernanza • conjunto de herramientas consistente
Los resultados del proceso,
Conjunto de herramientas
• Algunos roles y
mejoras en la calidad Nivel 5
limitado • Roles definidos dentro incluida la calidad de los de los datos
de silos • Controles aplicados de
procesos definidos • datos, son más predecibles optimizado
Creciente conciencia del Nivel 4
manera inconsistente, si es que se
impacto de los problemas
aplican Administrado
de calidad de los datos
Nivel 3
•Problemas de calidad de
datos no abordados Nivel 2 definido
Nivel 1 repetible
Inicial / Ad Hoc
Figura 104 Ejemplo de modelo de madurez de gestión de datos
Los criterios de evaluación pueden incluir la presencia de cualquier control de proceso, como el registro de problemas de calidad de datos.
• Nivel 2 Repetible: Aparición de herramientas consistentes y definición de roles para apoyar la ejecución del proceso. En
Nivel 2, la organización comienza a utilizar herramientas centralizadas y proporciona más supervisión para la gestión de
datos. Los roles están definidos y los procesos no dependen únicamente de expertos específicos. Hay conciencia organizacional
de los problemas y conceptos de calidad de datos. Se empiezan a reconocer los conceptos de Datos Maestros y de Referencia.
Los criterios de evaluación pueden incluir la definición de roles formales en artefactos como descripciones de puestos, la existencia de
documentación de procesos y la capacidad de aprovechar los conjuntos de herramientas.
• Definición de nivel 3: capacidad emergente de gestión de datos. El nivel 3 ve la introducción y
institucionalización de procesos de gestión de datos escalables y una visión de DM como facilitador organizacional. Las
características incluyen la replicación de datos en toda una organización con algunos controles implementados y un aumento
general en la calidad general de los datos, junto con una definición y administración de políticas coordinadas. Una definición
más formal del proceso conduce a una reducción significativa de la intervención manual.
Esto, junto con un proceso de diseño centralizado, significa que los resultados del proceso son más predecibles.
Los criterios de evaluación pueden incluir la existencia de políticas de gestión de datos, el uso de procesos escalables y la coherencia de los
modelos de datos y los controles del sistema.
• Nivel 4 Gestionado: El conocimiento institucional obtenido del crecimiento en los Niveles 13 permite a la organización predecir resultados
al abordar nuevos proyectos y tareas y comenzar a gestionar los riesgos relacionados con los datos. La gestión de datos incluye
métricas de rendimiento. Las características del Nivel 4 incluyen herramientas estandarizadas para la gestión de datos desde el
escritorio hasta la infraestructura, junto con una función de gobierno y planificación centralizada bien formada. Las expresiones de
este nivel son un aumento medible en la calidad de los datos y las capacidades de toda la organización, como las auditorías de
datos de extremo a extremo.
536 • DMBOK2
Los criterios de evaluación pueden incluir métricas relacionadas con el éxito del proyecto, métricas operativas para sistemas y métricas de calidad
de datos.
• Nivel 5: Optimización: cuando se optimizan las prácticas de gestión de datos, son altamente predecibles,
debido a la automatización de procesos y la gestión del cambio tecnológico. Las organizaciones en este nivel de madurez se enfocan
en la mejora continua. En el Nivel 5, las herramientas permiten ver datos en todos los procesos. La proliferación de datos se controla
para evitar la duplicación innecesaria. Las métricas bien entendidas se utilizan para administrar y medir la calidad de los datos y los
procesos.
Los criterios de evaluación pueden incluir artefactos de gestión de cambios y métricas sobre la mejora de procesos.
1.3.2 Criterios de evaluación
Cada nivel de capacidad tendrá criterios de evaluación específicos relacionados con los procesos que se evalúan. Por ejemplo, si se evalúa la
madurez de la función de modelado de datos, el nivel 1 puede preguntar si existe una práctica de modelado de datos y a cuántos sistemas se
extiende; el nivel 2 puede preguntar si se ha definido un enfoque para el modelado de datos empresariales; el nivel 3 preguntará el grado en que se
ha implementado el enfoque; el nivel 4 preguntará si los estándares de modelado se han aplicado efectivamente; y el nivel 5 preguntará sobre los
procesos establecidos para mejorar las prácticas de modelado. (Consulte el Capítulo 5.)
En cualquier nivel, los criterios de evaluación se evaluarán a lo largo de una escala, como 1: no iniciado, 2: en proceso, 3: funcional, 4: efectivo, que
muestra el progreso dentro de ese nivel y el movimiento hacia el siguiente nivel. Las puntuaciones se pueden combinar o mostrar visualmente para
permitir la comprensión de la variación entre el estado actual y el deseado.
Al evaluar utilizando un modelo que se puede asignar a un Área de conocimiento de gestión de datos DAMADMBOK, los criterios se pueden
formular en función de las categorías en el Diagrama de contexto:
• Actividad: ¿Hasta qué punto está la actividad o el proceso en su lugar? ¿Están definidos los criterios para una ejecución eficaz y
eficiente? ¿Qué tan bien definida y ejecutada está la actividad? ¿Se producen resultados de mejores prácticas?
• Herramientas: ¿Hasta qué punto la actividad está automatizada y respaldada por un conjunto común de herramientas? ¿Se
proporciona capacitación en herramientas dentro de funciones y responsabilidades específicas? ¿Están disponibles las
herramientas cuando y donde se necesitan? ¿Están configurados de manera óptima para proporcionar los resultados más efectivos
y eficientes? ¿Hasta qué punto existe una planificación tecnológica a largo plazo para adaptarse a las futuras capacidades estatales?
• Estándares: ¿Hasta qué punto la actividad está respaldada por un conjunto común de estándares? Que tan bien
¿Están documentadas las normas? ¿Los estándares se hacen cumplir y están respaldados por la gobernanza y la gestión del
cambio?
• Personas y recursos: ¿En qué medida cuenta la organización con personal para llevar a cabo la actividad? Qué
¿Se necesitan habilidades, capacitación y conocimientos específicos para ejecutar la actividad? ¿Qué tan bien están definidos los
roles y responsabilidades?
La Figura 105 ilustra una forma de presentar un resumen visual de los resultados de un DMMA. Para cada una de las
capacidades (Gobierno, Arquitectura, etc.), el anillo exterior de la pantalla muestra el nivel de capacidad que la organización
ha determinado que necesita para competir con éxito. El anillo interior muestra el nivel de capacidad determinado a través
de la evaluación. Las áreas donde la distancia entre los dos anillos es mayor representan los mayores riesgos para la
organización. Dicho informe puede ayudar a establecer prioridades. También se puede utilizar para medir el progreso a lo largo del tiempo.
Tabla de evaluación de DMM
Rango deseado Posición actual
Gobernanza 5
DQ Arquitectura
4
metadatos 2 Modelado
DW&BI Almacenamiento y operaciones
R&MD Seguridad
CORRIENTE CONTINUA DII
Figura 105 Ejemplo de una visualización de evaluación de madurez de gestión de datos
1.3.3 Marcos DMMA existentes98
Un marco de evaluación de la madurez de la gestión de datos se segmenta en temas discretos de gestión de datos.
El enfoque y el contenido del marco varían dependiendo de si tienen un enfoque general o específico de la industria.
Sin embargo, la mayoría aborda temas que se pueden asignar a las áreas de conocimiento de DAMADMBOK. Los siguientes
ejemplos pretenden ilustrar la gama de modelos de madurez de capacidad que se han desarrollado en el espacio de gestión
de datos. Muchos proveedores han desarrollado sus propios modelos. Las organizaciones deben evaluar varios modelos
antes de elegir un proveedor o antes de desarrollar su propio marco.
98 Para obtener información adicional y una revisión de los CMM de gestión de datos existentes, consulte: Alan McSweeney, Review of
Data Management Maturity Models, SlideShare.net, publicado el 23 de octubre de 2013. http://bit.ly/2spTCY9. Jeff Gorball, Introducción a
los modelos de madurez de gestión de datos, SlideShare.net, publicado el 01082016. McSweeney incluye el DAMADMBOK como uno
de sus modelos de madurez, aunque el DMBOK no está estructurado como tal.
538 • DMBOK2
1.3.3.1 Modelo de madurez de gestión de datos (DMM) de CMMI
El CMMI (Capability Maturity Model Institute) ha desarrollado el CMMIDMM (Data Management Maturity
Modelo) que proporciona criterios de evaluación para las siguientes áreas de gestión de datos:
• Estrategia de gestión de datos
• Dato de governancia
• Calidad de los datos
• Plataforma y Arquitectura
• Operaciones de datos •
Procesos de soporte
Dentro de cada uno de estos procesos, el modelo identifica subprocesos para evaluación. Por ejemplo, la sección Calidad de los datos da
cuenta de la estrategia de calidad de los datos y la evaluación, creación de perfiles y limpieza de la calidad de los datos. El modelo también
da cuenta de la relación entre las áreas de gestión de datos. Por ejemplo, la necesidad de alineación de las partes interesadas y la relación
entre los procesos comerciales y la gestión de la calidad de los datos.99
1.3.3.2 Consejo EDM DCAM100
El Enterprise Data Management Council, una organización de defensa de la industria de servicios financieros con sede en los Estados Unidos,
ha desarrollado el DCAM (Modelo de evaluación de la capacidad de gestión de datos). Como resultado de un esfuerzo impulsado por los
miembros para obtener un consenso sobre las mejores prácticas de gestión de datos, el DCAM describe 37 capacidades y 115 subcapacidades
asociadas con el desarrollo de un programa sostenible de gestión de datos. La puntuación se centra en el nivel de participación de las partes
interesadas, la formalidad del proceso y la existencia de artefactos que demuestran el logro de las capacidades.
1.3.3.3 Modelo de madurez del Consejo de gobierno de datos de IBM101
El Modelo de Madurez del Consejo de Gobernanza de Datos de IBM se basó en los aportes de un consejo de 55 organizaciones.
Los miembros del consejo colaboraron para definir un conjunto común de comportamientos observables y deseados que las organizaciones
pueden usar para evaluar y diseñar sus propios programas de gobierno de datos. El propósito del modelo es ayudar a las organizaciones a
generar consistencia y control de calidad en la gobernanza a través de tecnologías comerciales probadas, métodos colaborativos y mejores
prácticas. El modelo está organizado en torno a cuatro categorías clave:
• Resultados: Gestión de riesgos de datos y cumplimiento, creación de valor •
Facilitadores: Estructura organizativa y conciencia, política, administración
99
http://bit.ly/1Vev9xx consultado el 18072015.
100 http://bit.ly/2sqaSga consultado el 18072015.
101 https://ibm.co/2sRfBIn (consultado el 4 de diciembre de 2016).
• Disciplinas básicas: gestión de la calidad de los datos, gestión del ciclo de vida de la información, seguridad de la información
y privacidad
• Disciplinas de apoyo: arquitectura de datos, clasificación y metadatos, información de auditoría, registro
e informes
El modelo de IBM se presenta como un Marco de Madurez y como un conjunto de preguntas de evaluación con respuestas construidas
para indicar los niveles de madurez.
1.3.3.4 Modelo de madurez de gobierno de datos de Stanford102
El Modelo de Madurez de la Gobernanza de Datos de Stanford fue desarrollado para uso de la Universidad; no estaba destinado a ser
un estándar de la industria. Aún así, sirve como un ejemplo sólido de un modelo que brinda orientación y un estándar de medición. El
modelo se centra en la gobernanza de datos, no en la gestión de datos, pero, sin embargo, proporciona una base para evaluar la
gestión de datos en general. El modelo diferencia entre los componentes fundamentales (concienciación, formalización, metadatos) y
de proyecto (administración de datos, calidad de datos, datos maestros). Dentro de cada uno, articula impulsores de personas,
políticas y capacidades. Luego articula las características de cada nivel de madurez. También proporciona mediciones cualitativas y
cuantitativas para cada nivel.
1.3.3.5 Modelo de madurez de gestión de información empresarial de Gartner
Gartner ha publicado un modelo de madurez de EIM, que establece criterios para evaluar la visión, la estrategia, las métricas, la
gobernanza, las funciones y responsabilidades, el ciclo de vida y la infraestructura.
2. Actividades
Las evaluaciones de madurez de la gestión de datos requieren planificación. Para garantizar resultados prácticos y procesables, deje
tiempo dentro del plan para la preparación de materiales y la evaluación de resultados. Las evaluaciones deben llevarse a cabo en un
período de tiempo breve y definido. El propósito de la evaluación es exponer las fortalezas actuales y las oportunidades de mejora, no
resolver problemas.
Las evaluaciones se llevan a cabo solicitando conocimientos de los participantes de negocios, gestión de datos y tecnología de la
información. El objetivo es llegar a una visión consensuada de las capacidades del estado actual, respaldada por evidencia. La
evidencia puede provenir del examen de los artefactos (por ejemplo, si existen copias de seguridad de la base de datos), a través de
entrevistas (verificando que alguien está realizando una evaluación del sistema de registros para su reutilización), o ambos.
102 http://stanford.io/2sBR5bZ (consultado el 04122016) y http://stanford.io/2rVPyM2 (consultado el 04122016).
540 • DMBOK2
Las evaluaciones pueden y deben escalarse para adaptarse a las necesidades de la organización. Sin embargo, modifique con
cuidado. Los modelos pueden perder rigor o trazabilidad a la intención original si se acortan o editan. Mantén intacta la integridad
del modelo al personalizarlo.
2.1 Actividades de evaluación del plan
La planificación de una evaluación incluye definir el enfoque general y comunicarse con las partes interesadas antes y durante la
evaluación para asegurarse de que participen. La evaluación en sí incluye la recopilación y evaluación de insumos y la comunicación
de resultados, recomendaciones y planes de acción.
2.1.1 Definir objetivos
Cualquier organización que decida que debe evaluar su nivel de madurez de gestión de datos ya está comprometida con el esfuerzo
de mejorar sus prácticas. En la mayoría de los casos, dicha organización habrá identificado los impulsores de la evaluación. Estos
impulsores deben aclararse en forma de objetivos que describan el enfoque e influyan en el alcance de la evaluación. Los objetivos
de la evaluación deben ser claramente entendidos por los ejecutivos y las líneas de negocio, quienes pueden ayudar a asegurar la
alineación con la dirección estratégica de la organización.
Los objetivos de la evaluación también brindan criterios para evaluar qué modelo de evaluación adoptar, qué áreas comerciales
priorizar para la evaluación y quién debe proporcionar información directa al proceso.
2.1.2 Elija un marco
Como se describe en la Sección 1.3.3, los marcos existentes se centran en diferentes aspectos de la gestión de datos. Revise estos
marcos en el contexto de los supuestos sobre el estado actual y los objetivos de evaluación para elegir uno que informará a la
organización de manera significativa. Las áreas de enfoque del modelo de evaluación se pueden personalizar según el enfoque o
el alcance de la organización.
La elección del marco influye en cómo se lleva a cabo la evaluación. El equipo que trabaja en él debe tener experiencia en el modelo
y la metodología de la que depende.
2.1.3 Definir el alcance organizacional
La mayoría de los marcos DMM están diseñados para aplicarse a toda una empresa. Sin embargo, un alcance de toda la empresa
puede ser poco práctico. Para una primera evaluación, por lo general es mejor definir un alcance manejable, como un área o
programa comercial único. Las áreas elegidas representan un subconjunto significativo de la organización y los participantes deben
poder influir en los procesos comerciales clave que afectan los activos de datos dentro del alcance. Como parte de un enfoque por etapas,
la evaluación puede repetirse para otras partes de la organización. Hay compensaciones entre local y empresarial.
evaluaciones:
• Las evaluaciones localizadas pueden profundizar mucho más en los detalles. También se pueden hacer más rápido.
porque el alcance está contenido. Para realizar una evaluación localizada, seleccione una función que esté altamente
regulada, como la presentación de informes financieros dentro de una empresa pública. Los insumos, roles, herramientas y
consumidores pueden estar fuera de las funciones que se evalúan, lo que puede complicar el alcance y la ejecución de la
evaluación. Las evaluaciones localizadas bien planificadas a menudo se pueden agregar y ponderar para formar una
evaluación empresarial, ya que se comparten muchos activos de datos.
• Las evaluaciones empresariales se centran en las partes amplias ya veces desconectadas de una organización. Un
La evaluación empresarial puede crearse a partir de DMMA localizados o puede ser una tarea separada. Por ejemplo, una
organización puede evaluar diferentes funciones (investigación y desarrollo, fabricación y financiación) basándose en los
mismos criterios. Las entradas, los roles, las herramientas y los consumidores suelen ser panempresariales y de varios
niveles.
2.1.4 Definir el enfoque de interacción
Al realizar un DMMA, una organización debe seguir las recomendaciones para el modelo seleccionado. Las actividades de recopilación
de información pueden incluir talleres, entrevistas, encuestas y revisiones de artefactos. Emplee métodos que funcionen bien dentro de la
cultura organizacional, minimice el compromiso de tiempo de los participantes y permita que la evaluación se complete rápidamente para
que las acciones de la evaluación puedan definirse mientras el proceso está fresco en la mente de los participantes.
En todos los casos, las respuestas deberán formalizarse haciendo que los participantes califiquen los criterios de evaluación. En muchos
casos, la evaluación también incluirá la inspección y evaluación reales de artefactos y otras pruebas.
Si hay demoras en completar la evaluación, es probable que las partes interesadas pierdan el entusiasmo por el programa de gestión de
datos y el ímpetu por contribuir a un cambio positivo. Es aconsejable evitar el análisis detallado y exhaustivo y enfatizar el buen juicio
basado en la experiencia de los líderes de la evaluación. Los marcos DMM proporcionan los criterios de medición y un camino integrado
para la mejora. Estos permiten la síntesis de una imagen completa del programa de gestión de datos actual y sus partes.
2.1.5 Planificar las comunicaciones
Las comunicaciones contribuyen al éxito general de la evaluación y los elementos de acción que surgen de ella.
La comunicación se dirigirá a los participantes y otras partes interesadas. Los hallazgos pueden afectar los trabajos de las personas, a
través de cambios en la metodología y la alineación organizacional, por lo que es importante comunicar claramente el propósito, el
proceso y las expectativas específicas para individuos y grupos. Asegúrese de que los participantes entiendan el modelo de evaluación,
así como también cómo se utilizarán los hallazgos.
542 • DMBOK2
Antes de que comience la evaluación, se debe informar a las partes interesadas sobre las expectativas de la evaluación.
Las comunicaciones deben describir:
• El propósito de la DMMA
• Cómo se llevará a cabo
• Cuál puede ser su participación
• El calendario de actividades de evaluación
Durante cualquier actividad de la evaluación (por ejemplo, una reunión de un grupo focal), asegúrese de que haya una agenda clara, incluido un
plan para responder cualquier pregunta de seguimiento. Recuerde continuamente a los participantes las metas y objetivos.
Siempre agradezca a los participantes y describa los próximos pasos.
Determinar si es probable que el enfoque planificado tenga éxito en todo el ámbito comercial objetivo, incluidos factores tales como resistencia/
cooperación, posibles inquietudes legales internas sobre la exposición a la inspección externa si se encuentran brechas preocupantes o posibles
inquietudes de Recursos Humanos.
El plan de comunicaciones debe incluir un cronograma para informar sobre los hallazgos y recomendaciones en todos los niveles, incluidos
informes generales y sesiones informativas ejecutivas.
2.2 Realizar evaluación de madurez
2.2.1 Recopilar información
El siguiente paso es recopilar insumos apropiados para la evaluación, con base en el modelo de interacción. Como mínimo, la información
recopilada incluirá calificaciones formales de los criterios de evaluación. También puede incluir aportes de entrevistas y grupos focales, análisis
de sistemas y documentación de diseño, investigación de datos, cadenas de correo electrónico, manuales de procedimientos, estándares,
políticas, repositorios de archivos, flujos de trabajo de aprobación, varios productos de trabajo, repositorios de metadatos, datos y arquitecturas
de referencia de integración, plantillas. y formularios.
2.2.2 Realizar la Evaluación
Las asignaciones de calificaciones generales y la interpretación suelen tener varias fases. Los participantes tendrán diferentes opiniones
generando diferentes calificaciones en los temas de evaluación. Se necesitará discusión y racionalización para conciliar las calificaciones. Los
participantes brindan información y luego se refinan mediante revisiones de artefactos o exámenes por parte del equipo de evaluación. El objetivo
es llegar a una visión consensuada del estado actual. Este punto de vista debe estar respaldado por evidencia (es decir, prueba de práctica
demostrada por comportamiento y artefactos). Si las partes interesadas no tienen consenso sobre el estado actual, es difícil tener consenso
sobre cómo mejorar la organización.
El refinamiento generalmente funciona de la siguiente manera:
• Revisar los resultados contra el método de calificación y asignar una calificación preliminar a cada producto de trabajo o
actividad.
• Documentar la evidencia de respaldo. • Revise
con los participantes para llegar a un consenso sobre una calificación final para cada área. Si es apropiado, use
modificadores de peso basados en la importancia de cada criterio.
• Documentar la interpretación de la calificación utilizando las declaraciones de criterios del modelo y los comentarios del
evaluador. • Desarrollar visualizaciones para ilustrar los resultados de la evaluación.
2.3 Interpretar resultados
La interpretación de los resultados consiste en identificar oportunidades de mejora alineadas con la estrategia organizacional y
recomendar las acciones necesarias para aprovechar dichas oportunidades. En otras palabras, la interpretación define los próximos
pasos hacia un estado objetivo. Cuando se completa la evaluación, las organizaciones deben planificar el estado objetivo que aspiran
lograr en la gestión de datos. La cantidad de tiempo y esfuerzo necesarios para alcanzar el objetivo deseado variará según el punto de
partida, la cultura de la organización y los impulsores del cambio.
Al presentar los resultados de la evaluación, comience con el significado de las calificaciones para la organización. Las calificaciones
se pueden expresar con respecto a los impulsores organizacionales y culturales, así como a los objetivos comerciales, como la
satisfacción del cliente o el aumento de las ventas. Ilustrar el vínculo entre las capacidades actuales de la organización y los procesos
y estrategias comerciales que respaldan, y los beneficios de mejorar estas capacidades moviéndose al estado objetivo.
2.3.1 Informe de los resultados de la evaluación
El informe de evaluación debe incluir:
• Impulsores comerciales para la evaluación
• Resultados generales de la evaluación
• Calificaciones por tema con brechas indicadas
• Un enfoque recomendado para cerrar las brechas •
Fortalezas de la organización observadas • Riesgos
para el progreso • Opciones de inversión y resultados
• Gobernanza y métricas para medir el progreso •
Análisis de recursos y uso potencial futuro • Artefactos que
se pueden usar o reutilizados dentro de la organización
El informe de evaluación es una entrada para la mejora del programa de gestión de datos, ya sea en su totalidad o por área de
conocimiento de gestión de datos. A partir de ella, la organización puede desarrollar o avanzar en su gestión de datos
544 • DMBOK2
estrategia. La estrategia debe incluir iniciativas que promuevan los objetivos comerciales a través de una mejor gobernanza de procesos
y estándares.
2.3.2 Desarrollar sesiones informativas ejecutivas
El equipo de evaluación debe preparar informes ejecutivos que resuman los hallazgos (fortalezas, deficiencias y recomendaciones) que
los ejecutivos utilizarán como información para tomar decisiones sobre objetivos, iniciativas y plazos. El equipo debe adaptar los mensajes
para aclarar los posibles impactos y beneficios para cada grupo ejecutivo.
A menudo, los ejecutivos desean apuntar más alto que las recomendaciones de la evaluación. En otras palabras, quieren saltarse niveles
en el modelo de madurez. El objetivo de un mayor nivel de madurez debe reflejarse en el análisis de impacto de las recomendaciones.
Este tipo de aceleración tiene un costo, y los costos deben equilibrarse con los beneficios.
2.4 Crear un programa específico para mejoras
La DMMA debe tener un impacto directo en la estrategia de datos y el gobierno de TI, así como en el programa y la estrategia de gestión
de datos. Las recomendaciones de la DMMA deben ser procesables. Estos deben describir las capacidades que requiere la organización.
Al hacerlo, una evaluación puede ser una herramienta poderosa para que los líderes empresariales y de TI establezcan prioridades
organizacionales y asignen recursos.
2.4.1 Identificar acciones y crear una hoja de ruta
Las clasificaciones de DMMA resaltan elementos para la atención de la gerencia. Inicialmente, es probable que una calificación se utilice
como una métrica independiente para determinar qué tan bien una organización está realizando una actividad específica. Sin embargo,
las calificaciones se pueden operacionalizar rápidamente en medidas continuas, especialmente para actividades en las que se desea un
cambio (p. ej., “El objetivo es el nivel 'n' porque necesitamos o queremos poder hacer algo 'z'”). Si el modelo de evaluación se utiliza para
la medición continua, sus criterios no solo guían a la organización hacia niveles más altos de madurez, sino que también mantienen la
atención de la organización en los esfuerzos de mejora.
Los resultados de la evaluación de DMM deben ser lo suficientemente detallados y completos para respaldar un programa de mejora de
la gestión de datos de varios años, incluidas las iniciativas que desarrollarán la capacidad de gestión de datos a medida que la
organización adopta las mejores prácticas. Dado que el cambio ocurre en gran medida en las organizaciones a través de proyectos, se
debe influir en los nuevos proyectos para que adopten mejores prácticas. La hoja de ruta o plan de referencia debe contener:
• Actividades secuenciadas para efectuar mejoras en funciones específicas de gestión de datos • Un
cronograma para implementar actividades de mejora • Mejoras esperadas en las calificaciones de DMMA
una vez que se hayan implementado las actividades • Supervisión de actividades, incluida la maduración
de esta supervisión sobre el cronograma
La hoja de ruta proporcionará objetivos y un ritmo para el cambio dentro de los flujos de trabajo priorizados, y estará acompañada de un
enfoque para medir el progreso.
2.5 Reevaluar la madurez
Las reevaluaciones deben llevarse a cabo a intervalos regulares. Forman parte del ciclo de mejora continua:
• Establecer una calificación de referencia a través de la primera evaluación
• Definir parámetros de reevaluación, incluido el alcance de la organización • Repetir la
evaluación DMM según sea necesario en un cronograma publicado
• Seguimiento de tendencias en relación con la línea de base inicial
• Desarrollar recomendaciones basadas en los hallazgos de la reevaluación
La reevaluación también puede revitalizar o reenfocar el esfuerzo. El progreso medible ayuda a mantener el compromiso y el entusiasmo en
toda la organización. Los cambios en los marcos regulatorios, la política interna o externa, o las innovaciones que podrían cambiar el enfoque
de la gobernanza y las estrategias son razones adicionales para reevaluar periódicamente.
3. Herramientas
• Marco de Madurez de Gestión de Datos: La herramienta principal utilizada en una evaluación de madurez es el
Marco DMM en sí mismo.
• Plan de comunicación: un plan de comunicación incluye un modelo de participación para las partes interesadas, el
tipo de información que se compartirá y el calendario para compartir información.
• Herramientas de colaboración: Las herramientas de colaboración permiten compartir los resultados de la evaluación. Además,
la evidencia de las prácticas de gestión de datos se puede encontrar en correos electrónicos, plantillas completas y
documentos de revisión creados a través de procesos estándar para diseño colaborativo, operaciones, seguimiento de
incidentes, revisiones y aprobaciones.
• Gestión del conocimiento y repositorios de metadatos: en estos repositorios se pueden gestionar estándares de datos, políticas,
métodos, agendas, actas de reuniones o decisiones y artefactos comerciales y técnicos que sirvan como prueba de la práctica.
En algunos CMM, la falta de dichos repositorios es un indicador de menor madurez en la organización. Los repositorios de
metadatos pueden existir en varias construcciones, lo que puede no ser obvio para los participantes. Por ejemplo, algunas
aplicaciones de Business Intelligence dependen completamente de los metadatos para compilar sus vistas e informes, sin
referirse a ellos como un repositorio distinto e independiente.
546 • DMBOK2
4. Técnicas
Muchas técnicas relacionadas con la ejecución de un DMMA están definidas por la metodología del marco DMM elegido. Las técnicas que
son más generales se describen aquí.
4.1 Selección de un marco DMM
Los siguientes criterios deben tenerse en cuenta al seleccionar un marco DMM.
• Accesibilidad: Las prácticas se expresan en términos no técnicos que transmiten la esencia funcional de la
actividad.
• Integralidad: El marco aborda un amplio alcance de las actividades de gestión de datos y
incluye compromiso comercial, no simplemente procesos de TI.
• Extensible y flexible: el modelo está estructurado para permitir la mejora de disciplinas adicionales o específicas de la
industria y se puede utilizar en su totalidad o en parte, según las necesidades de la organización.
• Camino de progreso futuro incorporado: si bien las prioridades específicas difieren de una organización a otra, el marco DMM
describe un camino lógico a seguir dentro de cada una de las funciones que describe. • Agnóstico de la industria versus
específico de la industria: algunas organizaciones se beneficiarán de un enfoque específico de la industria, otras de un marco más
genérico. Cualquier marco DMM también debe adherirse a las mejores prácticas de gestión de datos que cruzan verticales.
• Nivel de abstracción o detalle: Las prácticas y criterios de evaluación se expresan con un nivel de detalle suficiente para asegurar
que puedan relacionarse con la organización y el trabajo que realiza.
• No prescriptivo: el marco describe lo que debe realizarse, no cómo debe realizarse.
realizado.
• Organizado por tema: El marco coloca las actividades de gestión de datos en su contexto apropiado,
permitiendo que cada uno sea evaluado por separado, mientras se reconocen las dependencias.
• Repetible: el marco se puede interpretar de manera coherente, lo que respalda resultados repetibles para comparar
una organización frente a otras en su industria y seguir el progreso a lo largo del tiempo.
• Respaldado por una organización neutral e independiente: el modelo debe ser independiente del proveedor para evitar conflictos
de interés y estar ampliamente disponible para garantizar una amplia representación de las mejores prácticas.
• Tecnología neutral: el enfoque del modelo debe estar en las prácticas, en lugar de las herramientas. • Soporte
de capacitación incluido: el modelo está respaldado por una capacitación integral para permitir
profesionales para dominar el marco y optimizar su uso.
4.2 Uso del marco DAMADMBOK
El DAMADMBOK se puede utilizar para preparar o establecer criterios para un DMMA. Los propietarios de la ejecución verán un vínculo
directo entre las funciones segmentadas (las áreas de conocimiento) y las tareas correspondientes (actividades).
Las áreas de conocimiento, las actividades y los entregables (productos de trabajo) de DMBOK se pueden configurar en un marco DMM
específico en función de las áreas medidas, sus actividades de apoyo, relevancia y tiempo disponible. Este enfoque rápido de lista de
verificación se puede utilizar para determinar áreas que necesitan un análisis más profundo, representar brechas o señalar puntos críticos para
la remediación.
El DMBOK ofrece una ventaja adicional como herramienta de evaluación y planificación: existe una gran comunidad de profesionales del
conocimiento que utilizan el DMBOK como guía en múltiples industrias, creando una comunidad de práctica en torno a su uso.
5. Pautas para un DMMA
Antes de realizar una evaluación de madurez, es útil identificar los riesgos potenciales y algunas estrategias de mitigación de riesgos. La Tabla
33 resume los riesgos y los enfoques de mitigación.
Tabla 33 Riesgos típicos y mitigaciones para un DMMA
Riesgo Mitigación
Falta de compromiso organizacional Socialice los conceptos relacionados con la evaluación.
Establezca declaraciones de beneficios antes de realizar la evaluación. Comparte artículos y
casos de éxito. Involucrar a un patrocinador ejecutivo para defender el esfuerzo y revisar los
resultados.
Falta de experiencia en DMMA Utilice recursos de terceros o especialistas. Requerir transferencia de conocimientos y
Falta de tiempo o experiencia capacitación como parte del compromiso.
interna
Falta de planificación o
estándares de comunicación.
Falta de 'Habla de datos' en la Relacionar el DMMA con problemas o escenarios comerciales específicos.
organización; Las conversaciones sobre Dirección en el plan de comunicaciones. La DMMA educará a todos los participantes
datos se convierten rápidamente en independientemente de sus antecedentes y experiencia técnica. Orientar a los participantes
discusiones sobre sistemas sobre conceptos clave previos al DMMA.
Activos incompletos o Marque 'a partir de' o equilibre la calificación en consecuencia. Por ejemplo, asigne un 1 a
desactualizados para análisis todo lo que tenga más de 1 año de antigüedad.
Enfoque estrecho Reduzca la profundidad de la investigación a un simple DMMA y vaya a otras áreas para una
evaluación rápida para establecer calificaciones para una línea de base comparativa posterior.
Lleve a cabo el primer DMMA como piloto, luego aplique las lecciones aprendidas para abordar
un alcance más amplio. Presentar el enfoque dentro del alcance de la evaluación propuesta en
el contexto de las áreas de conocimiento de DAMADMBOK. Ilustre lo que queda fuera del alcance
y discuta la necesidad de incluirlo.
Personal o sistemas inaccesibles Reduzca el alcance horizontal del DMMA centrándose solo en las áreas de conocimiento y el
personal disponibles Agregue flexibilidad al flujo de trabajo y enfoque de la evaluación.
Surgen sorpresas como un
cambio de reglamento
548 • DMBOK2
5.2 Cambio Organizacional y Cultural
Establecer o mejorar un programa de gestión de datos incluye cambios en los procesos, métodos y herramientas.
Con estos cambios, la cultura también debe cambiar. La transformación organizacional y cultural comienza con el reconocimiento de que las
cosas pueden ser mejores. Las funciones de medición suelen marcar el comienzo de un cambio significativo. El DMMA ubica a la
organización en una escala de madurez y proporciona una hoja de ruta para la mejora. Al hacerlo, puede orientar a una organización hacia
adelante a través del cambio. Los resultados de DMMA deben ser parte de una discusión más amplia dentro de una organización. Cuando
cuentan con el respaldo adecuado de un gobierno de datos efectivo, los resultados de DMMA pueden fusionar diferentes perspectivas, dar
como resultado una visión compartida y acelerar el progreso de una organización. (Consulte el Capítulo 17.)
6. Gobernanza de la gestión de la madurez
Por lo general, un DMMA es parte de un conjunto general de actividades de gobierno de datos, cada una de las cuales tiene un ciclo de
vida. El ciclo de vida de un DMMA consiste en la planificación inicial y la evaluación inicial, seguidas de recomendaciones, un plan de acción
y una reevaluación periódica. El ciclo de vida en sí debe ser gobernado.
6.1 Supervisión del proceso DMMA
La supervisión del proceso de DMMA pertenece al equipo de Data Governance. Si el gobierno de datos formal no está en su lugar, entonces
la supervisión pasa por defecto al comité directivo o al nivel de gestión que inició la DMMA. El proceso debe tener un patrocinador ejecutivo,
idealmente el CDO, para garantizar que las mejoras en las actividades de gestión de datos se correspondan directamente con los objetivos
comerciales.
La amplitud y profundidad de la supervisión dependen del alcance de la DMMA. Cada función involucrada en el proceso tiene voz en la
ejecución, método, resultados y hojas de ruta que surgen de la evaluación general. Cada área de gestión de datos y función de organización
involucrada tendrá una vista independiente, pero también tendrá un lenguaje común a través del marco DMM.
6.2 Métricas
Además de ser un componente central de cualquier estrategia de mejora, las métricas son una herramienta de comunicación clave.
Las métricas iniciales de DMMA son las calificaciones que representan el estado actual de la gestión de datos. Estos pueden reevaluarse
periódicamente para mostrar tendencias de mejora. Cada organización debe desarrollar métricas adaptadas a la hoja de ruta de su estado
objetivo. Las métricas de muestra podrían incluir:
• Calificaciones de DMMA: las calificaciones de DMMA presentan una instantánea del nivel de capacidad de la organización. Las
calificaciones pueden ir acompañadas de una descripción, tal vez una ponderación personalizada para la calificación en una
evaluación o área temática específica, y un estado objetivo recomendado.
• Tasas de utilización de recursos: poderosos ejemplos de métricas que ayudan a expresar el costo de los datos
gestión en forma de recuento de personas. Un ejemplo de este tipo de métrica es: “Todos los recursos de la organización
pasan el 10 % de su tiempo agregando datos manualmente”.
• La exposición al riesgo o la capacidad de responder a escenarios de riesgo expresa las capacidades de una organización
en relación con sus clasificaciones DMMA. Por ejemplo, si una organización quisiera comenzar un nuevo negocio que
requería un alto nivel de automatización pero su modelo operativo actual se basa en la gestión manual de datos (Nivel 1),
correría el riesgo de no cumplir.
• La gestión de gastos expresa cómo se asigna el coste de la gestión de datos en una organización
e identifica los impactos de este costo en la sostenibilidad y el valor. Estas métricas se superponen con las métricas
de gobierno de datos.
o Sostenibilidad de la gestión de datos o
Logro de las metas y objetivos de la iniciativa
o Eficacia de la comunicación
o Eficacia de la educación y la formación o Velocidad
de adopción del cambio o Valor de la gestión de
datos o Contribuciones a los objetivos empresariales
o Reducciones de riesgos
o Mejora de la eficiencia en las operaciones
• Es importante administrar las entradas a la DMMA , ya que hablan de la integridad de la cobertura, el nivel de investigación y el
detalle del alcance relevante para la interpretación de los resultados de la puntuación. Las entradas principales podrían incluir
lo siguiente: conteo, cobertura, disponibilidad, cantidad de sistemas, volúmenes de datos, equipos involucrados, etc.
• Tasa de cambio La tasa a la que una organización mejora su capacidad. Se establece una línea base
a través del DMMA. La reevaluación periódica se utiliza para mejorar la tendencia.
Aflerbach, Peter. Lecturas esenciales sobre la evaluación. Asociación Internacional de Lectura, 2010. Imprimir.
Baskarada, Sasa. IQMCMM: Modelo de Madurez de la Capacidad de Gestión de la Calidad de la Información. Vieweg+Teubner Verlag, 2009.
Imprimir. Ausgezeichnete Arbeiten zur Informationsqualität.
Boutros, Tristán y Tim Purdie. El manual de mejora de procesos: un modelo para gestionar el cambio y aumentar el rendimiento de la organización.
McGrawHill Education, 2013. Imprimir.
Instituto CMMI (sitio web). http://bit.ly/1Vev9xx.
Crawford, J. Kent. Modelo de Madurez de Gestión de Proyectos. 3ra ed. Publicaciones de Auerbach, 2014. Imprimir. Investigación de
soluciones PM.
550 • DMBOK2
Consejo de gestión de datos empresariales (sitio web).
Freund, Jack y Jack Jones. Medición y gestión del riesgo de la información: un enfoque JUSTO. ButterworthHeinemann, 2014. Imprimir.
Ghavami, Peter PhD. Gobernanza de Big Data: Principios modernos de gestión de datos para Hadoop, NoSQL y Big Data Analytics. Plataforma de
publicación independiente CreateSpace, 2015. Imprimir.
Honeyset, Sara. Capacidad limitada: la fase de evaluación. Amazon Digital Services LLC., 2013. Libro de Inseguridad Social 3.
Consejo de gobierno de datos de IBM. https://ibm.co/2sUKIng.
Jeff Gorball, Introducción a los modelos de madurez de gestión de datos. SlideShare.net, 20160801. http://bit.ly/2tsIOqR.
Marchewka, Jack T. Gestión de proyectos de tecnología de la información: Proporcionar valor organizacional medible. 5ª ed.
Wiley, 2016. Imprimir.
McSweney, Alan. Revisión de modelos de madurez de gestión de datos. SlideShare.net, 20131023. http://bit.ly/2spTCY9.
Persse, James R. Implementación del modelo de madurez de capacidad. Wiley, 2001.Imprimir.
Saaksvuori, Antti. Marco de evaluación de la madurez de la gestión de productos. Sirrus Publishing Ltd., 2015. Imprimir.
Seleccione Soluciones comerciales. “¿Qué es el modelo de madurez de la capacidad?” http://bit.ly/IFMJI8 (Consultado el 10 de noviembre de 2016).
Universidad Stanford. Modelo de madurez de gobierno de datos de Stanford. http://stanford.io/2ttOMrF.
Editorial Van Haren. Marco de Madurez de Capacidades de TI ITCMF. Van Haren Pub, 2015. Imprimir.
CAPÍTULO 1 6
Organización y función de gestión de datos
Expectativas
1. Introducción
T
El panorama de datos está evolucionando rápidamente y, con él, las organizaciones necesitan evolucionar la forma en que administran
y gobiernan los datos. La mayoría de las organizaciones de hoy en día se enfrentan a un volumen cada vez mayor de datos capturados
a través de una amplia gama de procesos en una variedad de formatos. El aumento de volumen y variedad añade complejidad a la
gestión de datos. Al mismo tiempo, los consumidores de datos exigen ahora un acceso rápido y fácil a los datos.
Quieren ser capaces de comprender los datos y usarlos para abordar preguntas comerciales críticas de manera oportuna.
Las organizaciones de administración y gobierno de datos deben ser lo suficientemente flexibles para trabajar de manera efectiva en este entorno
en evolución. Para hacerlo, necesitan aclarar preguntas básicas sobre propiedad, colaboración, responsabilidad y toma de decisiones.
Esta sección describirá un conjunto de principios que deben tenerse en cuenta al crear una organización de gestión o gobierno de datos. Se refiere
tanto al gobierno de datos como a la gestión de datos porque el gobierno de datos proporciona la orientación y el contexto comercial para las
actividades ejecutadas por la Organización de gestión de datos. No existe una estructura organizativa perfecta para ninguno de los dos. Si bien se
deben aplicar principios comunes a la organización en torno al gobierno y la gestión de datos, gran parte de los detalles dependerán de los
impulsores de la industria de esa empresa y la cultura corporativa de la empresa misma.
2. Comprender las normas culturales y de organización existentes
La conciencia, la propiedad y la responsabilidad son las claves para activar e involucrar a las personas en iniciativas, políticas y procesos de
gestión de datos. Antes de definir una nueva organización o intentar mejorar una existente, es importante comprender el estado actual de los
componentes, relacionados con la cultura, el modelo operativo existente y las personas. Consulte la Figura 106. Por ejemplo:
• El papel de los datos en la organización: ¿Qué procesos clave están basados en datos? ¿Cómo se definen y entienden los requisitos de
datos? ¿Qué tan reconocido es el papel que juegan los datos en la estrategia organizacional?
551
552 • DMBOK2
Operando
• ¿Cómo se toman las decisiones? Modelo
• Propietario de gestión de datos •
•¿Quién los hace?
Propietario de gobierno de datos •
• ¿Cómo se utilizan los comités? • Centralizado
• Descentralizado Expertos en la materia • Liderazgo
•¿Quién gestiona actualmente los
datos? • Híbrido/Federado
Cultura Gente
Figura 106 Evaluar el estado actual para crear un modelo operativo
• Normas culturales sobre los datos: ¿Existen posibles obstáculos culturales para implementar o mejorar
estructuras de gestión y gobierno? • Prácticas
de gestión y gobierno de datos: cómo y quién realiza el trabajo relacionado con los datos
¿ejecutado? ¿Cómo y por quién se toman las decisiones sobre los datos?
• Cómo se organiza y ejecuta el trabajo: por ejemplo, ¿cuál es la relación entre la ejecución centrada en el proyecto y la operativa?
¿Qué estructuras de comité existen que puedan respaldar la gestión de datos?
¿esfuerzo?
• Cómo se organizan las relaciones jerárquicas: por ejemplo, ¿la organización está centralizada o
¿descentralizado, jerárquico o plano?
• Niveles de habilidad: ¿Cuál es el nivel de conocimiento de datos y conocimiento de gestión de datos de las pymes y otros
partes interesadas, desde el personal de línea hasta los ejecutivos?
Después de formarse una imagen del estado actual, evalúe el nivel de satisfacción con el estado actual para obtener información sobre
las necesidades y prioridades de gestión de datos de la organización. Por ejemplo:
• ¿Tiene la organización la información que necesita para tomar decisiones comerciales sólidas y oportunas? • ¿La
organización tiene confianza en sus informes de ingresos? • ¿Puede realizar un seguimiento de los indicadores clave
de rendimiento de la organización? • ¿Cumple la organización con todas las leyes relativas a la gestión de datos?
La mayoría de las organizaciones que buscan mejorar su administración de datos o prácticas de gobierno se encuentran en el medio
de la escala de madurez de capacidad (es decir, no son ni 0 ni 5 en la escala CMM). (Consulte el Capítulo 15). Para diseñar una
organización de gestión de datos relevante, es importante comprender y adaptarse a la cultura empresarial y las normas organizativas
existentes. Si la organización de gestión de datos no está alineada con la toma de decisiones existente y las construcciones del comité,
será un desafío mantenerla a lo largo del tiempo. Por lo tanto, tiene sentido hacer evolucionar estas organizaciones, en lugar de imponer
cambios radicales.
Una organización de gestión de datos debe alinearse con la jerarquía y los recursos organizativos de una empresa.
Encontrar a las personas adecuadas requiere una comprensión del papel tanto funcional como político de los datos.
ORGANIZACIÓN DE GESTIÓN DE DATOS Y EXPECTATIVAS DEL ROL • 553
gestión dentro de una organización. El objetivo debe ser la participación interfuncional de las diversas partes interesadas del negocio. Para
lograr esto:
• Identificar a los empleados que actualmente realizan funciones de gestión de datos; reconocerlos e involucrarlos primero.
Contrate recursos adicionales solo a medida que crezcan las necesidades de administración y gobierno de datos.
• Examinar los métodos que utiliza la organización para gestionar los datos y determinar cómo se pueden gestionar los procesos.
mejorado. Determine cuánto cambio es probable que se requiera para mejorar las prácticas de gestión de datos. • Planifique
los tipos de cambios que deben llevarse a cabo desde una perspectiva organizacional para cumplir mejor
requisitos
3. Construcciones organizativas de gestión de datos
Un paso crítico en el diseño de la organización de gestión de datos es identificar el modelo operativo que mejor se adapte a la organización.
El modelo operativo es un marco que articula roles, responsabilidades y procesos de toma de decisiones. Describe cómo colaborarán las
personas y las funciones.
Un modelo operativo confiable ayuda a crear responsabilidad al garantizar que se representen las funciones correctas dentro de la
organización. Facilita la comunicación y proporciona un proceso para resolver problemas. Si bien constituye la base de la estructura
organizativa, el modelo operativo no es un organigrama; no se trata de poner nombres en casillas, sino de describir la relación entre los
componentes de la organización.
Esta sección presentará una descripción general de alto nivel de las ventajas y desventajas de los modelos operativos descentralizados,
de red, híbridos, federados y centralizados.
3.1 Modelo operativo descentralizado
En un modelo descentralizado, las responsabilidades de gestión de datos se distribuyen entre diferentes líneas de negocio y TI (consulte la
Figura 107). La colaboración se basa en comités; no hay un solo dueño. Muchos programas de gestión de datos comienzan como esfuerzos
de base para unificar las prácticas de gestión de datos en una organización y, por lo tanto,
tener una estructura descentralizada.
Los beneficios de este modelo incluyen su estructura relativamente plana y su alineación de la gestión de datos con las líneas de negocio o
TI. Esta alineación generalmente significa que hay una comprensión clara de los requisitos de datos. También es relativamente fácil de
implementar o mejorar.
Los inconvenientes incluyen el desafío de tener muchos participantes involucrados en los órganos de gobierno y en la toma de decisiones.
Por lo general, es más difícil implementar decisiones colaborativas que los edictos centralizados.
Los modelos descentralizados son generalmente menos formales y, debido a esto, pueden ser más difíciles de mantener en el tiempo. Para
tener éxito, necesitan tener formas de hacer cumplir la coherencia de las prácticas. Esto puede ser difícil de coordinar. También suele ser
difícil definir la propiedad de los datos con un modelo descentralizado.
554 • DMBOK2
LOB/BU
Comité Directivo de Gestión de Datos
Grupo de gestión de datos LOB/BU
Datos Solicitud Negocio Datos

mayordomos Arquitectos analistas analistas
Figura 107 Modelo operativo descentralizado
3.2 Modelo operativo de la red
La informalidad descentralizada se puede hacer más formal a través de una serie documentada de conexiones y
responsabilidades a través de una matriz RACI (Responsable, Responsable, Consultado e Informado). Esto se
denomina modelo en red porque funciona como una serie de conexiones conocidas entre personas y roles y se
puede diagramar como una 'red'. (Consulte la Figura 108.)
DATOS
ADMINISTRACIÓN
OFICINA
Figura 108 Modelo operativo de red
Los beneficios de un modelo de red son similares a los de un modelo descentralizado (estructura plana, alineación, configuración
rápida). La adición de un RACI ayuda a crear responsabilidad sin afectar los organigramas. El inconveniente adicional es la
necesidad de mantener y hacer cumplir las expectativas relacionadas con el RACI.
3.3 Modelo Operativo Centralizado
El modelo operativo de gestión de datos más formal y maduro es el centralizado (consulte la Figura 109). Aquí todo es
propiedad de la Organización de Gestión de Datos. Los involucrados en el gobierno y la gestión de datos informan directamente
a un líder de gestión de datos que es responsable de la gobernanza, la administración, la gestión de metadatos, la gestión de
la calidad de los datos, la gestión de datos maestros y de referencia, la arquitectura de datos, el análisis comercial, etc.
Ejecutivo Direccion
Patrocinador
Comité
Datos
Gestión
Plomo
Soporte empresarial Apoyo técnico
Negocio Datos Datos Técnico

Análisis Gestión Arquitectura Análisis de los datos
Grupo Grupo Grupo Grupo
Bus / LOB
Figura 109 Modelo operativo centralizado
El beneficio de un modelo centralizado es que establece una posición ejecutiva formal para la gestión de datos o el gobierno
de datos. Hay una persona en la parte superior. La toma de decisiones es más fácil porque la rendición de cuentas es clara.
Dentro de la organización, los datos se pueden gestionar por tipo o área temática. El inconveniente es que la implementación
de un modelo centralizado generalmente requiere un cambio organizacional significativo. También existe el riesgo de que la
separación formal de la función de gestión de datos la aleje de los procesos comerciales centrales y pueda provocar la pérdida
de conocimiento con el tiempo.
Un modelo centralizado generalmente requiere una nueva organización. Surge la pregunta: ¿Dónde encaja la Organización de
gestión de datos dentro de la empresa en general? ¿Quién lo dirige ya quién le reporta el líder? Eso
556 • DMBOK2
Cada vez es más común que una organización de gestión de datos no informe al CIO debido al deseo de mantener una perspectiva comercial,
en lugar de TI, sobre los datos. Estas organizaciones también suelen formar parte de un equipo de operaciones o servicios compartidos o
forman parte de la organización del director de datos. (Consulte la Sección 6.1.)
3.4 Modelo operativo híbrido
Como su nombre lo indica, el modelo operativo híbrido abarca los beneficios de los modelos descentralizado y centralizado (consulte la Figura
110). En un modelo híbrido, un Centro de Excelencia de gestión de datos centralizado trabaja con grupos de unidades de negocios
descentralizados, generalmente a través de un comité directivo ejecutivo que representa líneas de negocios clave y un conjunto de grupos de
trabajo tácticos que abordan problemas específicos.
Organización de gestión de datos
Comité Directivo
Centro de Gestión de Datos de
Excelencia
Equipos de unidades de negocio de gestión de datos
Partes interesadas comerciales Habilitación de TI
Gestión de datos BU
Figura 110 Modelo operativo híbrido
En este modelo, algunos roles permanecen descentralizados. Por ejemplo, los arquitectos de datos pueden permanecer dentro de un grupo de
arquitectura empresarial; las líneas de negocio pueden tener sus propios equipos de calidad de datos. Los roles centralizados y los que
permanecen descentralizados pueden variar ampliamente, dependiendo en gran medida de la cultura organizacional.
El principal beneficio de un modelo híbrido es que establece la dirección adecuada desde la parte superior de la organización. Hay un ejecutivo
responsable de la gestión y/o gobernanza de los datos. Los equipos de las unidades comerciales tienen una amplia responsabilidad y pueden
alinearse con las prioridades comerciales para brindar un mayor enfoque. Se benefician del apoyo de un Centro de excelencia de gestión de
datos dedicado que puede ayudar a enfocarse en desafíos específicos.
Los desafíos incluyen establecer la organización, ya que hacerlo generalmente requiere personal adicional para dotar de personal a un Centro
de Excelencia. Los equipos de las Unidades de negocio pueden tener diferentes prioridades, y estas deberán gestionarse desde una
perspectiva empresarial. Además, a veces hay conflictos entre las prioridades de la organización central y las de las organizaciones
descentralizadas.
3.5 Modelo operativo federado
Una variación del modelo operativo híbrido, el modelo federado proporciona capas adicionales de centralización/descentralización,
que a menudo se requieren en grandes empresas globales. Imagine una organización de gestión de datos empresarial con
múltiples modelos híbridos de gestión de datos delineados en función de la división o la región. (Consulte la Figura 111.)
Organización de gestión de datos
Dirección de gestión de información empresarial
Comité
Gestión de datos empresariales
Centro de excelencia
Grupos de gestión de datos
Datos Divisionales Datos Divisionales Datos Divisionales
Gestión Gestión Gestión

Grupo Grupo Grupo
Negocio Negocio Negocio

Partes interesadas Partes interesadas Partes interesadas
Habilitación de TI Habilitación de TI
Habilitación de TI
Figura 111 Modelo operativo federado
Un modelo federado proporciona una estrategia centralizada con ejecución descentralizada. Por lo tanto, para las grandes
empresas puede ser el único modelo que pueda funcionar. Un ejecutivo de gestión de datos responsable de toda la organización
dirige el Centro de Excelencia empresarial. Por supuesto, las diferentes líneas de negocio están facultadas para cumplir con los
requisitos en función de sus necesidades y prioridades. La federación permite a la organización priorizar en función de entidades
de datos específicas, desafíos divisionales o prioridades regionales.
El principal inconveniente es la complejidad. Hay muchas capas y es necesario que haya un equilibrio entre la autonomía de las
líneas de negocio y las necesidades de la empresa. Este equilibrio puede afectar las prioridades de la empresa.
3.6 Identificación del mejor modelo para una organización
El modelo operativo es un punto de partida para mejorar las prácticas de gestión y gobierno de datos.
Introducirlo requiere una comprensión de cómo puede afectar a la organización actual y cómo probablemente
558 • DMBOK2
necesita evolucionar con el tiempo. Dado que el modelo operativo servirá como la estructura a través de la cual se definirán,
aprobarán y ejecutarán las políticas y los procesos, es fundamental identificar la mejor opción para una organización.
Evalúe si la estructura organizacional actual es centralizada, descentralizada o una combinación, jerárquica o relativamente plana.
Caracterizar cuán independientes son las divisiones o regiones. ¿Operan casi autosuficientemente? ¿Son sus requisitos y
objetivos muy diferentes entre sí? Lo que es más importante, trate de determinar cómo se toman las decisiones (p. ej.,
democráticamente o por decreto), así como también cómo se implementan.
Las respuestas deben dar un punto de partida para comprender la ubicación de la organización en el espectro entre
descentralizado y centralizado.
3.7 Alternativas de DMO y consideraciones de diseño
La mayoría de las organizaciones comienzan con un modelo descentralizado antes de pasar a una Organización de gestión de
datos (DMO) formal. A medida que una organización ve el impacto de las mejoras en la calidad de los datos, puede comenzar a
formalizar la rendición de cuentas a través de una matriz RACI de gestión de datos y evolucionar hacia un modelo de red. Con el
tiempo, las sinergias entre los roles distribuidos se harán más evidentes y se identificarán economías de escala que atraerán a
algunos roles y personas a grupos organizados. Eventualmente, esto puede transformarse en un híbrido o federado
modelo.
Algunas organizaciones no pueden darse el lujo de pasar por este proceso de madurez. Se ven obligados a madurar rápidamente
en función de un shock del mercado o de nuevas regulaciones gubernamentales. En tal caso, es importante abordar de manera
proactiva la incomodidad asociada con el cambio organizacional para que sea exitoso y sostenible. (Consulte el Capítulo 17.)
Cualquiera que sea el modelo elegido, recuerde que la simplicidad y la facilidad de uso son esenciales para la aceptación y la
sostenibilidad. Si el modelo operativo se ajusta a la cultura de una empresa, entonces la gestión de datos y la gobernanza
adecuada pueden integrarse en las operaciones y alinearse con la estrategia. Tenga en cuenta estos consejos cuando construya
un modelo operativo:
• Determinar el punto de partida evaluando el estado actual •
Vincular el modelo operativo a la estructura de la organización
• Tener en cuenta:
o Complejidad + madurez de la organización o
Complejidad + madurez del dominio o
Escalabilidad • Obtener patrocinio ejecutivo:
imprescindible para un modelo sostenible • Asegurar que cualquier foro
de liderazgo (comité directivo, consejo asesor, junta) sea un lugar de toma de decisiones
cuerpo
• Considere programas piloto y olas de implementación • Céntrese
en dominios de datos de alto valor y alto impacto • Use lo que ya
existe • Nunca adopte un enfoque único para todos
ORGANIZACIÓN DE LA GESTIÓN DE DATOS Y EXPECTATIVAS DEL ROL • 559
4. Factores críticos de éxito
Se ha demostrado sistemáticamente que diez factores desempeñan un papel clave en el éxito de una gestión de datos eficaz
Las organizaciones, independientemente de su estructura:
1. Patrocinio ejecutivo
2. Visión clara
3. Gestión proactiva del cambio 4.
Alineación del liderazgo
5. Comunicación
6. Participación de las partes
interesadas 7. Orientación y
capacitación 8. Medición de la
adopción 9. Adherencia a los principios rectores
10. Evolución, no revolución
4.1 Patrocinio Ejecutivo
Tener el patrocinador ejecutivo adecuado garantiza que las partes interesadas afectadas por un programa de gestión de datos
reciban la orientación necesaria para hacer la transición de manera eficiente y efectiva a través de los cambios necesarios
para armar la nueva organización centrada en los datos y sostenerla a largo plazo. El patrocinador ejecutivo debe entender y
creer en la iniciativa. Él o ella debe ser capaz de involucrar de manera efectiva a otros líderes en apoyo de los cambios.
4.2 Visión clara
Una visión clara de la organización de gestión de datos, junto con un plan para impulsarla, es fundamental para el éxito.
Los líderes organizacionales deben asegurarse de que todas las partes interesadas que se ven afectadas por la gestión de
datos, tanto internas como externas, entiendan e internalicen qué es la gestión de datos, por qué es importante y cómo su
trabajo afectará y se verá afectado por ella.
4.3 Gestión proactiva del cambio
Gestionar el cambio asociado con la creación de una organización de gestión de datos requiere planificar, gestionar y mantener
el cambio. La aplicación de la gestión del cambio organizacional al establecimiento de una Organización de Gestión de Datos
aborda los desafíos de las personas y aumenta la probabilidad de que la Organización de Gestión de Datos deseada sea
sostenible en el tiempo. (Consulte el Capítulo 17.)
560 • DMBOK2
4.4 Alineación de liderazgo
La alineación del liderazgo garantiza que haya acuerdo y apoyo unificado para la necesidad de un programa de gestión de datos y que
haya acuerdo sobre cómo se definirá el éxito. La alineación del liderazgo incluye tanto la alineación entre los objetivos de los líderes y
los resultados y el valor de la gestión de datos como la alineación en el propósito entre los líderes.
Si los líderes no están alineados entre sí, terminarán enviando mensajes contradictorios que pueden generar resistencia y, finalmente,
descarrilar el cambio. Por lo tanto, es fundamental evaluar, y reevaluar regularmente, a los líderes en todos los niveles para identificar
las desconexiones y tomar medidas para abordarlas rápidamente.
4.5 Comunicación
La comunicación debe comenzar temprano y continuar abierta y frecuentemente. La organización debe asegurarse de que las partes
interesadas comprendan claramente qué es la gestión de datos y por qué es importante para la empresa, qué está cambiando y qué
cambios de comportamiento se requieren. Las personas no pueden mejorar la forma en que administran los datos si no saben qué se
supone que deben hacer de manera diferente. Crear una historia en torno a la iniciativa de gestión de datos y generar mensajes clave
a su alrededor ayuda a estos procesos.
Los mensajes deben ser consistentes, subrayando la importancia de la gestión de datos. Además, deben personalizarse según el grupo
de partes interesadas. Por ejemplo, variará el nivel de educación o la cantidad de capacitación que necesitan los diferentes grupos en
relación con la gestión de datos. Los mensajes deben repetirse según sea necesario y probarse continuamente a lo largo del tiempo
para garantizar que se transmitan de manera efectiva y que se desarrolle la conciencia y la comprensión.
4.6 Participación de las partes interesadas
Las personas, así como los grupos, afectados por una iniciativa de gestión de datos reaccionarán de manera diferente al nuevo
programa y su papel dentro de él. La forma en que la organización involucra a estas partes interesadas (cómo se comunican con ellas,
les responden y las involucran) tendrá un impacto significativo en el éxito de la iniciativa.
Un análisis de las partes interesadas ayuda a la organización a comprender mejor a las personas afectadas por los cambios en la
gestión de datos. Al tomar esa información y mapear a las partes interesadas de acuerdo con el nivel de influencia dentro de la
organización y el nivel de interés en (o afecto debido a) la implementación de la gestión de datos, la organización puede determinar el
mejor enfoque para involucrar a las diferentes partes interesadas en el proceso de cambio. (Consulte la Sección 5.3.)
4.7 Orientación y Capacitación
La educación es esencial para que la gestión de datos suceda, aunque diferentes grupos requerirán diferentes tipos
y niveles de educación.
Los líderes necesitarán orientación sobre los aspectos más amplios de la gestión de datos y el valor para la empresa. Los administradores,
propietarios y custodios de datos (es decir, aquellos que están en la primera línea del cambio) requerirán una comprensión profunda de
la iniciativa de gestión de datos. La capacitación enfocada les permitirá desempeñar sus funciones de manera efectiva. Esto significa
capacitación sobre nuevas políticas, procesos, técnicas, procedimientos e incluso herramientas.
4.8 Medición de la adopción
Es importante construir métricas en torno al progreso y la adopción de las pautas de gestión de datos y planificar para saber si la hoja de
ruta de gestión de datos está funcionando y seguirá funcionando. Plano a medida:
• Adopción •
Cantidad de mejora, o el delta de un estado anterior • Los aspectos
habilitadores de la gestión de datos: qué tan bien influye la gestión de datos en las soluciones con
resultados medibles?
• Procesos y proyectos mejorados •
Identificación y reacción al riesgo mejoradas • El aspecto
innovador de la gestión de datos: qué tan bien cambia fundamentalmente la gestión de datos
¿cómo se llevan a cabo los negocios?
• Análisis de confianza
El aspecto habilitador de la gestión de datos podría centrarse en la mejora de los procesos centrados en datos, como el cierre de fin de
mes, la identificación de riesgos y la eficiencia de la ejecución del proyecto. El aspecto de innovación de la gestión de datos podría
centrarse en la mejora de la toma de decisiones y el análisis a través de datos mejorados y confiables.
4.9 Adhesión a los Principios Rectores
Un principio rector es una declaración que articula los valores organizacionales compartidos, subyace en la visión y misión estratégicas y
sirve como base para la toma de decisiones integrada. Los principios rectores constituyen las reglas, restricciones, criterios primordiales
y comportamientos por los cuales una organización se rige en sus actividades diarias a largo plazo. Independientemente de si existe un
modelo operativo descentralizado o centralizado, o algo intermedio, es fundamental establecer y acordar principios rectores para que
todos los participantes se comporten de manera sincrónica. Los principios rectores sirven como puntos de referencia a partir de los cuales
se tomarán todas las decisiones. Establecerlos es un primer paso importante en la creación de un programa de gestión de datos que
impulse de manera efectiva los cambios en el comportamiento.
4.10 Evolución, no revolución
En todos los aspectos de la gestión de datos, la filosofía de 'evolución, no revolución' ayuda a minimizar los grandes cambios o los
proyectos de alto riesgo a gran escala. Es importante establecer una organización que evolucione y madure con el tiempo.
Mejorar gradualmente la forma en que los datos se gestionan y priorizan por objetivos comerciales garantizará que
562 • DMBOK2
se adoptan nuevas políticas y procesos y se mantiene el cambio de comportamiento. El cambio incremental también es mucho más fácil
de justificar, por lo que es más fácil obtener el apoyo y la aceptación de las partes interesadas, e involucrar a los participantes críticos.
5. Construir la organización de gestión de datos
5.1 Identificar a los participantes actuales en la gestión de datos
Al implementar el modelo operativo, comience con equipos que ya estén involucrados en actividades de gestión de datos. Esto minimizará
el efecto en la organización y ayudará a garantizar que el enfoque del equipo sean los datos, no los recursos humanos o la política.
Comience por revisar las actividades de gestión de datos existentes, como quién crea y gestiona los datos, quién mide la calidad de los
datos o incluso quién tiene 'datos' en su título de trabajo. Realice una encuesta en la organización para averiguar quién ya puede estar
desempeñando las funciones y responsabilidades necesarias. Tales individuos pueden tener diferentes títulos. Es probable que formen
parte de una organización distribuida y que la empresa no los reconozca necesariamente. Después de compilar una lista de 'personas de
datos', identifique las brechas. ¿Qué roles y conjuntos de habilidades adicionales se requieren para ejecutar la estrategia de datos? En
muchos casos, las personas en otras partes de la organización tienen conjuntos de habilidades transferibles similares. Recuerde, las
personas que ya están en la organización aportan valiosos conocimientos y experiencia a un esfuerzo de gestión de datos.
Una vez que se completa un inventario y se asignan personas a los roles, revise su compensación y alinéela con las expectativas de la
gestión de datos. Probablemente, el departamento de Recursos Humanos se involucrará para validar los títulos, roles, compensación y
objetivos de desempeño. Asegúrese de que los roles se asignen a las personas adecuadas en el nivel correcto dentro de la organización,
de modo que cuando participen en la toma de decisiones, tengan la credibilidad para tomar decisiones duraderas.
5.2 Identificar a los participantes del comité
Independientemente del modelo operativo que elija una organización, será necesario que un Comité Directivo de Gobernanza de Datos y
grupos de trabajo realicen algún trabajo de gobernanza. Es importante contar con las personas adecuadas en el Comité Directivo y utilizar
bien su tiempo. Manténgalos bien informados y enfocados en las formas en que una mejor gestión de datos los ayudará a alcanzar los
objetivos comerciales, incluidos los objetivos estratégicos.
Muchas organizaciones son reacias a iniciar otro comité ya que ya existen muchos. A menudo, es más fácil aprovechar los comités
existentes para avanzar en temas de gestión de datos que comenzar uno nuevo. Pero toma esta ruta con cautela. El principal riesgo de
usar un comité existente es que la gestión de datos puede no recibir la atención que requiere, especialmente en las primeras etapas. El
proceso para dotar de personal a un comité directivo senior oa un grupo de trabajo más táctico requiere realizar un análisis de las partes
interesadas y, a través de eso, identificar a los patrocinadores ejecutivos.
5.3 Identificar y analizar las partes interesadas
Una parte interesada es cualquier persona o grupo que puede influir o verse afectado por el programa de gestión de datos.
Las partes interesadas pueden ser internas o externas a la organización. Incluyen PyMEs individuales, líderes sénior, equipos de empleados,
comités, clientes, agencias gubernamentales o reguladoras, corredores, agentes, proveedores, etc.
Las partes interesadas internas pueden provenir de TI, operaciones, cumplimiento, legal, recursos humanos, finanzas u otras líneas de negocios.
Las partes interesadas externas pueden ser influyentes y es importante que la organización de gestión de datos tenga en cuenta sus necesidades.
Un análisis de las partes interesadas puede ayudar a la organización a determinar el mejor enfoque para involucrar a los participantes en el
proceso de gestión de datos y aprovechar sus roles dentro del modelo operativo. La información obtenida del análisis también es útil para
determinar cómo asignar mejor el tiempo y otros recursos limitados. Cuanto antes se lleve a cabo este análisis, mejor, ya que cuanto más capaz
sea la organización de anticipar las reacciones al cambio, más podrá planificarlas. Un análisis de las partes interesadas ayudará a responder
preguntas como:
• ¿Quién se verá afectado por la gestión de datos? • ¿Cómo
cambiarán los roles y las responsabilidades? • ¿Cómo podrían
responder los afectados a los cambios? • ¿Qué problemas y
preocupaciones tendrá la gente?
El análisis dará como resultado una lista de partes interesadas, sus objetivos y prioridades, y por qué esos objetivos son importantes para ellos.
Determine qué acciones son necesarias para las partes interesadas en función del análisis. Preste especial atención a lo que se debe hacer para
atraer a las partes interesadas críticas, aquellas que pueden hacer o deshacer el éxito de la gestión de datos de una organización, especialmente
sus prioridades iniciales. Considerar:
• Quién controla los recursos críticos
• Quién podría bloquear las iniciativas de gestión de datos, ya sea directa o indirectamente
• Quién podría influir en otros componentes críticos
• Qué tan solidarias son las partes interesadas con los próximos cambios
La Figura 112 proporciona un mapa simple para ayudar a priorizar a las partes interesadas en función de su influencia, su nivel de interés en el
programa o el grado en que el programa los afectará.
5.4 Involucrar a las partes interesadas
Después de identificar a las partes interesadas y un buen Patrocinador Ejecutivo, o una lista corta para elegir, es importante articular claramente
por qué cada una de las partes interesadas debe participar. Puede que no aprovechen la oportunidad. La persona o el equipo que dirige el
esfuerzo de gestión de datos debe articular las razones por las que cada parte interesada es necesaria para el éxito del programa. Esto significa
comprender sus objetivos personales y profesionales, y poder vincular el resultado de los procesos de gestión de datos con sus objetivos, para
que puedan ver una conexión directa.
Sin una comprensión de esta conexión directa, es posible que estén dispuestos a ayudar a corto plazo, pero no brindarán apoyo o asistencia a
largo plazo.
564 • DMBOK2
Conoce a sus
Jugador clave
Necesidades
Priorización
interesadas
Influencia
partes
las
de de
Partes interesadas
Más bajo Espectáculo
Prioridad Consideración
Interés de las partes interesadas
Figura 112 Mapa de intereses de las partes interesadas
6. Interacciones entre la DMO y otros organismos orientados a datos
Una vez que se establece el modelo operativo y se identifican los participantes, es hora de trasladar a las personas a los
nuevos roles autorizados. Hacer operativa la organización significa establecer los comités y comprometerse con las partes
interesadas. En un modelo centralizado, la mayor parte de la actividad de gestión de datos se controlará dentro de una
organización. Sin embargo, con un modelo de red o descentralizado, la organización de administración de datos deberá
trabajar con otros grupos que tengan un impacto significativo en la forma en que se administran los datos. Esos grupos son
típicamente:
• Organización del director de datos
• Órganos de Gobierno de Datos
• Calidad de datos
• Arquitectura empresarial
6.1 El director de datos
Si bien la mayoría de las empresas reconocen en algún nivel que los datos son un activo corporativo valioso, solo unas pocas
han designado un director de datos (CDO) para ayudar a cerrar la brecha entre la tecnología y los negocios y evangelizar una
estrategia de gestión de datos en toda la empresa a un nivel superior. Sin embargo, este papel va en aumento, ya que Gartner
estima que la mitad de todas las empresas reguladas emplearán un CDO para 2017 (Gartner, 2015).
Si bien los requisitos y funciones de un CDO son específicos de la cultura, la estructura organizativa y las necesidades comerciales
de cada empresa, muchos CDO tienden a ser en parte estrategas comerciales, asesores, administradores de calidad de datos y
embajadores de gestión de datos.
En 2014, Dataversity publicó una investigación que describe los mandatos comunes para un CDO.103 Estos incluyen:
• Establecer una estrategia de datos de la organización
• Alinear los requisitos centrados en datos con los recursos comerciales y de TI disponibles •
Establecer estándares, políticas y procedimientos de gobierno de datos • Brindar asesoramiento
(y quizás servicios) al negocio para iniciativas dependientes de datos, como
análisis, Big Data, calidad de datos y tecnologías de datos
• Evangelizar la importancia de los buenos principios de gestión de la información para internos y externos.
partes interesadas del negocio
• Supervisión del uso de datos en análisis y Business Intelligence
Los hallazgos de Dataversity también destacaron el cambio de enfoque en diferentes industrias.
Independientemente de la industria, es común que una organización de gestión de datos informe a través del CDO. En un modelo
operativo más descentralizado, el CDO es responsable de la estrategia de datos, pero los recursos que se encuentran en TI,
operaciones u otras líneas de negocios ejecutan esa estrategia. Algunas DMO se establecen inicialmente con el CDO simplemente
determinando la estrategia y, con el tiempo, otros aspectos de la gestión de datos, el gobierno y el análisis son definidos.
doblado bajo el paraguas de CDO a medida que se identifican eficiencias y economías de escala.
6.2 Gobierno de datos
Data Governance es el marco organizativo para establecer la estrategia, los objetivos y la política para administrar de manera efectiva
los datos corporativos. Consiste en los procesos, políticas, organización y tecnologías necesarias para gestionar y garantizar la
disponibilidad, usabilidad, integridad, consistencia, auditabilidad y seguridad de los datos. Dado que un programa de gobierno de
datos consiste en el interfuncionamiento de la estrategia, los estándares, las políticas y la comunicación con respecto a los datos,
tiene una relación sinérgica con la gestión de datos. La gobernanza proporciona un marco para que la gestión de datos se comprometa
y se alinee con las prioridades comerciales y las partes interesadas.
Dentro de un modelo centralizado, la Oficina de Gobierno de Datos puede informar a la Organización de Gestión de Datos o
viceversa. Cuando un programa de gestión de datos se centra en establecer las políticas y directrices necesarias para gestionar los
datos como un activo, la Oficina de gestión de datos puede actuar como líder y la Organización de gestión de datos informa a (o está
asociada a) la Oficina de gestión de datos. Esto ocurre muchas veces en entornos altamente regulados donde el énfasis está en la
política y la rendición de cuentas.
Incluso en un modelo muy descentralizado, debe haber una estrecha asociación entre la Oficina de Gobierno de Datos, que crea las
pautas y políticas sobre cómo se deben administrar los datos, y la Organización de Gestión de Datos que las implementa. John
Ladley aclara sucintamente esta relación: el gobierno de datos se trata de
103 http://bit.ly/2sTf3Cy.
566 • DMBOK2
'Hacer las cosas correctas' y la gestión de datos se trata de 'Hacer las cosas bien' (Ladley, 2012). Son dos lados de la ecuación
necesarios para producir datos valiosos. De esta manera, el gobierno de datos proporciona las órdenes de marcha para la gestión de
datos.
Lo que es más importante, debe haber una comprensión de esta sinergia y un acuerdo sobre los roles, las responsabilidades y las
responsabilidades que respaldan las pautas de gobierno de datos y la eficiencia de la gestión de datos.
Los participantes en un grupo de trabajo de gobernanza de datos pueden provenir de una organización de gestión de datos, y una
organización de gestión de datos puede usar el mandato y la "cobertura aérea" proporcionada por la supervisión de la gobernanza.
6.3 Calidad de los datos
La gestión de calidad de datos es una capacidad clave de una práctica y organización de gestión de datos. Muchas organizaciones
de gestión de datos comienzan centrándose en la calidad de los datos porque existe el deseo de medir y mejorar la calidad de los
datos en toda la organización. Es posible abordar la calidad de los datos dentro de una línea de negocio, o incluso dentro de una
aplicación, sin tener que involucrar a otros grupos ni gestionar complejidades multifuncionales. Sin embargo, a medida que madura
una práctica de calidad de datos, la organización se beneficiará de un enfoque unificado de la calidad de datos; por ejemplo,
estableciendo un Centro de Excelencia. El objetivo cambia a mejorar la calidad de los datos que se comparten entre líneas de negocios
o aplicaciones, a menudo con un enfoque en la gestión de datos maestros.
Es común que una organización de gestión de datos se desarrolle orgánicamente a partir de una iniciativa de calidad de datos, ya que
la inversión en mejorar la calidad de los datos agrega valor en toda la empresa y los esfuerzos asociados con la mejora de la calidad
se expanden a otras disciplinas como la gestión maestra, de referencia y de metadatos.
Un programa de calidad de datos puede evolucionar hacia modelos operativos similares a los de un programa general de gestión de
datos, aunque es raro que las funciones de calidad de datos se centralicen por completo en una empresa importante porque la
mayoría de los aspectos de la calidad de datos se ejecutan en una línea. de nivel de negocio o de aplicación. Debido a que un
programa de calidad de datos se puede descentralizar, conectar en red o ser híbrido (usando un enfoque de centro de excelencia),
alinee el modelo operativo de calidad de datos con el de la organización de gestión de datos en general, a fin de utilizar partes
interesadas, relaciones, responsabilidades y estándares coherentes. , procesos y
incluso herramientas.
6.4 Arquitectura empresarial
Un grupo de Arquitectura Empresarial diseña y documenta los planos maestros para que una organización articule y optimice cómo
cumplir sus objetivos estratégicos. Las disciplinas dentro de una práctica de Arquitectura Empresarial
incluir:
• Arquitectura tecnológica •
Arquitectura de aplicaciones •
Arquitectura de información (o datos)
• Arquitectura Empresarial
La arquitectura de datos es una capacidad clave de una organización de gestión de datos eficaz. Por lo tanto, los Arquitectos de datos
pueden sentarse en cualquier grupo, con una línea punteada al otro grupo.
Cuando los Arquitectos de datos se sientan dentro de una Organización de gestión de datos, por lo general interactúan con el resto de
sus pares de arquitectura a través de Juntas de revisión de arquitectura (ARB), comités que revisan y brindan orientación sobre la forma
en que los estándares de arquitectura se implementan o se ven afectados por proyectos y programas. Un ARB puede aprobar o
desaprobar nuevos proyectos y sistemas en función de su nivel de cumplimiento de los estándares arquitectónicos.
Cuando una organización no tiene arquitectos de datos, la gestión de datos puede interactuar con la organización de arquitectura de
varias maneras:
• A través del gobierno de datos: dado que tanto la gestión de datos como la arquitectura empresarial participan en un programa de
gobierno de datos, el grupo de trabajo de gobierno y la estructura del comité pueden proporcionar una plataforma para alinear
objetivos, expectativas, estándares y actividades.
• A través del ARB: A medida que los proyectos de gestión de datos se llevan al ARB, el grupo de Arquitectura
proporcionaría orientación, comentarios y aprobaciones.
• Adhoc: si no hay comités formales, entonces el líder de administración de datos debe reunirse periódicamente con el líder de
arquitectura para garantizar que haya un conocimiento y una comprensión compartidos de los proyectos y procesos que
impactan a la otra parte. Con el tiempo, la dificultad de manejar este proceso ad hoc probablemente conducirá al desarrollo
de un rol o comité formal para facilitar las discusiones y decisiones.
Si hubiera arquitectos de datos, representarían la arquitectura en los debates de gobernanza y liderarían
las discusiones en el ARB.
6.5 Gestión de una organización global
Las empresas globales enfrentan desafíos complejos de administración de datos basados en el volumen y la variedad de leyes y
regulaciones específicas de cada país, especialmente aquellas relacionadas con la privacidad y seguridad de ciertos tipos de datos.
Agregue estos problemas a los desafíos de administración típicos de una organización global (fuerza de trabajo distribuida, sistemas,
zonas horarias e idiomas), y la tarea de administrar datos de manera eficiente y efectiva puede parecer un ejercicio interminable de
pastoreo de gatos.
Las organizaciones globales deben prestar especial atención a:
• Cumplimiento de estándares •
Sincronización de procesos •
Alineación de responsabilidades •
Capacitación y comunicación • Monitoreo
y medición efectivos • Desarrollo de economías de
escala • Reducción de la duplicación de esfuerzos
568 • DMBOK2
A medida que los programas y organizaciones de gestión de datos se vuelven más globales, los modelos en red o federados se vuelven
más atractivos donde las responsabilidades se pueden alinear, se pueden seguir los estándares y los
todavía se pueden acomodar variaciones.
7. Funciones de gestión de datos
Los roles de gestión de datos se pueden definir a nivel funcional o individual. Los nombres de los roles diferirán entre organizaciones y
algunas organizaciones tendrán una mayor o menor necesidad de algunos de los roles.
Todos los roles de TI se pueden asignar a puntos en el ciclo de vida de los datos, por lo que todos afectan la gestión de datos, ya sea
directamente (como con un Arquitecto de datos que diseña un almacén de datos) o indirectamente (como con un Desarrollador web que
programa un sitio web). Del mismo modo, muchos roles comerciales crean, acceden o manipulan datos. Algunos roles, como el de analista
de calidad de datos, requieren una combinación de habilidades técnicas y conocimientos comerciales. Las funciones y roles que se
describen a continuación se enfocan en aquellos que están dirigidos a participar en la gestión de datos.
7.1 Roles organizacionales
Las organizaciones de administración de datos de TI brindan una variedad de servicios, desde datos, aplicaciones y arquitectura técnica
hasta administración de bases de datos. Una Organización de Servicios de Gestión de Datos centralizada se centra únicamente en la
gestión de datos. Este equipo puede incluir un ejecutivo de DM, otros gerentes de DM, arquitectos de datos, analistas de datos, analistas
de calidad de datos, administradores de bases de datos, administradores de seguridad de datos, especialistas en metadatos, modeladores
de datos, administradores de datos, arquitectos de almacenamiento de datos, arquitectos de integración de datos y analistas de inteligencia
empresarial. .
Un enfoque de servicios de gestión de datos federados incluirá un conjunto de unidades de TI, cada una centrada en una faceta de la
gestión de datos. Especialmente en las grandes organizaciones, las funciones de TI suelen estar descentralizadas. Por ejemplo, cada
función comercial puede tener su propio equipo de Desarrolladores de software. También se adopta un enfoque híbrido. Por ejemplo,
mientras que cada función comercial puede tener sus propios desarrolladores, la función DBA puede estar centralizada.
Las funciones comerciales centradas en la gestión de datos se asocian con mayor frecuencia con los equipos de Gobierno de datos o
Gestión de información empresarial. Por ejemplo, los administradores de datos suelen formar parte de una organización de gobierno de datos.
Dicha organización facilitará los órganos de Gobierno de Datos, como el Consejo de Gobierno de Datos.
7.2 Funciones individuales
Los roles individuales pueden definirse en negocios o TI. Algunos son roles híbridos que requieren conocimiento de sistemas y procesos
comerciales.
7.2.1 Funciones ejecutivas
Los ejecutivos de gestión de datos pueden estar en el lado comercial o tecnológico de la casa. El director de información y el director de
tecnología son funciones bien establecidas en TI. El concepto de director de datos en el lado comercial ha ganado mucha credibilidad en la última
década y muchas organizaciones han contratado CDO.
7.2.2 Funciones comerciales
Los roles comerciales se centran en gran medida en las funciones de gobierno de datos, especialmente en la administración. Los administradores
de datos suelen ser expertos en la materia reconocidos a quienes se les asigna la responsabilidad de los metadatos y la calidad de los datos de
las entidades comerciales, las áreas temáticas o las bases de datos. Los delegados juegan diferentes roles, dependiendo de las prioridades
organizacionales. El enfoque inicial de la administración a menudo es definir términos comerciales y valores válidos para sus áreas temáticas. En
muchas organizaciones, los Stewards también definen y mantienen los requisitos de calidad de datos y las reglas comerciales para los atributos
de datos asignados, ayudan a identificar y resolver problemas de datos y brindan información sobre estándares, políticas y procedimientos de datos.
Los delegados pueden funcionar a nivel de empresa, unidad de negocio o funcional. Su función puede ser formal ("administrador de datos" es
parte del título) o informal (administran datos, pero tienen otro título de trabajo).
Además de los administradores de datos, los analistas de procesos comerciales y los arquitectos de procesos contribuyen a garantizar que los
modelos de procesos comerciales y los procesos reales que crean datos sean sólidos y admitan usos posteriores.
Otros trabajadores del conocimiento basados en el negocio, como los consumidores analistas de negocios de datos e información que agregan
valor a los datos para la organización, contribuyen a la gestión general de los datos.
7.2.3 Funciones de TI
Los roles de TI incluyen diferentes tipos de arquitectos, desarrolladores en diferentes niveles, administradores de bases de datos y una variedad
de funciones de apoyo.
• Arquitecto de datos: analista sénior responsable de la arquitectura de datos y la integración de datos. Los arquitectos de datos pueden
trabajar a nivel empresarial o funcional. Los arquitectos de datos pueden especializarse en almacenamiento de datos, data marts y
sus procesos de integración asociados.
• Modelador de datos: responsable de capturar y modelar requisitos de datos, definiciones de datos, negocios
reglas, requisitos de calidad de datos y modelos de datos físicos y lógicos.
• Administrador del Modelo de Datos: Responsable del control de versiones y control de cambios del modelo de datos.
• Administrador de base de datos: responsable del diseño, implementación y soporte de datos estructurados
activos y el rendimiento de la tecnología que hace que los datos sean accesibles.
• Administrador de Seguridad de Datos: Responsable de garantizar el acceso controlado a los datos que requieren diferentes
niveles de protección.
570 • DMBOK2
• Arquitecto de integración de datos: desarrollador sénior de integración de datos responsable del diseño de tecnología
para integrar y mejorar la calidad de los activos de datos empresariales.
• Especialista en integración de datos: un diseñador o desarrollador de software responsable de implementar sistemas
para integrar (replicar, extraer, transformar, cargar) activos de datos por lotes o casi en tiempo real.
• Desarrollador de informes/análisis: un desarrollador de software responsable de crear informes y análisis
soluciones de aplicación.
• Arquitecto de Aplicaciones: Desarrollador senior responsable de la integración de sistemas de aplicaciones.
• Arquitecto Técnico: Ingeniero técnico senior responsable de coordinar e integrar la TI
infraestructura y la cartera de tecnología de TI.
• Ingeniero Técnico: Analista técnico sénior responsable de investigar, implementar, administrar y dar soporte a una parte
de la infraestructura de tecnología de la información.
• Administrador de la mesa de ayuda: responsable de manejar, rastrear y resolver problemas relacionados con el uso de
información, los sistemas de información o la infraestructura de TI.
• Auditor de TI: un auditor interno o externo de las responsabilidades de TI, incluida la calidad de los datos y la
seguridad.
7.2.4 Funciones híbridas
Los roles híbridos requieren una combinación de conocimientos comerciales y técnicos. Dependiendo de la organización, las personas en estos
roles pueden informar a través del área de TI o comercial.
• Analista de calidad de datos: responsable de determinar la idoneidad de los datos para su uso y monitorear la condición continua
de los datos; contribuye al análisis de la causa raíz de los problemas de datos y ayuda a la organización a identificar los
procesos comerciales y las mejoras técnicas que contribuyen a una mayor calidad
datos.
• Especialista en Metadatos: Responsable de la integración, control y entrega de Metadatos, incluida la administración de
repositorios de Metadatos.
• Arquitecto de Business Intelligence: Analista sénior de Business Intelligence responsable del diseño del entorno de usuario de Business
Intelligence.
• Analista/Administrador de Business Intelligence: Responsable de respaldar el uso efectivo de los datos de Business Intelligence por
parte de los profesionales de negocios.
• Gerente del programa de Business Intelligence: coordina los requisitos y las iniciativas de BI en toda la corporación y los integra en
un programa y una hoja de ruta coherentes y priorizados.
Aiken, Peter y Juanita Billings. Monetización de la gestión de datos: encontrar el valor en el activo más importante de su organización. Publicaciones de
Technics, LLC, 2013. Imprimir.
Aiken, Peter y Michael M. Gorman. El caso del director de datos: reformulación del CSuite para aprovechar su activo más valioso. Morgan Kaufmann,
2013. Imprimir.
Anderson, Carlos. Creación de una organización basada en datos. O'Reilly Media, 2015. Imprimir.
Arturo, Lisa. Big Data Marketing: Involucre a sus clientes de manera más efectiva y genere valor. Wiley, 2013. Imprimir.
Blokdijk, Gerard. Análisis de las partes interesadas: pasos sencillos para ganar, perspectivas y oportunidades para maximizar el éxito. Edición completa,
2015. Impreso.
Borek, Alejandro et al. Gestión total de riesgos de la información: maximizar el valor de los datos y los activos de información. Morgan Kaufmann, 2013.
Imprimir.
Brestoff, Nelson E. y William H. Inmon. Prevención de litigios: un sistema de alerta temprana para obtener un gran valor de Big Data. Business Expert
Press, 2015. Impreso.
Collier, Ken W. Agile Analytics: un enfoque basado en el valor para la inteligencia empresarial y el almacenamiento de datos. Addison Wesley
Professional, 2011. Imprimir. Desarrollo ágil de software Ser.
Decano, Jared. Big Data, minería de datos y aprendizaje automático: creación de valor para líderes empresariales y profesionales. Wiley, 2014. Imprimir.
Wiley y SAS Business Ser.
Dietrich, Brenda L., Emily C. Plachy y Maureen F. Norton. Análisis en toda la empresa: cómo IBM obtiene el valor comercial de Big Data y Analytics. IBM
Press, 2014. Impreso.
Freeman, R. Edward. Gestión estratégica: un enfoque de las partes interesadas. Prensa de la Universidad de Cambridge, 2010. Imprimir.
Gartner, Tom McCall, colaborador. "Comprender el rol del director de datos". 18 de febrero de 2015. http://gtnr.it/1RIDKa6.
Gemignani, Zach, et al. Fluidez de datos: empoderar a su organización con una comunicación de datos eficaz. Wiley, 2014.
Imprimir.
Gibbons, Paul. La ciencia del cambio organizacional exitoso: cómo los líderes establecen la estrategia, cambian el comportamiento y crean una cultura
ágil. Pearson FT Press, 2015. Imprimir.
Harrison, Michael I. Organizaciones de diagnóstico: métodos, modelos y procesos. 3ra ed. Publicaciones SAGE, Inc., 2004.
Imprimir. Métodos de Investigación Social Aplicada (Libro 8).
Harvard Business Review, John P. Kotter et al. Las 10 lecturas imprescindibles de HBR sobre la gestión del cambio. Harvard Business Review Press,
2011. Imprimir. Las 10 lecturas obligatorias de HBR.
Hatch, Mary Jo y Ann L. Cunliffe. Teoría de la organización: perspectivas modernas, simbólicas y posmodernas. 3ra ed.
Prensa de la Universidad de Oxford, 2013. Imprimir.
Hiatt, Jeffrey y Timothy Creasey. Gestión del cambio: el lado humano del cambio. Publicaciones del Centro de Aprendizaje Prosci, 2012. Imprimir.
Hillard, Roberto. Negocios impulsados por la información: cómo administrar datos e información para obtener la máxima ventaja. Wiley, 2010.
Imprimir.
Hoverstadt, Patrick. La Organización Fractal: Creando organizaciones sostenibles con el Modelo de Sistema Viable. Wiley, 2009. Imprimir.
Howson, Cindy. Business Intelligence exitosa: Libere el valor de BI y Big Data. 2ª ed. McgrawHill Osborne Media, 2013. Imprimir.
572 • DMBOK2
Kates, Amy y Jay R. Galbraith. Diseñando su organización: usando el modelo STAR para resolver 5 desafíos críticos de diseño. Jossey
Bass, 2007. Imprimir.
Kesler, Gregory y Amy Kates. Diseño y desempeño de la organización puente: cinco formas de activar un modelo de operación global.
JosseyBass, 2015. Imprimir.
Pequeño, Jasón. Lean Change Management: prácticas innovadoras para gestionar el cambio organizacional. Happy Melly Express, 2014. Imprimir.
Laboratorio Nacional de Energías Renovables. Libro de recursos de metodologías de análisis de partes interesadas. BiblioGov, 2012. Impreso.
Prokscha, Susana. Guía Práctica de Gestión de Datos Clínicos. 2ª ed. CRC Press, 2006. Impreso.
Schmarzo, Bill. Big Data MBA: conducción de estrategias comerciales con ciencia de datos. Wiley, 2015. Imprimir.
Soares, Sunil. El manual del director de datos para el gobierno de datos. Mc Press, 2015. Imprimir.
Stubbs, Evan. El valor de Business Analytics: identificar el camino hacia la rentabilidad. Wiley, 2011. Imprimir.
Tompkins, Jonathan R. Teoría de la Organización y Gestión Pública. Wadsworth Publishing, 2004. Imprimir.
Tsoukas, Haridimos y Christian Knudsen, eds. El manual de Oxford de teoría de la organización: perspectivas metateóricas. Prensa de la
Universidad de Oxford, 2005. Imprimir. Manuales de Oxford.
Verhoef, Peter C., Edwin Kooge y Natasha Walk. Creación de valor con Big Data Analytics: toma de decisiones de marketing más inteligentes.
Routledge, 2016. Imprimir.
Willows, David y Brian Bedrick, eds. Gestión eficaz de datos para las escuelas. John Catt Educational Ltd, 2012. Imprimir.
Escuelas Internacionales Efectivas Ser.
CAPÍTULO 1 7
Gestión de datos y organización
Gestión del cambio
1. Introducción
F
Para la mayoría de las organizaciones, mejorar las prácticas de gestión de datos requiere cambiar la forma en que trabajan las personas.
juntos y cómo entienden el papel de los datos en sus organizaciones, así como la forma en que utilizan los datos
e implementar tecnología para apoyar los procesos organizacionales. Prácticas exitosas de gestión de datos
requieren, entre otros factores:
• Aprender a administrar horizontalmente alineando las responsabilidades a lo largo de la cadena de valor de la información • Cambiar el
enfoque de la responsabilidad vertical (silo) a la administración compartida de la información • Evolucionar la calidad de la información
desde una preocupación comercial de nicho o el trabajo del departamento de TI
valor de la organización •
Cambiar el pensamiento sobre la calidad de la información de 'limpieza de datos y cuadros de mando' a una capacidad
organizativa más fundamental
• Implementar procesos para medir el costo de una mala gestión de datos y el valor de los datos disciplinados
administración
Este nivel de cambio no se logra a través de la tecnología, aunque el uso apropiado de herramientas de software puede respaldar la entrega. En
cambio, se logra a través de un enfoque cuidadoso y estructurado de la gestión del cambio en la organización. Se requerirá un cambio en todos los
niveles. Es fundamental gestionar y coordinar el cambio para evitar iniciativas sin salida, pérdida de confianza y daño a la credibilidad de la función
de gestión de la información y su liderazgo.
Los profesionales de la gestión de datos que entienden la gestión formal del cambio tendrán más éxito a la hora de generar cambios que ayuden a
sus organizaciones a obtener más valor de sus datos. Para ello, es importante entender:
• Por qué falla el cambio •
Los desencadenantes del cambio efectivo • Las
barreras para el cambio • Cómo experimentan
las personas el cambio
573
574 • DMBOK2
2. Leyes del cambio
Los expertos en gestión del cambio organizacional reconocen un conjunto de 'Leyes del Cambio' fundamentales que describen por qué el cambio
no es fácil. Reconocerlos al comienzo del proceso de cambio permite el éxito.
• Las organizaciones no cambian, la gente cambia: el cambio no sucede porque se anuncia una nueva organización o se implementa un
nuevo sistema. Tiene lugar cuando las personas se comportan de manera diferente porque reconocen el valor de hacerlo. El
proceso de mejorar las prácticas de gestión de datos e implementar el gobierno de datos formal tendrá efectos de gran alcance en
una organización. Se les pedirá a las personas que cambien la forma en que trabajan con los datos y cómo interactúan entre sí en
actividades que involucran
datos.
• La gente no se resiste al cambio. Se resisten a ser cambiados: las personas no adoptarán el cambio si lo ven como arbitrario o dictatorial.
Es más probable que cambien si han participado en la definición del cambio y si entienden la visión que impulsa el cambio, así como
cuándo y cómo tendrá lugar el cambio. Parte de la gestión de cambios para las iniciativas de datos implica trabajar con equipos para
desarrollar una comprensión organizacional del valor de las prácticas mejoradas de gestión de datos.
• Las cosas son como son porque se pusieron así: Puede haber buenas razones históricas para
siendo las cosas como son. En algún momento del pasado, alguien definió los requisitos comerciales, definió el proceso, diseñó
los sistemas, redactó la política o definió el modelo comercial que ahora requiere cambios. Comprender los orígenes de las
prácticas actuales de gestión de datos ayudará a la organización a evitar errores del pasado. Si a los miembros del personal se
les da voz en el cambio, es más probable que entiendan las nuevas iniciativas como mejoras.
• A menos que haya un impulso para cambiar, es probable que las cosas sigan igual: si desea mejorar,
hay que hacer algo diferente. Como dijo Einstein: "No se puede resolver un problema con el nivel de pensamiento que lo creó en
primer lugar".
• El cambio sería fácil si no fuera para todas las personas: la 'tecnología' del cambio suele ser fácil. Él
El desafío surge al tratar con la variación natural que surge en las personas.
El cambio requiere Agentes de Cambio, personas que presten atención a las personas y no solo a los sistemas. Los agentes de cambio escuchan
activamente a los empleados, clientes y otras partes interesadas para detectar los problemas antes de que surjan y ejecutar el cambio sin
problemas.
En última instancia, el cambio requiere una VISIÓN clara de los Objetivos de cambio comunicados de manera vívida y regular a las partes
interesadas para obtener compromiso, aceptación, respaldo y (lo que es más importante) apoyo continuo cuando surjan desafíos.
GESTIÓN DE DATOS Y GESTIÓN DEL CAMBIO ORGANIZACIONAL • 575
3. No gestionar un cambio: gestionar una transición
El experto en gestión del cambio William Bridges enfatiza la centralidad de la transición en el proceso de gestión del cambio. Él
define la transición como el proceso psicológico por el que pasan las personas para aceptar la nueva situación. Si bien muchas
personas piensan en el cambio únicamente en términos de un nuevo comienzo, Bridges afirma que el cambio implica pasar por tres
fases distintas, comenzando con el final del estado existente. Los finales son difíciles porque la gente necesita dejar ir las condiciones
existentes. Luego, la gente ingresa a la Zona Neutral, en la que el estado existente aún no ha terminado y el nuevo estado aún no
ha comenzado. El cambio se completa cuando se establece el nuevo estado (consulte la Tabla 34). De estas tres, la Zona Neutral
es la menos predecible y la más confusa, porque es una mezcla de lo antiguo y lo nuevo. Si las personas de la organización no
hacen la transición a través de la Zona Neutral, entonces la organización corre el riesgo de volver a los viejos hábitos y no lograr
mantener el cambio.
Bridges sostiene que la principal razón por la que fallan los cambios organizacionales es que las personas que impulsan el cambio
rara vez piensan en los finales y, por lo tanto, no gestionan el impacto de los finales en las personas. Él afirma: “La mayoría de las
organizaciones intentan comenzar con un principio, en lugar de terminar con él. No prestan atención a los finales. No reconocen la
existencia de la zona neutral y luego se preguntan por qué la gente tiene tanta dificultad con el cambio” (Bridges, 2009).
Al experimentar un cambio, todos los individuos pasan por las tres fases, pero a diferentes velocidades. La progresión depende de
factores como la experiencia pasada, el estilo preferido personal, el grado de implicación en el reconocimiento del problema y el
desarrollo de posibles soluciones, y la medida en que se sienten empujados hacia un cambio en lugar de avanzar hacia él
voluntariamente.
Tabla 34 Fases de Transición de Puentes
Fase de transición Descripción
El final • Cuando reconocemos que hay cosas que debemos dejar ir. • Cuando
reconocemos que hemos perdido algo. • Ejemplo: cambio de trabajo, incluso
cuando una persona elige cambiar de trabajo,
todavía hay pérdidas, como la pérdida de amigos cercanos que trabajan.
La Zona Neutral
• Cuando la antigua forma ha terminado pero la nueva forma aún no ha
llegado. • Cuando todo está en proceso de cambio y se siente como si nadie supiera cómo deberían ser
haciendo.
• Cuando las cosas son confusas y desordenadas. •
Ejemplo: mudarse a una nueva casa. Los primeros días o incluso meses después de
mudarse, la nueva casa aún no es el hogar y es muy probable que las cosas estén en orden.
confusión.
El nuevo comienzo • Cuando la nueva forma se siente cómoda, correcta y la única forma. •
Ejemplo: Tener un bebé. Después de unos meses en la zona neutral de confusión, llega a una
etapa en la que no puede imaginar la vida sin su nuevo bebé.
Bridges enfatiza que, si bien la primera tarea del administrador de cambios es comprender el destino (o
VISIÓN) y cómo llegar allí, el objetivo final de la gestión de la transición es convencer a las personas de que necesitan
576 • DMBOK2
para empezar el viaje. Al gestionar el cambio y la transición, el papel del Agente de Cambio, y de cualquier gerente o líder en el proceso,
es ayudar a las personas a reconocer que el proceso y las etapas de una transición son perfectamente
natural.
El nuevo comienzo
Cambio de incrustación
Valores de recongelación
La Zona Neutral
Finalizando
Gestión
Nivel
de
Perdiendo
Dejando ir
Descongelando el
Status quo
Hora
Figura 113 Fases de transición de los puentes
La siguiente lista de verificación para gestionar la transición resume los puntos clave que los gerentes deben tener en cuenta al ayudar a
las personas en la transición.
• El final
o Ayudar a todos a comprender los problemas actuales y por qué es necesario el cambio. o Identifique quién
es probable que pierda qué. Recuerda que la pérdida de amigos y el trabajo cercano
colegas es tan importante para algunos como la pérdida de estatus y poder para otros. o Las
pérdidas son subjetivas. Las cosas por las que una persona se aflige pueden no significar nada para otra. Aceptar
la importancia de las pérdidas subjetivas. No discuta con otros acerca de cómo perciben la pérdida y no se
sorprenda de las reacciones de otras personas ante la pérdida. o Espere y acepte signos de duelo y reconozca
las pérdidas abierta y comprensivamente. o Definir qué se acabó y qué no. La gente debe hacer la ruptura en algún
momento y tratar de
aferrarse a las viejas costumbres prolonga las dificultades.
o Tratar el pasado con respeto. La gente probablemente ha trabajado extremadamente duro en lo que pueden haber
sido condiciones muy difíciles. Reconócelo y demuestra que el trabajo es valorado.
o Mostrar cómo terminar algo asegura que las cosas que son importantes para las personas continúen y
mejorado.
o Dar información a la gente. Luego hágalo una y otra y otra vez en una variedad de formas escrito
información para salir y leer, así como la oportunidad de hablar y hacer preguntas.
o Utilice el análisis de las partes interesadas para trazar la mejor manera de acercarse a diferentes personas:
comprender cómo podrían ser necesarias sus perspectivas para iniciar el cambio y cuáles podrían ser los posibles
puntos de resistencia.
• La Zona Neutral
o Reconocer esto como una fase difícil (mezcla de lo antiguo y lo nuevo) pero que todos deben pasar por ella. o Involucrar a las
personas y trabajar juntas; darles tiempo y espacio para experimentar y probar
nuevas ideas.
o Ayudar a las personas a sentir que aún son valoradas. o
Elogie a las personas con buenas ideas, incluso si no todas las buenas ideas funcionan como se esperaba. el plan hacer
El modelo Study, Act (PDSA) fomenta probar cosas y aprender de cada ciclo.
o Dar información a las personas; hacerlo una y otra y otra vez en una variedad de formas. o Proporcionar
retroalimentación sobre los resultados de las ideas que se prueban y las decisiones que se toman.
• El nuevo comienzo
o No fuerce un comienzo antes de tiempo. o Asegúrese de
que las personas sepan qué papel deben desempeñar en el nuevo sistema. o Asegúrese
de que las políticas, los procedimientos y las prioridades sean claros; no envíe mensajes contradictorios. o Plan para
celebrar el nuevo comienzo y dar crédito a quienes han hecho el cambio. o Dar información a las personas; hacerlo una y otra
vez en una variedad de maneras.
4. Los ocho errores de gestión del cambio de Kotter
En Leading Change, John P. Kotter, uno de los investigadores más respetados en el campo de la gestión del cambio, describe ocho razones por
las que la organización no logra ejecutar el cambio. Estos brindan una perspectiva sobre los problemas que comúnmente surgen en el contexto de
la gestión de información y datos.
4.1 Error #1: Permitir demasiada complacencia
Según Kotter, el mayor error que cometen las personas cuando intentan cambiar las organizaciones es avanzar sin establecer primero un sentido
de urgencia lo suficientemente alto entre sus compañeros y superiores. (Esto está relacionado con la necesidad de aumentar la insatisfacción con
el statu quo identificado en la fórmula de Gleicher; consulte la Sección 6). El análisis de Kotter proporciona indicadores valiosos para los
administradores de cambios que buscan evitar los errores de los demás. Agentes de cambio
con frecuencia:
• Sobreestiman su capacidad para forzar grandes cambios en la organización • Subestiman
lo difícil que puede ser sacar a las personas de sus zonas de confort • No ven cómo sus acciones y enfoque
podrían reforzar el statu quo al aumentar la actitud defensiva
578 • DMBOK2
• Precipitarse donde los ángeles temen pisar: iniciar actividades de cambio sin suficiente comunicación de
qué cambio se requiere o por qué se requiere el cambio (la Visión)
• Confundir la urgencia con la ansiedad, que a su vez conduce al miedo y la resistencia a medida que las partes interesadas retroceden (a menudo
literalmente) en sus silos
Si bien es tentador pensar que frente a una crisis organizacional, la autocomplacencia no sería un problema, a menudo sucede lo
contrario. Las partes interesadas a menudo se aferran al statu quo frente a demasiadas demandas (a menudo conflictivas) de cambio
(que a menudo se procesan como 'si todo es importante, entonces nada es importante').
4.1.1 Ejemplos en el contexto de la gestión de la información
La Tabla 35 describe ejemplos de cómo la complacencia puede manifestarse en un contexto de gestión de la información:
Cuadro 35 Escenarios de conformidad
Escenario de ejemplo Cómo podría manifestarse
Respuesta a un cambio regulatorio “Estamos bien. No hemos sido multados bajo las reglas actuales”.
Respuesta al cambio comercial “Hemos estado apoyando el negocio con éxito durante años. Estaremos bien.
Respuesta al cambio tecnológico “Esa nueva tecnología no está probada. Nuestros sistemas actuales son estables y sabemos cómo
solucionar los problemas”.
Respuesta a problemas o errores “Podemos asignar un equipo de solución de problemas para eso y solucionar los problemas.
Es probable que haya algunas personas disponibles en [Insertar el nombre del
departamento o equipo aquí]”.
4.2 Error n.º 2: No crear una coalición de orientación lo suficientemente poderosa
Kotter identifica que un cambio importante es casi imposible sin el apoyo activo del jefe de la organización y sin una coalición de otros
líderes que se unan para guiar el cambio. El compromiso del liderazgo es especialmente importante en los esfuerzos de gobierno de
datos, ya que requieren cambios de comportamiento significativos.
Sin el compromiso de los principales líderes, el interés propio a corto plazo superará el argumento de los beneficios a largo plazo de
una mejor gobernanza.
Una Coalición de Orientación es un equipo poderoso y entusiasta de voluntarios de toda la organización que ayuda a implementar
nuevas estrategias y transformar la organización. Un desafío clave en el desarrollo de una Coalición de Orientación es identificar quién
debe participar. (Consulte la Sección 5.2.)
4.3 Error #3: Subestimar el poder de la visión
De nada sirve la urgencia y un fuerte equipo guía sin una visión clara y sensata del cambio. La visión proporciona el contexto del
esfuerzo de cambio. Ayuda a las personas a comprender el significado de cualquier componente individual.
Una visión bien definida y comunicada puede ayudar a impulsar el nivel de energía necesario para implementar adecuadamente el
cambio. Sin una declaración pública de visión para guiar la toma de decisiones, cada elección corre el riesgo de convertirse en un
debate y cualquier acción podría descarrilar la iniciativa de cambio o socavarla.
Visión no es lo mismo que planificación o gestión de programas. La visión no es el plan del proyecto o la carta del proyecto o un
desglose detallado de todos los componentes del cambio.
Una visión es una declaración clara y convincente de hacia dónde conduce el cambio.
Comunicar la visión significa conectarse con las personas. Para las iniciativas de gestión de datos, la visión debe articular los desafíos
con las prácticas de gestión de datos existentes, los beneficios de la mejora y el camino para llegar a un mejor estado futuro.
4.3.1 Ejemplo en Gestión de la Información
Con demasiada frecuencia, en la gestión de la información, la visión de un proyecto en particular se presenta como la implementación
de una nueva tecnología. La tecnología, aunque importante, no es el cambio ni la visión. Lo que la organización puede hacer con la
tecnología constituye la visión.
Por ejemplo, afirmar: "Implementaremos un nuevo conjunto integrado de informes y análisis financieros basado en [inserte el nombre
de la tecnología aquí] para fines del primer trimestre" es un objetivo loable y medible. Sin embargo, hace poco para comunicar una
declaración clara y convincente de hacia dónde conducirá el cambio.
Por otro lado, afirmando: “Mejoraremos la precisión y la puntualidad de los informes financieros y los haremos más fácilmente
disponibles para todas las partes interesadas. Una mejor comprensión de cómo los datos entran y salen de nuestros procesos de
informes respaldará la confianza en nuestros números, ahorrará tiempo y reducirá el estrés innecesario durante los procesos de fin
de período. Daremos nuestro primer paso para lograr esto mediante la implementación del [Sistema X] para fines del primer trimestre”,
aclara lo que se hará y por qué se hará. Si puede señalar los beneficios del cambio para la organización, generará apoyo para el
cambio.
4.4 Error #4: Comunicación insuficiente de la visión por un factor de 10, 100 o 1000
Incluso si todos están de acuerdo en que la situación actual es insatisfactoria, la gente no cambiará a menos que perciba los
beneficios del cambio como una mejora significativa sobre el status quo.
La comunicación coherente y eficaz de la visión, seguida de la acción, es fundamental para una gestión del cambio exitosa. Kotter
advierte que la comunicación se produce tanto en palabras como en hechos. La congruencia entre los dos es crítica para el éxito.
Nada acaba con un esfuerzo de cambio tan rápido como una situación en la que la gente recibe el mensaje: 'Haz lo que digo, no lo
que hago'.
580 • DMBOK2
4.5 Error #5: Permitir que los obstáculos bloqueen la visión
Las nuevas iniciativas fracasan cuando las personas se sienten impotentes ante los enormes obstáculos que se interponen en su camino,
incluso cuando aceptan plenamente la necesidad y la dirección del cambio propuesto. Como parte de su transformación, la organización
debe identificar y responder a diferentes tipos de obstáculos:
• Psicológicos: Los obstáculos que existen en la cabeza de las personas deben ser abordados en función de sus causas. Hacer
provienen del miedo, la falta de conocimiento o alguna otra causa?
• Estructural: Los obstáculos debidos a estructuras organizativas, como categorías laborales limitadas o sistemas de evaluación
del desempeño que obligan a las personas a elegir entre la Visión y su propio interés, deben abordarse como parte del
proceso de gestión del cambio. La gestión del cambio debe abordar los incentivos estructurales y los desincentivos al cambio.
• Resistencia activa: ¿Qué obstáculos existen debido a las personas que se niegan a adaptarse al nuevo conjunto de
circunstancias y que hacen demandas que son inconsistentes con la Transformación? Si los miembros clave de la
organización hacen los ruidos correctos sobre la visión del cambio pero no alteran sus comportamientos o recompensan los
comportamientos requeridos o continúan operando de manera incompatible, la ejecución de la visión
flaqueará y podría fallar.
Kotter hace un llamado a las "personas inteligentes" en las organizaciones para enfrentar estos obstáculos. Si no lo hacen, los demás se
sentirán impotentes y el cambio se verá socavado.
4.6 Error n.° 6: no lograr ganancias a corto plazo
El verdadero cambio lleva tiempo. Cualquiera que alguna vez se haya embarcado en un régimen de acondicionamiento físico o en un
plan para bajar de peso sabe que el secreto para seguir adelante es tener objetivos regulares que mantengan el impulso y la motivación
al marcar el progreso. Cualquier cosa que implique un compromiso a largo plazo y una inversión de esfuerzo y recursos requiere algún
elemento de retroalimentación temprana y regular del éxito.
Los esfuerzos de cambio complejos requieren metas a corto plazo en apoyo de objetivos a largo plazo. Alcanzar estos objetivos permite
que el equipo celebre y mantenga el impulso. La clave es crear la ganancia a corto plazo en lugar de simplemente esperarla. En las
transformaciones exitosas, los gerentes establecen metas tempranas de manera activa, las alcanzan y recompensan al equipo. Sin
esfuerzos sistemáticos para garantizar el éxito, es probable que el cambio fracase.
En un contexto de gestión de la información, los logros y objetivos a corto plazo a menudo surgen de la resolución de un problema
identificado. Por ejemplo, si el desarrollo de un Business Glossary es un producto clave de una iniciativa de gobierno de datos, una
ganancia a corto plazo podría provenir de resolver un problema relacionado con la comprensión inconsistente de los datos (es decir, dos
áreas comerciales informan resultados de KPI diferentes porque utilizaron diferentes reglas en sus cálculos).
Identificar el problema, resolverlo y vincular la solución a la visión general a largo plazo para el cambio permite que el equipo celebre ese objetivo y
demuestre la visión en acción. También proporciona una garantía valiosa para la comunicación sobre la visión y ayuda a reforzar el mensaje de
cambio.
4.7 Error #7: Declarar la victoria demasiado pronto
Con demasiada frecuencia en los proyectos de Cambio, particularmente los que se extienden durante varios años, existe la tentación de declarar el
éxito en la primera mejora importante del desempeño. Las ganancias rápidas y las ganancias tempranas son herramientas poderosas para mantener
el impulso y la moral. Sin embargo, cualquier sugerencia de que el trabajo está hecho suele ser un error. Hasta que los cambios se integren en la
cultura de la organización, los nuevos enfoques son frágiles y los viejos hábitos y prácticas pueden reafirmarse. Kotter sugiere que cambiar toda una
empresa puede llevar entre tres y diez años.
4.7.1 Ejemplo en contexto de gestión de información
El ejemplo clásico del síndrome de 'Misión cumplida' es el escenario en el que la implementación de una tecnología se ve como la ruta para mejorar
la gestión de la información o resolver un problema con la calidad o la confiabilidad de los datos. Una vez que se ha implementado la tecnología,
puede ser difícil mantener el proyecto en movimiento hacia la meta, especialmente si la visión general se ha definido de manera deficiente. La Tabla
36 captura varios ejemplos relacionados con las consecuencias de declarar la victoria demasiado pronto.
Tabla 36 Escenarios de Declarar la Victoria Demasiado Pronto
Escenario de ejemplo Cómo podría manifestarse
Abordar la calidad de los datos “Compramos una herramienta de calidad de datos. Eso está arreglado ahora”.
• Nadie en la organización está revisando o actuando sobre la calidad de los datos.
informes
Confundir la entrega de capacidades "Hemos implementado la pila de informes para la Regulación X. Ahora cumplimos con la
con la implementación y la operación legislación".
• Cambios en los requisitos reglamentarios •
Nadie está revisando ni actuando sobre los problemas identificados en los informes
Migración de datos “Todos los datos en el Sistema X ahora están en el Sistema Y”.
• Los recuentos de registros coinciden, pero los datos en el Sistema Y están incompletos, o
truncado debido a fallas en el proceso de migración. Manual
intervenciones necesarias
4.8 Error #8: Descuidar Anclar Cambios Firmemente en la Cultura Corporativa
Las organizaciones no cambian, las personas cambian. Hasta que los nuevos comportamientos se integren en las normas sociales y los valores
compartidos de una organización, están sujetos a la decadencia y la degradación tan pronto como se elimine el foco del esfuerzo de cambio. Kotter
es claro: ignoras la cultura a tu propio riesgo cuando participas en cualquier actividad de cambio.
582 • DMBOK2
Las dos claves para anclar el cambio en la cultura de la organización son:
• Mostrar conscientemente a las personas cómo comportamientos y actitudes específicos han influido en el desempeño. •
Tomarse el tiempo suficiente para incorporar el cambio de enfoque en la próxima generación de gestión.
Este riesgo destaca la importancia de los factores humanos en el cambio general que podría implementarse para generar mejoras en la
ejecución del gobierno de datos, la gestión y el uso de metadatos o las prácticas de calidad de datos (por nombrar solo tres).
Por ejemplo, una organización puede haber introducido un requisito de etiquetado de metadatos en toda la documentación para respaldar
los procesos de clasificación y archivo automatizados en su sistema de gestión de contenido. El personal comienza a cumplir en las
primeras semanas, pero a medida que pasa el tiempo, vuelven a los viejos hábitos y no etiquetan correctamente los documentos, lo que
genera una acumulación masiva de registros no clasificados que deben revisarse manualmente para adecuarlos a los requisitos de la
solución tecnológica.
Esto destaca el simple hecho de que las mejoras en la gestión de la información se obtienen a través de una combinación de procesos,
personas y tecnología. Muy a menudo se pasa por alto ese componente intermedio, lo que lleva a una entrega subóptima y a un
retroceso en el progreso realizado. Cuando se introducen nuevas tecnologías o nuevos procesos, es importante considerar cómo las
personas llevarán adelante el cambio y mantendrán las ganancias.
5. Proceso de ocho etapas de Kotter para un cambio importante
Además de los ocho errores de la gestión del cambio, Kotter reconoce un conjunto de obstáculos comunes para el cambio:
• Culturas centradas en el interior
• Burocracia paralizante • Política
parroquial
• Bajos niveles de confianza
• Falta de trabajo en equipo
• Arrogancia •
Falta o fracaso de liderazgo
• Miedo a lo desconocido
Para combatirlos, propone un modelo de ocho pasos para un cambio importante. El modelo de Kotter proporciona un marco dentro del
cual cada uno de estos problemas puede abordarse de una manera que respalde un cambio sostenible a largo plazo. Cada paso está
asociado con uno de los errores fundamentales que socavan los esfuerzos de transformación.
Los primeros cuatro pasos del modelo suavizan las posiciones arraigadas del statu quo. Como dice Kotter, este esfuerzo solo es
necesario porque el cambio no es fácil.
Los próximos tres pasos (5 a 7) introducen nuevas prácticas y formas de trabajar. El último paso bloquea los cambios en su lugar y
proporciona la plataforma para ganancias y mejoras futuras.
Kotter advierte que no hay atajos para seguir estos pasos. Todos los esfuerzos de cambio exitosos deben pasar por los ocho pasos.
Centrarse en los pasos 5, 6 y 7 es tentador. Sin embargo, eso no proporciona una base sólida para sostener el cambio (sin visión, sin
Coalición Guía, sin insatisfacción con el status quo). Del mismo modo, es importante reforzar cada paso a medida que avanza en el
proceso, utilizando ganancias rápidas para reforzar la visión y la comunicación y resaltar los problemas con el statu quo.
1Estableciendo un Sentido de 5Empoderamiento de base amplia
Urgencia Acción
2Ceating the Guiding Coalition 6Crear ganancias a corto plazo
3Desarrollar una Visión y un 7Consolidación de Ganancias y
Estrategia Producir más cambios
4Comunicar el Cambio 8Anclaje de nuevos enfoques en la
Visión cultura
Figura 114 Proceso de ocho etapas de Kotter para un cambio importante
5.1 Establecer un sentido de urgencia
Las personas encontrarán mil maneras de retener la cooperación de algo que creen que es innecesario. Se requiere un sentido de
urgencia claro y convincente para motivar a una masa crítica suficiente de personas para apoyar un esfuerzo de cambio. Ganar la
cooperación y la colaboración requiere una llamada de reunión.
Lo opuesto a la urgencia es la complacencia. Cuando la autocomplacencia es alta, es difícil, si no imposible, reunir un grupo
suficientemente poderoso para crear la visión del cambio y guiar el esfuerzo de cambio. En raras ocasiones, las personas pueden hacer
algún progreso frente a la autocomplacencia, pero esto es casi inevitablemente insostenible.
En el contexto de la gestión de la información, varios factores pueden crear una sensación de urgencia:
• Cambios regulatorios •
Amenazas a la seguridad de la información •
Riesgos a la continuidad del negocio •
Cambios a la estrategia comercial • Fusiones
y adquisiciones • Auditoría regulatoria o
amenazas de litigios • Cambios a la tecnología •
Cambios a la capacidad de los competidores en
el mercado • Comentarios de los medios acerca de una
organización o un problemas de gestión de la información de la industria
584 • DMBOK2
5.1.1 Fuentes de complacencia
Kotter identifica nueve razones por las que las organizaciones y las personas pueden ser complacientes. (Ver Figura 115)
• En ausencia de una crisis visible, es difícil generar un sentido de urgencia. • Las trampas del éxito pueden
ahogar la urgencia de algunas situaciones. • Medir al personal contra estándares de bajo desempeño o
estándares que no se comparan con los externos
puntos de referencia o tendencias internas a largo plazo.
• Las metas funcionales demasiado estrechas, con diferentes métricas de desempeño para diferentes unidades funcionales, pueden conducir a
una situación en la que nadie es responsable cuando el desempeño general de la organización es deficiente o sufre.
• Si los sistemas de control y planificación interna están (o pueden estar) amañados o manipulados para hacerlo más fácil para todos
para alcanzar sus objetivos, es fácil ser complaciente.
• Si la única fuente de retroalimentación del desempeño proviene de los sistemas internos defectuosos, no hay verificación de cordura
de la corrección de la complacencia.
• Cuando se identifican problemas o cuando se recopilan comentarios externos sobre el desempeño, a menudo se los ataca por ser perjudiciales
para la moral, perjudiciales para los demás o susceptibles de provocar una discusión. En lugar de tomar la información como entrada para una
evaluación del desempeño de la organización, la cultura es 'matar al mensajero'.
• Por razones psicológicas muy simples, la gente no acepta las cosas que no quiere escuchar. Cuándo
aparece evidencia de un gran problema, las personas a menudo ignorarán la información o la reinterpretarán de una manera menos
dolorosa.
• Incluso en organizaciones donde los primeros ocho desafíos no son significativos, existe el riesgo de que 'feliz
hablar' de la alta dirección o de figuras de alto nivel en la organización puede crear una sensación injustificada de seguridad y éxito. A menudo,
esta 'charla feliz' es el resultado de una historia de éxitos pasados. El éxito pasado puede dar a las personas un ego y crear una cultura
arrogante. Ambos factores pueden mantener bajo el sentido de urgencia y obstaculizar el cambio.
Una buena regla general en cualquier iniciativa de cambio es nunca subestimar el poder de las fuerzas que podrían reforzar la complacencia y promover el
statu quo. El desafío de la autocomplacencia debe abordarse. Una organización no puede tomar ninguna decisión importante sin abordar los problemas
reales.
5.1.2 Subiendo el nivel de urgencia
Para elevar el nivel de urgencia se requiere eliminar las fuentes de complacencia o reducir su impacto.
Crear un fuerte sentido de urgencia requiere que los líderes tomen medidas audaces o incluso arriesgadas. Vale la pena recordar cómo Deming amonestó
a la gerencia a instituir el liderazgo como parte de sus 14 Puntos de Transformación.104
104 En Out of the Crisis (1982), W. Edwards Deming publicó sus 14 puntos para la transformación de la gestión.
http://bit.ly/1KJ3JIS.
Ausencia de una crisis
importante y visible
demasiados
visibles
Capacidad humana para negar los
recursos
problemas, especialmente
cuando está ocupado o estresado
Estándares
Demasiado ''Feliz
de desempeño
Talk'' (Grupo de Pensamiento) general bajos
Interno
'' Matar a la
medición
Mensajero''
Candor bajo/Bajo centrándose en el
Confrontación desempeño incorrecto
medidas
Culturas
Falta de Organizativo
Estructuras que
retroalimentación
del desempeño enfocan a los empleados
en objetivos funcionales
de fuentes externas.
estrechos
Complacencia
Figura 115 Fuentes de complacencia
Negrita significa hacer algo que podría causar dolor a corto plazo, no solo algo que se ve bien en un correo electrónico de marketing. En
otras palabras, requiere la adopción de la nueva filosofía (tomando prestado nuevamente de Deming).
Los movimientos lo suficientemente audaces como para reducir la complacencia tienden a causar conflictos y ansiedad a corto plazo.
Sin embargo, si el conflicto y la ansiedad se pueden canalizar hacia la visión de cambio, entonces un líder puede capitalizar la
incomodidad a corto plazo para construir metas a largo plazo.
Los movimientos audaces son difíciles en ausencia de un liderazgo que apoye y respalde. Los altos directivos cautelosos que no pueden
aumentar el sentido de urgencia reducirán la capacidad de cambio de una organización.
5.1.3 Uso de crisis con cuidado
Una forma de aumentar los niveles de urgencia es aferrarse a una crisis visible. A veces se dice que un cambio importante no es posible
hasta que la propia supervivencia económica de la organización está en peligro. Sin embargo, no es necesariamente que la
586 • DMBOK2
el cambio viene incluso entonces. Una crisis económica o financiera en una organización a menudo puede resultar en que los recursos
escasos pero necesarios sean difíciles de conseguir para apoyar la visión del cambio.
Es posible crear una crisis percibida al bombardear la organización con información sobre problemas, problemas potenciales,
oportunidades potenciales o al establecer metas ambiciosas que alteran el statu quo. Kotter sugiere que a menudo es más fácil crear un
problema que (casualmente) tiene el plan para abordar.
5.1.4 El papel de los gerentes de nivel medio y bajo
Según la escala del objetivo del cambio (p. ej., un departamento o unidad de negocio versus una organización completa), los jugadores
clave serán los gerentes a cargo de esa unidad. Deberán poder reducir la complacencia en los equipos bajo su control directo. Si tienen
suficiente autonomía, pueden hacerlo independientemente del ritmo de cambio en el resto de la organización.
Si no hay suficiente autonomía, entonces un esfuerzo de cambio en una pequeña unidad puede estar condenado desde el principio
cuando las fuerzas externas de la inercia se presenten. A menudo, los altos ejecutivos necesitan reducir esas fuerzas. Sin embargo, medio o
Los gerentes de nivel inferior pueden impulsar este tipo de cambio si actúan de manera estratégica. Por ejemplo, si utilizan el análisis
para mostrar claramente el impacto de no realizar el cambio requerido en un proyecto estratégico clave. Esto es particularmente efectivo
cuando el debate puede difundirse dirigiéndolo a un grupo externo, como una consultoría externa que puede haber ayudado con el
análisis.
5.1.5 ¿Cuánta urgencia es suficiente?
Un sentido de urgencia acerca de un problema lleva a la gente a concluir que el statu quo es inaceptable. Para sostener la transformación
a largo plazo, se requiere el apoyo de una masa crítica de gerentes. Kotter sugiere 75%.
Sin embargo, crear demasiada urgencia puede ser contraproducente. Demasiada urgencia puede resultar en visiones contrapuestas de
cambio o causar un enfoque en 'apagar incendios'.
Un sentido de urgencia suficientemente convincente ayudará a iniciar el proceso de cambio y le dará impulso.
La urgencia suficiente también ayudará a obtener el nivel adecuado de liderazgo en la Coalición de Orientadores. En última instancia, el
sentido de urgencia debe ser lo suficientemente fuerte como para evitar que la autocomplacencia se reafirme después de lograr los
éxitos iniciales. Un enfoque clave es aprovechar la 'voz del cliente' y hablar con clientes externos, proveedores, accionistas u otras
partes interesadas sobre su perspectiva sobre el nivel de urgencia que se está tratando.
creado.
5.2 La Coalición Orientadora
Ninguna persona tiene todas las respuestas o todos los conocimientos necesarios para crear una visión, o tiene el rango correcto y la
variación de conexiones para respaldar la comunicación efectiva de una visión. Para un cambio exitoso, dos
deben evitarse escenarios:
• El CEO solitario / Campeón solitario • El Comité
de Baja Credibilidad
El escenario del CEO solitario pone el éxito o el fracaso del esfuerzo de cambio en manos de una sola persona. El ritmo de cambio en la
mayoría de las organizaciones en estos días es tal que una sola persona no puede administrarlo todo. El ritmo de la toma de decisiones y la
comunicación se hace más lento, a menos que se tomen decisiones sin una evaluación completa de los problemas. Cualquiera de las opciones
es una receta para el fracaso.
El Comité de Baja Credibilidad surge donde un campeón capaz recibe un 'grupo de trabajo' con representantes de una variedad de
departamentos funcionales (y tal vez algunos consultores externos). Lo que le falta al grupo de trabajo es representación suficiente (si la hay)
de personas de alto nivel en el orden jerárquico ejecutivo. Si se considera "importante pero no tanto " (nuevamente, debido a la falta de
compromiso de los altos mandos), las personas no se sienten motivadas para comprender realmente la situación. Inevitablemente, el grupo de
trabajo falla.
Es fundamental crear una Coalición Rectora adecuada que tenga el compromiso de gestión necesario para apoyar la urgencia de la necesidad
de cambio. Además, el equipo debe respaldar la toma de decisiones efectiva, lo que requiere altos niveles de confianza dentro del equipo. Una
Coalición de Orientación que trabaja en equipo puede procesar más información más rápido. También acelera la implementación de ideas
porque los tomadores de decisiones con poder están realmente informados y comprometidos con las decisiones clave.
Una Coalición de Orientación eficaz tiene cuatro características clave:
• Posición de poder: ¿Hay suficientes jugadores clave a bordo, especialmente los principales gerentes de línea, para que aquellos que
quedan fuera no pueden bloquear fácilmente el
progreso? • Experiencia: ¿Están adecuadamente representados los puntos de vista relevantes para que los interesados informados e inteligentes
se tomarán decisiones?
• Credibilidad: ¿Hay suficientes personas con buena reputación en la organización en el equipo para que sea
¿tomado en serio?
• Liderazgo: ¿Tiene el equipo suficientes líderes probados a bordo para impulsar el proceso de cambio?
El liderazgo es una preocupación clave. Debe haber un buen equilibrio entre la gestión y las habilidades de liderazgo en la Coalición de
Orientación. La gerencia mantiene todo el proceso bajo control. El liderazgo impulsa el cambio. Uno
sin el otro no se logrará un resultado sostenible.
Los temas clave que surgen en el contexto de la construcción de su Coalición de Orientación incluyen:
¿Cuántas personas necesito para ayudarme a definir y guiar este cambio?
La respuesta a esto es un dolorosamente parecido a un consultor "Depende", pero el tamaño de la coalición se relaciona con el tamaño del
grupo general que está siendo influenciado. Es necesario lograr un equilibrio entre tener un grupo demasiado grande y tener un grupo que deje
a las partes interesadas clave sintiéndose 'fuera de la tienda'.
¿Quién debería participar o invitarse a unirse a la Coalición de Orientadores?
La Coalición de Orientadores se diferencia de un comité directivo formal de un proyecto o programa en que debe proporcionar una plataforma
para ejercer influencia en toda la organización. Como tal, la coalición necesita incluir representantes de
588 • DMBOK2
diferentes comunidades de interesados. Sin embargo, tampoco es un foro general de recopilación de requisitos de las partes interesadas.
Busque perspectivas de personas que puedan verse afectadas en la cadena de valor de la información de la organización.
Un atributo clave de los miembros de la Coalición de Orientadores es su capacidad para influir en sus pares, ya sea a través de la autoridad
formal en la jerarquía oa través de su estatus y experiencia en la organización.
El comportamiento es clave en Guiding Coalition.
En la formulación de la Coalición Guía, los líderes del cambio deben evitar comportamientos que debiliten la eficacia, la función y el alcance
del equipo. Por ejemplo, evita:
• Negativos: Los detractores pueden obstaculizar el diálogo positivo y abierto necesario para que la Coalición de Orientadores
desarrollar ideas creativas, para refinar, implementar y evolucionar la visión del cambio e identificar oportunidades de
crecimiento.
• Distracción: Los miembros del equipo de la Coalición de Orientación deben concentrarse en la actividad de cambio. Las personas
desenfocadas pueden desviar al equipo, lo que puede provocar retrasos o la imposibilidad de capitalizar las victorias tempranas.
• Egoísmo: Los esfuerzos de Guiding Coalition mueven a la organización como un todo y afectan a todos.
No se debe permitir que las agendas ocultas descarrilen los esfuerzos del equipo.
5.2.1 La importancia del liderazgo efectivo en la coalición
Hay una diferencia entre la gestión y el liderazgo. Una Coalición de Orientación con buenos gerentes pero sin líderes no tendrá éxito. El
liderazgo faltante se puede abordar contratando desde afuera, promoviendo líderes desde adentro y alentando al personal a asumir el desafío
de liderar.
Al armar su coalición, debe tener cuidado con lo que Kotter llama 'egos', 'serpientes' y 'jugadores reacios'. Los 'egos' son individuos que llenan
la habitación y no permiten que otros contribuyan. Las 'serpientes' son personas que crean y propagan desconfianza y desconfianza. Los
'Jugadores reacios' son (generalmente) figuras de alto nivel que ven una necesidad moderada del cambio pero no comprenden completamente
la urgencia.
Cualquiera de estos tipos de personalidad puede secuestrar o socavar el esfuerzo de cambio. Se deben hacer esfuerzos para mantenerlos
fuera del equipo o administrarlos de cerca para mantenerlos en el mensaje.
En el contexto de una iniciativa de cambio de gestión de la información, Guiding Coalition puede ayudar a la organización a identificar
oportunidades para vincular iniciativas en diferentes áreas que están involucradas en diferentes aspectos del mismo cambio general.
Por ejemplo, en respuesta a un requisito reglamentario, el abogado interno de una empresa puede haber comenzado a desarrollar un mapa
de flujos de datos y procesos en la organización. Al mismo tiempo, una iniciativa de almacenamiento de datos puede haber comenzado a
mapear el linaje de los datos para verificar la precisión y calidad de los informes.
Un líder de cambio de gobierno de datos podría reunir al jefe legal y al jefe de informes en su Coalición de Guía para mejorar la
documentación y el control de los procesos de información en el contexto del gobierno de datos. Esto, a su vez, podría requerir aportes
de los equipos de primera línea que usan y crean datos para comprender los impactos de cualquier cambio propuesto.
En última instancia, una buena comprensión de la cadena de valor de la información ayudará a identificar candidatos potenciales para
incluir en la Coalición de Orientación.
5.2.3 Construyendo un Equipo Efectivo
Un equipo eficaz se basa en dos fundamentos simples: la confianza y un objetivo común. La falta de confianza a menudo se debe a la
falta de comunicación y otros factores, como la rivalidad fuera de lugar. La clásica división 'Negocios vs. TI' es un buen ejemplo de dónde
se rompe la confianza. Para generar confianza, participe en actividades de formación de equipos que creen y promuevan la comprensión,
el respeto y el cuidado mutuos. Sin embargo, para lograr ese entendimiento mutuo, se debe tener cuidado de evitar el 'pensamiento
grupal'.
5.2.4 Combatir el pensamiento grupal
'Group Think' es un efecto psicológico que surge en grupos altamente coherentes y cohesivos, particularmente aquellos que están
aislados de fuentes de información que podrían contradecir sus opiniones, o aquellos que están dominados por un líder que alienta a las
personas a estar de acuerdo con su posición. en lugar de abrir la discusión.
En Group Think, todos aceptan una propuesta incluso cuando tienen reservas al respecto. Group Think probablemente esté funcionando
si:
• Nadie pone objeciones
• No se ofrecen alternativas
• Las diferentes perspectivas se descartan rápidamente y mueren para siempre
• No se busca activamente información que pueda desafiar el pensamiento
Para prevenir el Pensamiento Grupal es importante:
• Anime a todos los participantes a seguir el método científico de recopilación de datos para ayudar a comprender el
naturaleza y causas de un problema
• Desarrollar una lista de criterios para evaluar todas las decisiones
• Aprender a trabajar juntos de manera eficiente para que el Pensamiento grupal no sea el atajo para hacer las cosas más rápido •
Fomentar la lluvia de ideas • Los líderes deben hablar al final • Buscar activamente conocimiento externo y aportes a las reuniones
• Una vez que se haya identificado una solución, haga que el equipo desarrolle no solo un plan sino también un 'Plan B' (que
los obliga a repensar las suposiciones en el plan original)
590 • DMBOK2
Group Think puede surgir en una variedad de contextos. Un área potencial es la tradicional 'división entre negocios y TI', en la que diferentes
partes de la organización se resisten a los cambios propuestos por la otra. Otro escenario potencial es donde el objetivo de la organización es
volverse impulsado por los datos con un enfoque en el análisis y la recopilación de datos, lo que puede resultar en problemas de privacidad,
seguridad o éticos en relación con el manejo de la información que se descartan o se les quita prioridad en el plan de trabajo general.
Hay muchas razones para aplicar la disciplina de gobierno de datos en las organizaciones. Una función clave es garantizar la claridad sobre
los modelos y métodos que se aplicarán. Esta claridad permitirá que cuestiones como la división entre empresas y TI o el equilibrio de
prioridades contrapuestas se aborden de forma adecuada y coherente.
5.2.6 Objetivos comunes
Si cada miembro de la Coalición de Orientadores está tirando en una dirección diferente, la confianza se romperá.
Los objetivos típicos que vinculan a las personas son el compromiso con la excelencia o el deseo de que la organización se desempeñe al
más alto nivel posible en un área determinada. Estos objetivos no deben confundirse con la visión de cambio, sino que deben ser
complementarios.
5.3 Desarrollo de una visión y estrategia
Un error común en los esfuerzos de gestión del cambio es confiar en el decreto autoritario o en la microgestión para poner en marcha el
cambio. Ningún enfoque es eficaz si la situación de cambio es compleja.
Si el objetivo es el cambio de comportamiento, a menos que el jefe sea muy poderoso, los enfoques de decretos autoritarios funcionan mal
incluso en situaciones simples. Sin 'el poder de los reyes' detrás, es poco probable que un decreto autoritario rompa todas las fuerzas de
resistencia. Los Agentes de Cambio tienden a ser ignorados, socavados o manipulados.
Casi inevitablemente, algún opositor al cambio descubrirá el farol del Agente de Cambio para poner a prueba la autoridad y la influencia detrás
del proceso de cambio.
La microgestión trata de sortear esta debilidad definiendo en detalle específico lo que deben hacer los empleados y luego monitoreando el
cumplimiento. Esto puede superar algunas de las barreras para el cambio pero, con el tiempo, llevará más tiempo, ya que la gerencia tiene
que dedicar más tiempo a detallar las prácticas y métodos de trabajo para los nuevos comportamientos modificados a medida que aumenta
el nivel de complejidad asociado con el cambio.
El único enfoque que permite a los Agentes de Cambio romper el statu quo de manera consistente es basar el cambio en una visión clara y
convincente que proporcione impulso.
Autoritario
Decreto Visión de microgestión
Fuerzas que apoyan el statu quo
Figura 116 La visión rompe el statu quo
5.3.1 Por qué la visión es esencial
Una visión es una imagen del futuro con algún comentario implícito o explícito sobre por qué las personas deberían esforzarse por crear
ese futuro. Una buena visión comparte tres propósitos importantes: clarificación, motivación y alineación.
• Aclaración: una buena visión aclara la dirección del cambio y simplifica una serie de decisiones más detalladas mediante el
establecimiento de parámetros clave. Una visión eficaz (y estrategias de respaldo de respaldo) ayuda a resolver los
problemas que surgen de los desacuerdos sobre la dirección o la confusión sobre la motivación o los impulsores del cambio.
Se pueden evitar debates interminables con una simple pregunta: ¿La acción planeada está en línea con la visión? De manera
similar, la visión puede ayudar a despejar el desorden, lo que permite que el equipo centre sus esfuerzos en proyectos
prioritarios que contribuyen al esfuerzo de transformación.
• Motivación: Una visión clara motiva a las personas a dar pasos en la dirección correcta, incluso si los pasos iniciales son
personalmente dolorosos. Esto es particularmente cierto en organizaciones donde las personas se ven obligadas a salir de
sus zonas de confort de forma regular. Cuando el futuro es deprimente y desmoralizador, la visión correcta puede brindarle a
la gente una causa atractiva por la cual luchar.
• Alineación: una visión convincente ayuda a alinear a las personas y coordinar las acciones de los motivados .
personas de manera eficiente. La alternativa es tener una ráfaga de directivas detalladas o reuniones interminables.
La experiencia muestra que sin un sentido compartido de dirección, las personas interdependientes pueden terminar en
ciclos de conflicto constante y reuniones ininterrumpidas.
592 • DMBOK2
5.3.2 La naturaleza de una visión eficaz
Una visión puede ser mundana y simple. No es necesario que sea grandioso o general. Es un elemento en el sistema de herramientas y
procesos para el cambio; este sistema también incluye estrategias, planes, presupuestos y más. Sin embargo, una visión es un factor muy
importante porque exige que los equipos se centren en mejoras tangibles.
Una visión eficaz tiene varias características clave:
• Imaginable: Transmite una imagen de cómo se ve el futuro. • Deseable: apela a
los intereses a largo plazo de empleados, clientes, accionistas y otros
partes interesadas.
• Factible: Comprende metas realistas y alcanzables. • Enfocado: es
lo suficientemente claro como para proporcionar una guía en la toma de decisiones. •
Flexible: es lo suficientemente general como para permitir que las personas tomen la iniciativa y permitir alternativas
planes y respuestas cuando cambian las condiciones o restricciones.
• Comunicable: es fácil de compartir y comunicar en cinco minutos o menos.
La prueba clave para la efectividad de una visión es qué tan fácil es imaginarla y qué tan deseable es. Una buena visión puede exigir
sacrificio, pero debe mantener en el alcance los intereses a largo plazo de las personas involucradas. Las visiones que no se enfocan a largo
plazo en los beneficios para las personas eventualmente se ven desafiadas. Asimismo, la visión debe estar enraizada en la realidad del
mercado del producto o servicio. En la mayoría de los mercados, la realidad es que el cliente final debe ser considerado constantemente.
Las preguntas clave que se deben hacer son:
• Si esto se hiciera realidad, ¿cómo afectaría a los clientes (internos y externos)? • Si esto se
hiciera realidad, ¿cómo afectaría a los accionistas? ¿Los hará más felices? ¿Les proporcionará valor a largo plazo? • Si esto
se hiciera realidad, ¿cómo afectaría a los empleados? ¿Sería el lugar de trabajo mejor, más feliz, menos
estresado, más satisfactorio? ¿Seremos capaces de convertirnos en un mejor lugar para trabajar?
Otra prueba clave es la viabilidad estratégica de la visión. Una visión factible es más que un deseo. Puede estirar los recursos y las
capacidades, pero la gente reconoce que se puede alcanzar. Sin embargo, factible no significa fácil. La visión debe ser lo suficientemente
desafiante como para forzar un replanteamiento fundamental. Independientemente de los objetivos ambiciosos que se establezcan, la
organización debe basar esa visión en una comprensión racional de las tendencias del mercado y la capacidad de la organización.
La visión debe estar lo suficientemente enfocada para guiar a las personas, pero no tan rígida como para atar al personal a modos de
comportamiento cada vez más irracionales. A menudo, el mejor enfoque es apuntar a la simplicidad de la visión y, al mismo tiempo, incorporar
suficientes ganchos específicos para que la visión siga siendo una piedra angular valiosa y un punto de referencia para la toma de decisiones:
Nuestro objetivo es convertirnos en el líder mundial en nuestra industria dentro de 5 años. En este contexto, el liderazgo significa administrar
la información de manera más efectiva para generar mayores ingresos, más ganancias y un lugar de trabajo más gratificante para nuestra
gente. Alcanzar esta ambición requerirá una base sólida de confianza en nuestra capacidad para hacer
decisiones, claridad en nuestras comunicaciones internas y externas, una mejor comprensión del panorama de la información en el que
operamos e inversiones racionales en herramientas y tecnologías apropiadas para respaldar una cultura y una ética basadas en datos.
Esta cultura contará con la confianza y la admiración de accionistas, clientes, empleados,
y comunidades.
5.3.3 Creando la Visión Efectiva
Kotter advierte que crear una visión efectiva es un proceso iterativo que debe tener varios elementos claros para ser
exitoso.
• Primer borrador: Un solo individuo hace una declaración inicial que refleja sus sueños y las necesidades de la
mercado
• Rol de la Coalición de Orientadores: La Coalición de Orientadores reelabora el primer borrador para adaptarlo a la estrategia más amplia .
perspectiva.
• Importancia del trabajo en equipo: El proceso grupal nunca funciona bien sin trabajo en equipo. Alentar gente
participar y contribuir.
• Papel de la cabeza y el corazón: tanto el pensamiento analítico como el "sueño del cielo azul" son necesarios en todo momento.
la actividad.
• Desorden del proceso: Este no será un procedimiento sencillo; habrá mucho debate, reelaboración y cambio. Si no lo
hay, algo anda mal con la visión o el equipo.
• Marco de tiempo: La actividad no es un trato de una sola reunión. Puede llevar semanas, meses o incluso más. Idealmente,
la visión debe estar en constante evolución. •
Producto final: Una dirección para el futuro que es deseable, factible, enfocada, flexible y puede ser
transportado en cinco minutos o menos.
Visión
Una imagen sensata y
Liderazgo
atractiva del futuro.
Estrategias
Una lógica de cómo la visión
puede lograrse
planes
Pasos y cronogramas específicos
Gestión para implementar estrategias
Presupuestos
Planes convertidos en financieros
proyecciones y metas
Figura 117 Contraste de gestión/liderazgo
594 • DMBOK2
5.4 Comunicar la visión del cambio
Una visión solo tiene poder cuando los involucrados en la actividad de cambio tienen un entendimiento común de sus objetivos y dirección,
una perspectiva común sobre el futuro deseado. Los problemas que comúnmente surgen con la comunicación de la
visión incluyen:
• Falta de comunicación, o de comunicar lo suficiente. • Mala
comunicación: Redacción engorrosa o difícil de manejar que oculta el sentido de urgencia; como resultado, la gente no escucha con
atención.
• No comunicarse lo suficientemente lejos: los gerentes están capacitados para comunicarse hacia arriba y hacia abajo. Los líderes
necesitan comunicarse hacia afuera y hacia grupos más amplios. Este rango de comunicación requiere que los líderes tengan
un sentido claro del problema y cómo se puede resolver.
Otro desafío es lidiar con las preguntas que tienen que ver con la visión, de las partes interesadas, la Coalición de Orientadores y el equipo
que implementa el cambio en sí. A menudo, Guiding Coalition dedica mucho tiempo a resolver estas preguntas y preparar las respuestas
solo para enviarlas a la organización de un solo golpe (una página de preguntas frecuentes, notas para un informe). La sobrecarga de
información resultante nubla la visión, crea pánico y resistencia a corto plazo.
Dado que, en la organización promedio, el mensaje de cambio representará no más de la mitad del uno por ciento de la comunicación total
dirigida a un empleado, está claro que simplemente volcar información no será efectivo. El mensaje necesita ser comunicado de una manera
que aumente su efectividad y amplifique
La comunicación.
Kotter identifica siete elementos clave en la comunicación efectiva de la visión:
• Manténgalo simple: elimine la jerga, el vocabulario interno y las oraciones complejas. • Use metáforas,
analogías y ejemplos: una imagen verbal (o incluso gráfica) puede valer la pena.
mil palabras
• Use varios foros: el mensaje debe poder comunicarse a través de una variedad de foros diferentes, desde discursos de ascensor
hasta memorandos de transmisión, desde reuniones pequeñas hasta sesiones informativas generales.
• Repetir, repetir, repetir: Las ideas tienen que ser escuchadas muchas veces antes de que sean internalizadas y
entendí.
• Predique con el ejemplo: el comportamiento de las personas importantes debe ser coherente con la visión. Inconsistente
el comportamiento supera a todas las demás formas de comunicación.
• Explique las aparentes inconsistencias: los cabos sueltos y las desconexiones no abordadas socavan la credibilidad
de toda comunicación.
• Dar y recibir: la comunicación bidireccional siempre es más poderosa que la comunicación unidireccional.
En un contexto de gestión de la información, la falta de definición o comunicación de una visión clara y convincente para un cambio a
menudo se puede ver en iniciativas en las que se implementa una nueva tecnología o capacidad impulsada por un
centrarse en el despliegue de tecnología. En ausencia de una comprensión o apreciación de los beneficios potenciales del manejo de la
información de la nueva tecnología o métodos, puede haber resistencia por parte de las partes interesadas para adoptar nuevas formas de
trabajo.
Por ejemplo, si una organización está implementando procesos de gestión de contenido y documentos basados en metadatos, es posible que
las partes interesadas del negocio no se comprometan con el esfuerzo inicial de comprender o aplicar el etiquetado de metadatos o la
clasificación de registros si no hay una visión claramente comunicada de cómo se hará esto. un beneficio para la organización y para ellos.
En ausencia de eso, la iniciativa, que de otro modo sería valiosa, puede empantanarse con niveles de adopción y cumplimiento inferiores a
los requeridos.
5.4.2 Manteniéndolo simple
Es difícil conectarse emocionalmente con un lenguaje poco natural, densamente escrito o difícil de entender.
Estos ejemplos ilustran los problemas de comunicación que pueden surgir cuando la visión no se mantiene simple. El siguiente ejemplo ilustra
este punto.
Nuestro objetivo es reducir nuestro parámetro medio de 'tiempo de reparación' para que sea demostrablemente más bajo que todos los
principales competidores en nuestros mercados geográficos y demográficos objetivo. De manera similar, nos hemos centrado en los tiempos
de ciclo de desarrollo de nuevos productos, los tiempos de procesamiento de pedidos y otros vectores de proceso relacionados con el cliente
para el cambio.
Traducción: "Vamos a ser más rápidos que nadie en nuestra industria para satisfacer las necesidades de los clientes".
Cuando la visión se articula de manera simple, es más fácil para los equipos, las partes interesadas y los clientes comprender el cambio
propuesto, cómo podría afectarlos y su papel en él. Esto, a su vez, les ayuda a comunicarlo más fácilmente a sus compañeros.
5.4.3 Use muchos foros diferentes
La comunicación de la visión suele ser más eficaz cuando se utilizan diferentes canales. Hay varias razones para esto, que van desde el
hecho de que algunos canales pueden estar sobrecargados con información o con 'equipaje' de iniciativas de cambio anteriores, hasta el
hecho de que diferentes personas interpretan y procesan la información de manera diferente. Si las personas reciben el mismo mensaje a
través de diferentes canales, aumenta la probabilidad de que el mensaje sea escuchado, interiorizado y aplicado. Relacionado con este
enfoque 'multicanal/multiformato' está la necesidad de seguir repitiendo la visión y comunicando el progreso.
5.4.4 Repetición, repetición, repetición
En muchos aspectos, la visión de cambio y los mensajes de cambio son como el agua en un río que se encuentra con una roca que debe ser
superada. El agua no irrumpe a través de la presa inmediatamente (a menos que tenga mucha fuerza detrás de ella,
596 • DMBOK2
en cuyo caso tiende a hacerlo destructivamente) pero con el tiempo, a través de la erosión iterativa, el agua desgasta el
roca para que pueda fluir a su alrededor.
De la misma manera, las iniciativas de cambio tienen que aplicar recuentos iterativos de la visión del cambio en diferentes foros y formatos
para generar un cambio que sea 'pegajoso'. ¿Cuál de estos escenarios sería más efectivo?
• La alta gerencia envió un mensaje de video a todo el personal y un mensaje de correo de voz para informar a todos sobre el
cambio. Los detalles sobre la ejecución seguirán de los gerentes de línea. La intranet publica tres artículos durante los próximos
seis meses sobre la Visión, y hay una sesión informativa en la conferencia de gestión trimestral (entregada al final del día). El
plan incluye seis instancias de comunicación sin desarrollar detalles.
• La alta gerencia se compromete a encontrar cuatro oportunidades cada día para tener una conversación de cambio y relacionarla
con el 'panorama general'. Ellos, a su vez, encargan a sus subordinados directos que encuentren cuatro oportunidades y les
asignan tareas a sus subordinados directos para que encuentren cuatro oportunidades. Entonces, cuando Frank se reúne con
Desarrollo de productos, les pide que revisen sus planes en el contexto de la Gran Visión. Cuando Mary presenta una
actualización de estado, la relaciona con la contribución a la Visión. Cuando Garry presenta hallazgos negativos de auditoría
interna, explica el impacto en términos de la Visión. En cada nivel de gestión, por gerente existen innumerables oportunidades
de comunicación por año donde se puede referenciar la visión. (Esto también se conoce como "Adoptar la nueva filosofía" e
"Instituir el liderazgo", que son puntos clave en los 14 puntos para la transformación en la gestión de la calidad de W. Edwards
Deming).
5.4.5 Practicando lo dicho
No hay sustituto para el liderazgo con el ejemplo. Hace que los valores y los aspectos culturales del cambio deseado sean tangibles de una
manera que ninguna cantidad de palabras puede hacer. Si por la única razón de que los altos directivos predican con el ejemplo engendran el
desarrollo de historias sobre la visión y desencadenan debates sobre la visión, esta es una herramienta excepcionalmente poderosa. El
corolario es que decirle a la gente una cosa y hacer lo contrario envía un mensaje claro de que la visión no es tan importante y puede ser
ignorada cuando llegue el momento. Nada socava más la visión y los esfuerzos de cambio que un miembro de alto rango de la Coalición de
Orientadores que actúa de manera incongruente con el
visión.
En el contexto de la gestión de la información, el incumplimiento de 'Walk the Talk' puede ser tan simple como que un alto directivo envíe
archivos que contengan información personal sobre los clientes a través de un canal de correo electrónico no seguro o no cifrado en
contravención de la política de seguridad de la información, pero sin recibir ninguna sanción.
También puede ser tan simple como que el equipo lidere una iniciativa de gobierno de la información aplicando los principios y el rigor que le
piden al resto de la organización que adopte en sus propias actividades, manejo de información, informes y respuestas a problemas y errores.
Considere el impacto en la implementación de un proyecto de gestión de metadatos si el equipo aplicara los estándares y
prácticas de metadatos a sus propios registros internos del proyecto. Al menos, les ayudaría a comprender los aspectos
prácticos del cambio, pero también les proporcionaría una buena demostración para otros de los beneficios de los registros y
la información correctamente etiquetados y clasificados.
5.4.7 Explicación de las incoherencias
A veces la inconsistencia es inevitable. Puede ser que, por razones tácticas u operativas, o simplemente para hacer que las
cosas se muevan dentro del sistema general de la organización, un Agente de Cambio podría necesitar tomar una acción que
analice la variación con la visión establecida. Cuando esto sucede, debe manejarse y abordarse con cuidado para garantizar
que la visión se mantenga, incluso si se está tomando una "ruta escénica". Los ejemplos de inconsistencias que pueden surgir
pueden incluir el uso de consultores externos cuando la organización busca reducir costos o personal. "¿Por qué la
organización está trayendo estos trajes caros cuando estamos racionando el papel de la impresora?" la gente puede
preguntar. Hay dos maneras de lidiar con la aparente inconsistencia. Uno de ellos está garantizado para matar su visión. El
otro te da la oportunidad de luchar para poder mantener las cosas en el buen camino.
La primera opción es ignorar la pregunta o reaccionar a la defensiva y dispararle al mensajero. Invariablemente, esto termina
en una vergonzosa escalada hacia abajo donde se elimina la inconsistencia, y no siempre de una manera que sea beneficiosa
para los objetivos a largo plazo del cambio. La segunda opción es comprometerse con la pregunta y explicar la razón de la
inconsistencia. La explicación debe ser simple, clara y honesta. Por ejemplo, una organización que trae consultores podría
responder así:
Apreciamos que parezca extraño gastar dinero en consultores cuando estamos recortando costos en todos los demás lugares
para lograr nuestra visión de ser eficientes, eficientes y sosteniblemente rentables. Sin embargo, para que los ahorros sean
sostenibles, debemos romper con los viejos hábitos de pensamiento y aprender nuevas habilidades. Eso nos obliga a invertir
en conocimiento. Y donde no tenemos ese conocimiento internamente, debemos comprarlo a corto plazo y usar esa
oportunidad para construir el conocimiento internamente para el futuro. Cada consultor está asignado a un proyecto específico.
Y a cada equipo de proyecto se le ha asignado la tarea de aprender tanto como sea posible sobre su nueva función siguiendo
a los consultores y usándolos para capacitación formal. De esta manera, nos aseguraremos de tener mejoras sostenibles en
el futuro.
La clave es ser explícito acerca de la inconsistencia y explícito acerca de por qué la inconsistencia es válida y cuánto tiempo
existirá si es solo una inconsistencia transitoria.
Explicar las inconsistencias es un muy buen ejemplo de la importancia de los modelos de gobierno de datos que crean
protocolos acordados para la toma de decisiones y promueven el reconocimiento y control formal de excepciones a
normas.
598 • DMBOK2
Por ejemplo, si un estándar de gobernanza requiere que no se realicen pruebas con datos de producción en vivo, pero un
proyecto requiere esto para verificar los algoritmos de coincidencia de datos o para probar la efectividad de las rutinas de
limpieza de datos, entonces debe haber una explicación clara y explícita de esta variación. del estándar esperado. A eso se
llega a través de controles de gobierno apropiados. Cuando ese proyecto ejecute pruebas utilizando datos en vivo sin contar
con las aprobaciones y evaluaciones de riesgo adecuadas, entonces debería haber una sanción ("práctica") o la base para la no
aplicación de la sanción debería ser igualmente clara y explícitamente explicada.
5.4.9 Escuchar y ser escuchado
Stephen Covey aconseja a las personas que quieren ser altamente efectivas que "busquen primero entender, luego ser
entendidos". En otras palabras, escucha para que te escuchen (Covey, 2013).
A menudo, el equipo de liderazgo no tiene la visión correcta o se encuentra con una barrera o cuello de botella que podría
haberse evitado si hubieran estado mejor informados. Esta falta de información conduce a errores costosos y debilita la
aceptación y el compromiso con la Visión. Las conversaciones bidireccionales son un método esencial para identificar y
responder las inquietudes que las personas tienen sobre un cambio o sobre una visión para el cambio. La Voz del Cliente es tan
importante para la definición y el desarrollo de la visión como lo es para cualquier métrica de calidad en los datos mismos. Y si
cada conversación se considera una oportunidad para discutir la visión y obtener comentarios ilícitos, entonces, sin tener que
vincular formalmente a las personas en las reuniones, es posible tener miles de horas de discusión y desarrollar la visión y cómo
ejecutarla de manera efectiva. .
En un contexto de gestión de la información, la comunicación bidireccional se ilustra mejor con un escenario en el que la función
de TI considera que todos los datos que necesitan las partes interesadas clave del negocio están disponibles de manera
oportuna y adecuada, pero las partes interesadas del negocio expresan constantemente su frustración por los retrasos. para
obtener la información que necesitan para hacer su trabajo, por lo que han desarrollado una industria artesanal en informes
basados en hojas de cálculo y data marts.
Una visión para mejorar la gestión de la información y la capacidad de gobierno que no identifique ni aborde la brecha en la
percepción entre la visión de la función de TI del entorno de la información y la percepción de las partes interesadas del negocio
de su entorno de información inevitablemente fallará y no logrará obtener la visión amplia. apoyo basado necesario para
asegurar que se entregue un cambio efectivo y sostenible.
6. La fórmula para el cambio
Uno de los métodos más famosos para describir la 'receta' requerida para un cambio efectivo, la fórmula de Gleicher, describe
los factores que deben existir para superar la resistencia al cambio en la organización.
= ( × × ) >
De acuerdo con la fórmula de Gleicher, el cambio (C) ocurre cuando el nivel de insatisfacción con el statu quo (D) se combina con una
visión de una mejor alternativa (V) y algunos primeros pasos factibles para llegar allí (F) y el producto de los tres es lo suficientemente
atractivo como para vencer la resistencia (R) en la organización.
Influir en cualquiera de las cuatro variables de la fórmula de Gleicher aumenta la eficacia y el éxito del esfuerzo de cambio. Sin embargo,
como ocurre con cualquier máquina compleja, es importante ser consciente de los riesgos inherentes a pulsar botones y tirar de palancas:
• El aumento de la insatisfacción dentro de la organización con la forma en que funcionan las cosas es una herramienta poderosa
y debe manejarse con cuidado para que no aumente la Resistencia.
• Desarrollar una visión del futuro requerirá una visión concreta y vívida de lo que la gente hará de manera diferente, lo que
la gente dejará de hacer o lo que comenzará a hacer que no está haciendo ahora.
Asegúrese de que las personas puedan apreciar las nuevas habilidades, actitudes o métodos de trabajo que se requerirán.
Preséntelos de una manera que no asuste a la gente ni cree barreras políticas para el cambio haciendo que la gente
defienda el status quo.
• Al describir los primeros pasos para el cambio, asegúrese de que sean factibles y vincúlelos explícitamente a
la visión.
• Actuar para reducir la resistencia y evitar aumentar la resistencia al cambio. Para ser franco: evitar alienar
gente. Esto requiere una buena comprensión de las partes interesadas.
7. Difusión de innovaciones y mantenimiento del cambio
En última instancia, se debe implementar capacitación y educación para brindar un cambio sostenible en la calidad de la información y la
gestión de datos en una organización. Implementar el cambio requiere comprender cómo se propagan las nuevas ideas en la organización.
Este aspecto del cambio se conoce como Difusión de Innovaciones.
La difusión de innovaciones es una teoría que busca explicar cómo, por qué y a qué velocidad se difunden nuevas ideas y tecnología a
través de las culturas. Formulado en 1962 por Everett Rogers, está relacionado con el concepto de cultura pop del Idea Virus (http://bit.ly/
2tNwUHD) popularizado por Seth Godin. La difusión de innovaciones se ha aplicado consistentemente en una amplia gama de campos,
desde la prescripción médica hasta los cambios en los métodos de manejo agrícola y la adopción de productos electrónicos de consumo.
La teoría de la Difusión de Innovaciones afirma que los cambios son iniciados por un porcentaje muy pequeño (2,5%) de la población total,
los Innovadores, que tienden (en el contexto de la sociedad que se examina) a ser jóvenes, de clase social alta y financieramente
suficientemente seguro para absorber las pérdidas por malas decisiones. Tienen contacto con innovadores tecnológicos y una alta
tolerancia al riesgo. Luego, les sigue otro 13,5 % de la población, los primeros adoptantes, que comparten rasgos con los innovadores,
pero son menos tolerantes al riesgo. Los primeros en adoptar entienden cómo hacer la elección correcta puede ayudarlos a mantener un
papel central en la sociedad como personas a las que se debe respetar. El cambio es adoptado luego por los segmentos más grandes de
la población, las Mayorías Temprana y Tardía,
600 • DMBOK2
que comprenden el 68% en total. Los rezagados son los últimos en adoptar cualquier innovación específica. (Consulte la Figura 118 y la Tabla
37).
100
mercado
Cuota
de
% 75
50
25
innovadores Tarde
Temprano Rezagados
2,5% Primeros Mayoría Mayoría 16%
usuarios 13,5 % 34% 34%
Figura 118 Difusión de innovaciones de Everett Rogers
Tabla 37 Categorías de Difusión de Innovaciones Adaptadas a la Gestión de la Información105
Adoptante
Definición (perspectiva de gestión de la información)
Categoría
innovadores Los innovadores son las primeras personas en detectar una mejor manera de abordar los problemas con la calidad
de la información. Asumen riesgos tratando de desarrollar perfiles de datos, crear cuadros de mando tentativos y comenzar a
poner los síntomas experimentados por el negocio en el lenguaje de la gestión de la información. A menudo, estos innovadores
utilizarán sus propios recursos para obtener información y desarrollar habilidades sobre las mejores prácticas.
Los primeros en adoptar Los primeros en adoptar son la segunda categoría de personas que más rápidamente adoptan una innovación. Estos
individuos tienen el grado más alto de liderazgo de opinión entre las demás categorías de adoptantes. Son percibidos como
gerentes 'visionarios' (o gerentes experimentados, o gerentes responsables de áreas emergentes de estrategia comercial) que se
han dado cuenta de que los problemas de calidad de la información son una barrera para su éxito. A menudo, se aprovechan del
trabajo inicial de los Innovadores para desarrollar su caso de negocios y comenzar a formalizar las prácticas de información.
Mayoría Temprana A la Mayoría Temprana le toma mucho más tiempo que a los Adoptadores Tempranos adoptar una innovación. Temprano
La mayoría tiende a ser más lenta en el proceso de adopción, tiene un estatus social superior al promedio, contacto con los
primeros en adoptar y rara vez ocupa posiciones de liderazgo de opinión en un sistema. Podrían estar en las áreas 'centrales
tradicionales' de la organización donde el impacto de los datos de mala calidad se enmascara como el 'costo del negocio'.
Mayoría Tardía Los individuos de la Mayoría Tardía se acercan a una innovación con un alto grado de escepticismo y después de que la mayoría de la
sociedad haya adoptado la innovación. La mayoría tardía suele tener un estatus social por debajo del promedio, muy poca lucidez
financiera, en contacto con otros en la mayoría tardía y la mayoría temprana, muy poco liderazgo de opinión.
En términos de gestión de la información, estas pueden ser áreas de la organización donde los presupuestos ajustados
pueden combinarse con el escepticismo sobre los cambios propuestos para generar resistencia.
Rezagados Los rezagados son los últimos en adoptar una innovación. Las personas en esta categoría muestran poco o ningún
liderazgo de opinión. Por lo general, son reacios a los agentes de cambio y tienden a ser de edad avanzada. Los rezagados
tienden a centrarse en las 'tradiciones'. En Gestión de la Información, estos términos suelen ser las personas o áreas de la
empresa que se resisten porque lo 'nuevo' significa tener que hacer lo 'antiguo' de manera diferente o no hacerlo en absoluto.
105 © 2014 Daragh O'Brien. Usado con permiso.
7.1 Los desafíos a superar a medida que se difunden las innovaciones
Existen dos áreas clave de desafío con la difusión de innovaciones a través de la organización. El primero es superar la etapa de Early
Adopter. Esto requiere una gestión cuidadosa del cambio para garantizar que los primeros usuarios puedan identificar un nivel suficiente
de insatisfacción con el statu quo que harán y persistir con el cambio.
Este paso es necesario para alcanzar el 'punto de inflexión' donde la innovación es adoptada por suficientes personas para que comience
para convertirse en la corriente principal.
El segundo punto clave del desafío es cuando la innovación pasa de la etapa de la mayoría tardía a la etapa de los rezagados. El equipo
debe aceptar que no necesariamente pueden convertir al 100% de la población a la nueva forma de hacer las cosas. Cierto porcentaje
del grupo puede continuar resistiéndose al cambio y la organización deberá decidir qué hacer con este elemento del grupo.
7.2 Elementos clave en la difusión de la innovación
Se deben considerar cuatro elementos clave al observar cómo se propaga una innovación a través de una organización:
• Innovación: Una idea, práctica u objeto que es percibido como nuevo por un individuo u otra unidad de
adopción
• Canales de comunicación: los medios por los cuales los mensajes pasan de un individuo a otro • Tiempo: la velocidad
a la que los miembros del sistema social adoptan la innovación • Sistema social: el conjunto de unidades interrelacionadas
que participan en la resolución conjunta de problemas para lograr a
meta común
En el contexto de la gestión de la información, una innovación podría ser algo tan simple como la idea del rol de un Administrador de datos
y la necesidad de que los Administradores trabajen de forma transversal en problemas de datos comunes en lugar del pensamiento
tradicional de "silo".
El proceso mediante el cual se comunica esa innovación, y los canales a través de los cuales se comunica de manera más efectiva, son
los canales de comunicación que deben ser considerados y gestionados.
Finalmente, la idea del Sistema Social como un conjunto de unidades interrelacionadas que se comprometen hacia un emprendimiento
conjunto. Esto es una reminiscencia del Sistema descrito por W. Edwards Deming, que debe optimizarse como un todo en lugar de pieza
por pieza de forma aislada. Una innovación que no se difunde fuera de una sola unidad de negocio o equipo no es un cambio bien
difundido.
7.3 Las cinco etapas de la adopción
La adopción de cualquier cambio tiende a seguir un ciclo de cinco pasos. Comienza cuando los individuos toman conciencia de la
innovación (Conocimiento), se convencen del valor de la innovación y su relevancia para ellos (Persuasión) y llegan al punto de tomar
una Decisión sobre su relación con la innovación. Si no lo hacen
602 • DMBOK2
rechazan la innovación, luego pasan a Implementar y finalmente Confirman la adopción de la innovación. (Consulte la Tabla 38 y la Figura
119).
Por supuesto, debido a que una idea siempre puede ser rechazada en lugar de adoptada, el punto de inflexión de la masa crítica de los
primeros en adoptar y la mayoría temprana es importante.
Cuadro 38 Las etapas de la adopción (adaptado de Rogers, 1964)
Etapa Definición
Conocimiento En la etapa de conocimiento, el individuo se expone por primera vez a una innovación, pero carece de información
sobre la innovación. Durante esta etapa, el individuo aún no se ha inspirado para encontrar más información
sobre la innovación.
Persuasión En la etapa de persuasión, el individuo está interesado en la innovación y busca activamente información
sobre la innovación.
Decisión En la etapa de Decisión, el individuo sopesa las ventajas y desventajas de usar la innovación y decide si la
adopta o la rechaza. Rogers señala que la naturaleza individualista de esta etapa la convierte en la etapa más difícil
sobre la cual adquirir evidencia empírica.
Implementación En la etapa de Implementación el individuo emplea la innovación y determina su
utilidad o busca más información al respecto.
Confirmación En la etapa de Confirmación, el individuo finaliza su decisión de continuar usando la innovación y puede
terminar usándola en todo su potencial.
Conocimiento Persuasión Decisión
Figura 119 Las Etapas de la Adopción
7.4 Factores que afectan la aceptación o el rechazo de una innovación o cambio
Las personas toman decisiones en gran parte racionales cuando aceptan o rechazan una innovación o un cambio. La clave para esto es
si la innovación ofrece alguna ventaja relativa sobre la forma anterior de hacer las cosas.
Considere el teléfono inteligente moderno. Presentaba una clara ventaja sobre los teléfonos inteligentes anteriores porque era fácil de
usar, elegante a la vista y tenía una tienda de aplicaciones donde las capacidades del producto se podían ampliar de forma rápida y sencilla.
fácilmente. Del mismo modo, la implementación de herramientas, tecnologías y técnicas de gestión de datos tiene ventajas relativas
sobre el cambio manual de datos, la codificación a medida o las actividades manuales de búsqueda y descubrimiento de datos que
requieren muchos recursos.
Por ejemplo, en muchas organizaciones puede haber resistencia a cambios simples en la administración de contenido y documentos,
como etiquetar archivos con metadatos para brindar contexto. Sin embargo, el uso de esos metadatos, a su vez, proporciona una
ventaja relativa en términos de soporte de controles de seguridad, cronogramas de retención y tareas simples como la búsqueda y
recuperación de información. Vincular la molestia de etiquetar con el tiempo ahorrado en la búsqueda de información o en el manejo
de problemas en los que la información se comparte o divulga sin autorización puede ayudar a demostrar esta ventaja relativa.
Una vez que las personas ven que se propone una mejora, preguntarán si la mejora es compatible con su vida, su forma de trabajar,
etc. Volviendo al ejemplo del teléfono inteligente, el hecho de que combinó un reproductor de mp3 de alta calidad, correo electrónico,
teléfono, etc. ., significaba que era compatible con el estilo de vida y formas de trabajo de sus usuarios objetivo.
Para entender la compatibilidad, un consumidor (consciente o inconscientemente) considerará varios factores. Por ejemplo, la
complejidad o sencillez del cambio. Si la innovación es demasiado difícil de usar, es menos probable que se adopte. Nuevamente, la
evolución de las plataformas de teléfonos inteligentes y tabletas está plagada de intentos fallidos que no lograron el objetivo de una
interfaz de usuario simple. Los que lo hicieron redefinieron la expectativa del mercado e inspiraron interfaces similares en otros
dispositivos.
La capacidad de prueba se refiere a qué tan fácil es para el consumidor experimentar con la nueva herramienta o tecnología. De ahí
las ofertas freemium para herramientas. Cuanto más fácil sea 'patear los neumáticos', más probable es que el usuario adopte la nueva
herramienta o innovación. La importancia de esto es que ayuda a establecer la comprensión de la ventaja relativa, la compatibilidad
con el estilo de vida y la cultura de la organización y la simplicidad del cambio. Como un conjunto de primeros pasos hacia una visión
de cambio, la creación iterativa de prototipos y 'probarlo' con las partes interesadas es esencial y puede ayudar a consolidar la
Coalición de Guías, así como a garantizar que los primeros adoptantes estén a bordo.
La observabilidad es la medida en que la innovación es visible. Hacer visible la innovación impulsará la comunicación al respecto a
través de redes formales y personales. Esto puede desencadenar reacciones negativas así como reacciones positivas. Planifique
cómo manejar los comentarios negativos. La experiencia de ver a personas usando una nueva tecnología o trabajando con información
de una manera particular (p. ej., visualización de números tradicionalmente 'secos') puede influir en cómo comunicar mejor la
experiencia.
8. Mantener el cambio
Comenzar el cambio requiere una visión clara y convincente y primeros pasos claros e inmediatos, un sentido de urgencia o
insatisfacción con el status quo, una Coalición Guía y un plan para evitar los escollos y las trampas en las que pueden caer los Agentes
de Cambio cuando comienzan su cambiar de viaje.
604 • DMBOK2
Sin embargo, un problema común en las iniciativas de gestión de la información (p. ej., programas de gobierno de datos) es que se inician
en respuesta a un impulsor específico oa un síntoma particular de capacidad subóptima en la organización. A medida que se aborda el
síntoma, disminuye la sensación de insatisfacción y urgencia. Se vuelve más difícil mantener el apoyo político o financiero, particularmente
cuando se compite con otros proyectos.
Está fuera del alcance de este trabajo proporcionar un análisis detallado o herramientas sobre cómo se pueden abordar estos problemas
complejos. Sin embargo, en el contexto de un Cuerpo de conocimientos, es apropiado volver a consultar los principios de gestión del cambio
descritos en este capítulo para proporcionar una idea de cómo se pueden encontrar las soluciones.
8.1 Sentido de Urgencia / Insatisfacción
Es importante mantener el sentido de urgencia. El corolario de esto es estar alerta a las áreas emergentes de insatisfacción en la
organización y cómo el cambio en la gestión de la información podría ayudar a respaldar la mejora.
Por ejemplo, el alcance de una iniciativa de gobierno de datos que se implementó para respaldar un requisito normativo de privacidad de
datos se puede ampliar para abordar problemas de calidad de la información en relación con los datos personales. Eso se puede relacionar
con el alcance principal de la iniciativa, ya que la mayoría de las regulaciones de privacidad de datos tienen un componente de calidad de
datos y brindan un derecho de acceso a los datos a las personas, por lo que existe el riesgo de que se expongan datos de mala calidad. Sin
embargo, abre la visión del programa de gobierno de datos para incluir métodos y prácticas de calidad de la información que pueden
implementarse como una 'segunda ola' una vez que se implementen los controles básicos de gobierno de privacidad de datos.
8.2 Enmarcando la visión
Un error común es confundir el alcance del proyecto con la visión del cambio. Muchos proyectos pueden ser necesarios para lograr la
visión. Es importante que la visión se establezca de una manera que permita una acción de base amplia y no cree un callejón sin salida
para los líderes del cambio una vez que se entreguen los proyectos iniciales de 'fruta al alcance de la mano'.
Hay una diferencia entre una visión que dice:
Implementaremos un marco de gobierno estructurado para datos personales para garantizar el cumplimiento de las normas de privacidad
de datos de la UE.
y uno que dice:
Lideraremos nuestra industria en enfoques y métodos repetibles y escalables para administrar nuestros activos de información críticos para
garantizar ganancias, reducir riesgos, mejorar la calidad del servicio y equilibrar nuestras obligaciones éticas como administradores de
información personal.
El primero es, más o menos, un objetivo. El segundo proporciona dirección para la organización.
8.3 La Coalición Orientadora
Restringir la membresía de la Coalición de Orientadores a las partes interesadas más inmediatamente afectadas restringirá la efectividad
del cambio. Al igual que con la visión, es importante no confundir los grupos directivos del proyecto que supervisan la entrega de
entregables específicos con la coalición que guía y desarrolla la visión para el cambio en la organización.
8.4 Ventaja relativa y observabilidad
Si bien la aplicación específica o el enfoque de una iniciativa de cambio puede ser limitado, en la mayoría de los casos los principios,
prácticas y herramientas que se aplican pueden transferirse a otras iniciativas. Ser capaz de demostrar cómo el enfoque y los métodos
pueden dar una ventaja relativa a otras iniciativas en la organización puede ayudar a extender la Coalición de Orientadores e identificar
nuevas áreas de urgencia o insatisfacción que la iniciativa de cambio puede respaldar.
Por ejemplo, en una empresa de servicios públicos, los métodos y herramientas de creación de perfiles y tarjetas de puntuación que se
implementan para una vista única de la implementación del cliente pueden transferirse directamente a un programa de cumplimiento
normativo de facturación. La vinculación de los dos se prestaría a un Cuadro de Mando de Calidad de Datos Empresariales y a las
iniciativas de remediación y gobernanza de datos asociadas, particularmente donde los enfoques subóptimos, como la limpieza manual
de datos, podrían ser la opción predeterminada para los datos de facturación.
9. Comunicar el valor de la gestión de datos
Ayudar a una organización a comprender la importancia de la gestión de datos a menudo requiere un plan de gestión de cambio
organizacional formal, como se describe en este capítulo. Dicho plan ayuda a la organización a reconocer el valor de sus datos y la
contribución de las prácticas de gestión de datos a ese valor. Sin embargo, una vez que se establece un programa de gestión de datos,
también es necesario cultivar un apoyo continuo. La comunicación continua promueve la comprensión y sustenta el apoyo. Si las
comunicaciones se estructuran como un canal bidireccional, un plan de comunicaciones puede ayudar a fortalecer las asociaciones al
permitir que las partes interesadas compartan inquietudes e ideas. Este tipo de esfuerzo de comunicación requiere planificación.
9.1 Principios de comunicación
El propósito de cualquier comunicación es enviar un mensaje a un receptor. Al planificar las comunicaciones, es necesario tener en
cuenta el mensaje, los medios utilizados para transmitirlo y las audiencias a las que está destinado. Para respaldar esta estructura básica,
se aplican ciertos principios generales a cualquier plan de comunicación formal, independientemente del tema. Estos son muy importantes
cuando se comunica sobre la gestión de datos porque muchas personas no entienden la importancia de la gestión de datos para el éxito
de la organización. Un plan general de comunicaciones y
cada comunicación individual debe:
606 • DMBOK2
• Tener un objetivo claro y un resultado deseado • Consistir en
mensajes clave para apoyar el resultado deseado
• Adaptarse a la audiencia / partes interesadas
• Entregarse a través de medios que sean apropiados para la audiencia/las partes interesadas
Si bien las comunicaciones pueden ser sobre una variedad de temas, los objetivos generales de la comunicación se reducen a:
• Informar • Educar
• Establecer metas
o una visión • Definir una solución a
un problema • Promover el cambio • Influir o
motivar la acción • Obtener retroalimentación •
Generar apoyo
Lo que es más importante, para poder comunicarse con claridad, es necesario tener mensajes sustantivos para compartir con la gente. Las
comunicaciones generales sobre la gestión de datos serán más exitosas si el equipo de gestión de datos comprende el estado actual de las
prácticas de gestión de datos y tiene una declaración de visión y misión que conecta la mejora en las prácticas de gestión de datos directamente
con los objetivos estratégicos de la organización. Gestión de datos
las comunicaciones deben esforzarse por:
• Transmitir el valor tangible e intangible de las iniciativas de gestión de datos
• Describir cómo las capacidades de gestión de datos contribuyen a la estrategia y los resultados comerciales.
• Comparta ejemplos concretos de cómo la gestión de datos reduce costos, respalda el crecimiento de ingresos, reduce
riesgo, o mejora la calidad de la decisión
• Educar a las personas sobre conceptos fundamentales de gestión de datos para aumentar la base de conocimientos sobre
gestión de datos dentro de la organización
9.2 Evaluación y preparación de la audiencia
La planificación de las comunicaciones debe incluir un análisis de las partes interesadas para ayudar a identificar las audiencias de las
comunicaciones que se desarrollarán. Con base en los resultados del análisis, el contenido se puede adaptar para que sea relevante, significativo
y en el nivel apropiado, según las necesidades de las partes interesadas. Por ejemplo, si el objetivo del plan de comunicaciones es obtener
patrocinio para una iniciativa, dirija las comunicaciones a las personas más influyentes posibles, generalmente ejecutivos que desean conocer el
beneficio final de cualquier programa que financian.
Las tácticas para persuadir a las personas para que actúen sobre las comunicaciones incluyen varias formas de hacer que las personas vean
cómo sus intereses se alinean con las metas del programa.
• Resolver problemas: los mensajes deben describir cómo el esfuerzo de gestión de datos ayudará a resolver los problemas pertinentes
a las necesidades de las partes interesadas a las que se dirige. Por ejemplo, los colaboradores individuales tienen necesidades
diferentes a las de los ejecutivos. TI tiene necesidades que son diferentes a las de la gente de negocios.
• Abordar los puntos débiles: diferentes partes interesadas tendrán diferentes puntos débiles. Contabilizando estos dolores
Los puntos en los materiales de comunicación ayudarán a la audiencia a comprender el valor de lo que se propone. Por
ejemplo, una parte interesada en el cumplimiento estará interesada en cómo un programa de gestión de datos reducirá el
riesgo. Una parte interesada en marketing estará interesada en cómo el programa los ayuda a generar nuevas oportunidades.
• Presentar los cambios como mejoras: en la mayoría de los casos, la introducción de prácticas de gestión de datos requiere que
las personas cambien su forma de trabajar. Las comunicaciones deben motivar a las personas a desear los cambios
propuestos. En otras palabras, necesitan reconocer los cambios como mejoras a partir de las cuales
beneficio.
• Tener una visión del éxito: Describir cómo será vivir en el futuro estado permite a las partes interesadas comprender cómo el programa
los impacta. Compartir cómo se ve y se siente el éxito puede ayudar a la audiencia a comprender los beneficios del programa de
gestión de datos.
• Evite la jerga: la jerga de gestión de datos y el énfasis en los aspectos técnicos convertirán a algunas personas
desconectar y restar valor al mensaje.
• Comparta historias y ejemplos: Las analogías y las historias son formas efectivas de describir y ayudar a las personas .
recordar las finalidades del programa de Gestión de Datos.
• Reconocer el miedo como motivación: Algunas personas están motivadas por el miedo. Compartir las consecuencias de no
gestionar los datos (p. ej., multas, sanciones) es una forma de implicar el valor de gestionar bien los datos. Los ejemplos de
cómo la falta de prácticas de gestión de datos ha afectado negativamente a una unidad de negocio resonarán.
La entrega efectiva de comunicaciones implica monitorear las reacciones de los oyentes al mensaje. Si una táctica determinada no funciona,
adáptese y pruebe con un ángulo diferente.
9.3 El elemento humano
Los hechos, ejemplos e historias compartidas sobre un programa de gestión de datos no son las únicas cosas que influirán en las percepciones
de las partes interesadas sobre su valor. Las personas están influenciadas por sus colegas y líderes. Por esta razón, la comunicación debe
usar el análisis de las partes interesadas para encontrar dónde los grupos tienen intereses y necesidades similares. A medida que se amplía
el apoyo al esfuerzo de gestión de datos, los colaboradores pueden ayudar a compartir el mensaje con sus compañeros y líderes.
608 • DMBOK2
9.4 Plan de comunicación
Un plan de comunicación reúne elementos de planificación. Un buen plan sirve como hoja de ruta para orientar el trabajo hacia los objetivos. El plan
de comunicación debe incluir los elementos enumerados en la Tabla 39.
Tabla 39 Elementos del plan de comunicación
Elemento Descripción Mensaje La información que debe transmitirse.
Meta/Objetivo El resultado deseado de transmitir un mensaje o conjunto de mensajes (es decir, por qué es necesario transmitir el mensaje).
Audiencia Grupo o persona a la que se dirige la comunicación. El plan tendrá diferentes objetivos para diferentes audiencias.
Estilo Tanto el nivel de formalidad como el nivel de detalle de los mensajes deben adaptarse a la audiencia. Los ejecutivos
necesitan menos detalles que los equipos responsables de la implementación de proyectos. El estilo también está
influenciado por la cultura organizacional.
Canal, Método, Los medios y el formato a través de los cuales se transmitirá el mensaje (p. ej., página web, blog, correo electrónico,
Medio reuniones individuales, presentaciones en grupos pequeños o grandes, sesiones de almuerzo y aprendizaje, talleres,
etc.) Diferentes medios tienen diferentes efectos .
Sincronización La forma en que se recibe un mensaje puede verse influida por el momento en que se recibe. Es más probable que los
empleados lean un correo electrónico que llega a primera hora de la mañana del lunes que uno que sale a última hora
de la tarde del viernes. Si el propósito de una comunicación es obtener apoyo antes de un ciclo presupuestario, entonces
debe programarse en relación con el ciclo presupuestario.
La información sobre cambios inminentes en los procesos debe compartirse de manera oportuna y antes de que se
produzca un cambio.
Frecuencia La mayoría de los mensajes deben repetirse para garantizar que todos los interesados los escuchen. El plan de
comunicaciones debe programar el intercambio de mensajes para que la repetición sea útil para transmitir el mensaje y
no se convierta en una molestia. Además, las comunicaciones en curso (por ejemplo, un boletín informativo) deben
publicarse según un cronograma acordado.
Materiales El plan de comunicaciones debe identificar cualquier material que sea necesario crear para ejecutar el plan. Por
ejemplo, versiones cortas y largas de presentaciones y otras comunicaciones escritas, discursos de ascensor,
resúmenes ejecutivos y materiales de marketing como carteles, tazas y otros medios de marca visual.
comunicadores El plan de comunicaciones debe identificar a la persona o personas que entregarán las comunicaciones.
A menudo, la persona que transmite el mensaje tiene una profunda influencia en la audiencia objetivo. Si el patrocinador
de gestión de datos u otro ejecutivo entrega un mensaje, las partes interesadas tendrán una respuesta diferente que si
lo entrega un gerente de nivel inferior.
Las decisiones sobre quién comunicará qué mensajes a qué partes interesadas deben basarse en los objetivos del
mensaje.
Esperado El plan de comunicaciones debe anticipar cómo los diferentes grupos de partes interesadas y, a veces, cómo
Respuesta las partes interesadas individuales responderán a las comunicaciones. Este trabajo puede lograrse anticipando preguntas
u objeciones y formulando respuestas. Pensar en las posibles respuestas es una buena manera de aclarar los objetivos
y crear mensajes sólidos para respaldarlos.
Métrica El plan de comunicaciones debe incluir medidas de su propia eficacia. El objetivo es garantizar que las personas hayan
entendido y estén dispuestas y sean capaces de actuar sobre los mensajes del plan. Esto se puede lograr a través de
encuestas, entrevistas, grupos focales y otros mecanismos de retroalimentación. Los cambios de comportamiento son
la prueba definitiva del éxito de un plan de comunicaciones.
Presupuesto y El plan de comunicaciones debe tener en cuenta qué recursos se necesitan para llevar a cabo los objetivos dentro de
Plan de recursos un presupuesto determinado.
9.5 Siga comunicándose
Un programa de gestión de datos es un esfuerzo continuo, no un proyecto de una sola vez. Los esfuerzos de comunicación que respaldan el programa
deben medirse y mantenerse para lograr un éxito continuo.
Se contratan nuevos empleados y los empleados existentes cambian de rol. A medida que ocurren los cambios, los planes de comunicación deben
actualizarse. Las necesidades de las partes interesadas cambian con el tiempo a medida que maduran los programas de gestión de datos. Se necesita
tiempo para que las personas absorban los mensajes, y escuchar los mensajes varias veces ayuda a las partes interesadas a retener este conocimiento.
Los métodos de comunicación y los mensajes también deberán adaptarse con el tiempo a medida que aumente la comprensión.
La competencia por la financiación nunca desaparece. Uno de los objetivos de un plan de comunicaciones es recordar a las partes interesadas el valor
y los beneficios del programa de gestión de datos. Mostrar el progreso y celebrar los éxitos es vital para obtener un apoyo continuo para el esfuerzo.
La planificación eficaz y la comunicación continua demostrarán el impacto que las prácticas de gestión de datos han tenido en la organización a lo
largo del tiempo. Con el tiempo, el conocimiento de la importancia de los datos cambia la forma de pensar de la organización sobre los datos. Una
comunicación exitosa proporciona una mejor comprensión de que la gestión de datos puede generar valor comercial a partir de los activos de
información y tener un impacto duradero en la organización.
Ackerman Anderson, Linda y Dean Anderson. La hoja de ruta del líder del cambio y más allá de la gestión del cambio. Juego de dos libros. 2ª ed. Pfeiffer,
2010. Imprimir.
Ackerman Anderson, Linda, Dean Anderson. Más allá de la gestión del cambio: cómo lograr resultados innovadores a través del liderazgo de cambio consciente.
2ª ed. Pfeiffer, 2010. Imprimir.
Ackerman Anderson, Linda, Dean Anderson. La hoja de ruta del líder del cambio: cómo navegar la transformación de su organización. 2ª ed. Pfeiffer,
2010. Imprimir.
Barksdale, Susan y Teri Lund. 10 pasos para una planificación estratégica exitosa. ASTD, 2006. Imprimir. 10 pasos.
Becker, Ethan F. y Jon Wortmann. Dominar la comunicación en el trabajo: cómo liderar, administrar e influir. McGraw Hill, 2009. Imprimir.
Bevan, Ricardo. Changemaking: Tácticas y recursos para gestionar el cambio organizacional. Plataforma de publicación independiente CreateSpace,
2011. Imprimir.
Límites, Andy. El efecto bola de nieve: técnicas de comunicación para hacerte imparable. Capstone, 2013. Imprimir.
Puentes, Guillermo. Gestión de transiciones: aprovechar al máximo el cambio. Libros de toda la vida de Da Capo, 2009. Imprimir.
Centro para el Liderazgo Creativo (CCL), Talula Cartwright y David Baldwin. Comunicando su visión. Pfeiffer, 2007.
Imprimir.
Contreras, Melissa. Habilidades de las personas para los negocios: Habilidades sociales ganadoras que lo colocan por delante de la competencia. Plataforma
de publicación independiente CreateSpace, 2013. Imprimir.
Covey, Stephen R. Franklin Guía de estilo de Covey: para comunicaciones comerciales y técnicas. 5ª ed. FT Press, 2012. Impreso.
610 • DMBOK2
Covey, Stephen R. Los 7 hábitos de las personas altamente efectivas: poderosas lecciones de cambio personal. Simon y Schuster, 2013. Imprimir.
Franklin, Melanie. Gestión ágil del cambio: un marco práctico para la planificación e implementación exitosa del cambio. Página de
Kogan, 2014. Imprimir.
García, Helio Fred. El poder de la comunicación: Las: Habilidades para generar confianza, inspirar lealtad y liderar con eficacia. FT Press, 2012. Imprimir.
Godin, Seth y Malcolm Gladwell. Desatando el Ideavirus. Libros de Hachette, 2001.
Prensa de la Escuela de Negocios de Harvard. Comunicacion de negocios. Harvard Business Review Press, 2003. Impreso. Esenciales de negocios de
Harvard.
Las 10 lecturas imprescindibles de HBR sobre la gestión del cambio. Harvard Business Review Press, 2011. Imprimir.
Hiatt, Jeffrey y Timothy Creasey. Gestión del cambio: el lado humano del cambio. Publicaciones del Centro de Aprendizaje Prosci, 2012.
Imprimir.
Holman, Peggy, Tom Devane, Steven Cady. The Change Handbook: el recurso definitivo sobre los mejores métodos actuales para involucrar sistemas
completos. 2ª ed. BerrettKoehler Publishers, 2007. Imprimir.
Hood, J H. Cómo libro de Comunicación Interpersonal: Mejora tus Relaciones. vol. 3. WordCraft Global Pty Limited, 2013. Impreso. Libros de “Cómo
hacer”.
Jones, Fil. Estrategia comunicativa. Ashgate, 2008. Imprimir.
Kotter, John P. Liderando el cambio. Harvard Business Review Press, 2012. Imprimir.
Locker, Kitty y Stephen Kaczmarek. Comunicación Empresarial: Desarrollo de Habilidades Críticas. 5ª ed. McGrawHill/Irwin, 2010. Imprimir.
Lucke, Richard. Gestión del cambio y la transición. Harvard Business Review Press, 2003. Impreso. Esenciales de negocios de Harvard.
Rogers, Everett M. Difusión de innovaciones. 5ª ed. Prensa Libre, 2003. Impreso.
Agradecimientos
D
L a elaboración de la segunda edición del DAMADMBOK ha sido un trabajo de amor para muchas personas. Él
El trabajo comenzó a fines de 2011 con la primera revisión del Documento Marco, publicado en 2012. El DAMA
El Comité Editorial de DMBOK dedicó muchas horas a producir el borrador de DMBOK2. Incluyen:
Patricia Cupoli (DAMA Filadelfia) fue la editora en jefe de la mayor parte de este trabajo, encontrando autores y ayudándolos a desarrollar
sus capítulos. Lamentablemente, Pat falleció en el verano de 2015, mientras aún participaba en el proyecto.
Deborah Henderson (IRMAC, afiliada de Toronto DAMA), directora del programa de los productos DAMADMBOK desde su inicio en
2005, fue una patrocinadora dedicada del proyecto y trabajó para garantizar su finalización después del fallecimiento de Pat.
Susan Earley (DAMA Chicago), quien redactó el marco DAMADMBOK2, fue la editora principal del borrador DMBOK2. Editó y organizó
el contenido e incorporó los extensos comentarios públicos de DAMA.
Miembros.
Eva Smith (DAMA Seattle), gerente de herramientas de colaboración, manejó la logística, incluida la habilitación de los miembros de
DAMA para acceder y comentar los capítulos.
Elena Sykora (IRMAC – afiliada de Toronto DAMA), investigadora bibliógrafa, compiló la bibliografía completa de DMBOK2.
El Comité Editorial también agradeció el apoyo particular de Sanjay Shirude, Cathy Nolan, Emarie Pope y
Steve Hobermann.
Laura SebastianColeman (DAMA New England), directora de publicaciones y editora de producción de DAMA, dio forma, pulió y finalizó
el manuscrito para su publicación. En este esfuerzo, fue guiada por un comité asesor que incluía a Peter Aiken, Chris Bradley, Jan
Henderyckx, Mike Jennings, Daragh O Brien y yo, con mucha ayuda de Lisa Olinda. Un agradecimiento especial también para Danette
McGilvray.
DMBOK2 no habría sido posible sin los principales autores contribuyentes que dieron sustancia a la visión definida en el Marco. Todos
los colaboradores son voluntarios que compartieron no solo sus conocimientos sino también su tiempo.
Se acreditan por sus contribuciones a continuación. Los muchos miembros de DAMA que proporcionaron comentarios sobre los capítulos
también se enumeran.
DAMA International, la Fundación Internacional DAMA y el Consejo de Presidentes de Capítulos de DAMA patrocinaron el proyecto
DMBOK. Su visión, perspicacia, paciencia y apoyo continuo permitieron que este proyecto tuviera éxito.
Finalmente, queremos reconocer a las familias de todos los voluntarios en este proyecto, quienes dieron su tiempo personal para
completar este trabajo.
Sue Geuens, Presidenta, DAMA Internacional
611
612 • DMBOK2
Colaboradores principales
# Capítulo Colaboradores principales
Comité Asesor Editorial, editores de DMBOK,
1 Introducción: Gestión de datos
Chris BradleyKen Kring
2 Ética en el manejo de datos
3 Gobierno y administración de datos John Ladley, Mark Cowan, Sanjay Shirude
4 Arquitectura de datos Hakan Edvinsson
5 Modelado y diseño de datos steve hobermann
6 Operaciones y almacenamiento de datos Sanjay Shirude
7 Seguridad de datos David Schlesinger, CISSP
8 Integración e interoperabilidad de datos abril reeve
9 Documentos y Contenido pat cupoli
10 Datos maestros y de referencia Gene BoomerMehmet Orun
Martín Sykora, Krish Krishnan, John Ladley, Lisa
11 Almacén de datos e inteligencia comercial
nelson
12 metadatos Saad Yacu
13 Calidad de datos rossano tavares
14 Big Data y ciencia de datos Robert Abate, Martín Sykora
15 Evaluación de la madurez de la gestión de datos Mark Cowan, Deborah Henderson
dieciséis
Organizaciones y funciones de gestión de datos Kelle O'Neal
Gestión de datos y cambio organizacional Micheline Casey, Andrea Thomsen, Daragh O.
17
Gestión Brien
Bibliografía Elena Sikora
Revisores y comentaristas
Las siguientes personas brindaron comentarios valiosos en varias etapas del DMBOK2:
Jalid Abu Shamleh mike beauchamp Susana Burk

gerard adams Chan Beauvais Guillermo Burkett
james adman glen bellomy Vence a Burtscher
Afsaneh Afkari Stacie Benton ismael caballero
Zaher Alhaj León Bernal pedro campbell

Shahid Alí Luciana Bicalho Betty (Elizabeth) Carpenito
Suhail Ahmad AmanUllah Pawel Bober Hazbleydi Cervera
Nav Amar Christiana Boehmer Indrajit Chatterjee
Samuel Kofi Annan enlace stewart bavani chaudhary
Iván Arroyo Boomer genético Denise Cook
Nicola Askham Taher Borsadwala nigel corbin
Juan Azcurra antonio braga james dawson
Ricardo Volver Ciaran Breen Elisio Henrique de Souza

carlos barbieri LeRoy Broughton patricio derde
Ian Batty Pablo marrón Tejas Desaí

steve beaton Donna Burbank Swapnil Deshmukh
AGRADECIMIENTOS • 613
cynthia dionisio Nicholene Kieviets susana navarro

Shaun Dookhoo jon rey Gautham Nayak
Janani Dumbleton ricardo rey Erkka Niemi
Lee Edwards bruno kinoshita Andy O´Hara
jane estrada Yasushi Kiyama Katherine O´Keefe
Adrianos Evangelidis daniel koger Hirofumi Onozawa

Guillermo Evans katarina kolich Mehmet Orun
Mario Faria onishi koshi matt osborn
gary mosca Edwin Landale Marcos Ouska

Michael Fraser teresa lau pamela owens
carolyn frey Tom LaVerdure Shailesh Palival
Alex Friedgan Richard Leacton Mijaíl Parfentev
lowell freyman miguel lee melanie parker

shu fulai Marta Lemoine John Partyka
Ketan Gadré Melodía Lewin Bill Penney
Óscar Galindo chen liu Andrés Pérez
alejandro gameiro Manoel Francisco Dutra Lopes Jr. Aparna Phal
jay gardner daniel lopez Jocelyn Sedes
johnny gay Karen López Mark Segall
sue geuens Adán Lynton Ichibori Seiji
Sumit Gupta colin maguire Brian Phillippi R.
gabrielle harrison Michael Mac Intyre Taeza Pittman
Kazuo Hashimoto Kenneth Mackinnon eduardo pok
Andy Hazelwood colin maguire emarie papa

muizz hassan Zeljko Marcan david quan
david heno satoshi matsumoto K Rajeswar Rao
clifford heath George McGeachie abril reeve
Jan Henderyckx Danette McGilvray R. todd reyes
Trevor Hodge Raymond McGirt Scott Raúl RuggiaFrick
marca jinete McLeod scott sammons
José Howard melanie la meca Pushpack Sarkar

Mónica Howat ben manso Juan Schmidt
Bill huennekens steve mepham Nadine Schramm
marca humphries klaus meyer Toshiya Seki

marido zoey Josep Antoni Mira Palacios Rajamanickam Senthil Kumar
toru ichikura toru miyaji sarang shah
Tomas Ihsle ademilson monteiro Gaurav Sharma
Gordon irlandés Daniela Monteiro Vijay Sharma
Fusahide Ito Subbaiah Muthu Krishnan Esteban Jerez
Seokhee Jeon Mukundhan Muthukrishnan jenny shi
Jarred Jimmerson Roberto Myers Satoshi Shimada
cristobal johnson Decano Myshrall Sandeep Shinagare

Wayne Johnson Krisztian Nagy Boris Shuster
SzeKei Jordania kazuhiro narita Vitaly Shusterov
Jorge Kalathoor Mohamad Naser Abi Sivasubramanian
614 • DMBOK2
masacre alicia akira takahashi Roy Verharen

eva herrero steve thomas Karel Vetrovsky
tenny soman Noriko Watanabe Gregg Withers
José Antonio Soriano Guzman José Tejedor miguel wityk
Donald Soulsby cristina weeden Marcin Wizgird
Erich Stahl Alejandro Titov Benjamin WrightJones
Jerry Stembridge Steven Tolkin teresa wylie
james stevens tono toshimitsu Hitoshi Yachida
Jan Stobbe Juan Pablo Torres Saad Yacu
Santosh Subramaniam David Twaddell Hiroshi Yagishita
Motofusa Sugaya Thijs van der Feltz Harishbabu Yelisetty
Venkat Sunkara Elize van der Linde Taisei Yoshimura
Alan Sweeney Peter van Nederpelt
Martín Sikora Pedro Vennel
Índice
Abstracción categoría, 165 Estrategia de macrodatos, 511–12
Abuso piratas informáticos de sombrero negro, 242
intencional, 239 Bases de datos de cadenas de bloques, 177
Involuntario, 239 robot, 229
Acceso, 249 Brandeis, Luis, 53
controles de acceso, 200 Teorema de Brewer, 180
Acceso a datos, 238 Puentes, Guillermo, 575–76
ÁCIDO, 179 Fases de transición de Bridges, 575
Riesgo de Funciones Administrativas y de Auditoría, 254 Traiga sus propios dispositivos (BYOD), 325
publicidad, 243 alineación de negocios, 80
gestión de afiliaciones, 365 Sesgo empresarial, 59
Aiken, Pedro, 39 grupo de continuidad del negocio, 198
Pirámide de Aiken, 40 Plan de Continuidad de Negocio, 197, 281, 327
Instituto Nacional Estadounidense de Estándares, 144 Administrador de datos comerciales, 77, 342
Modelo de información de Ámsterdam, The, 34–35, 35 Glosario de negocios, 90, 92, 427, 580
Modelo analítico, 521–22 Crecimiento empresarial, 220
Norma ANSI 859, 326 Inteligencia empresarial, 57, 63, 384
software antivirus, 256 Portafolio para, 398
Mahout apache, 521 Autoservicio, 408
Acoplamiento de aplicaciones, 281 Herramientas para, 403
Aplicación DBA, 174 Business intelligence y funciones analíticas, 40
Requisitos de seguridad de la aplicación, 261 Metadatos comerciales, 422–23
Arquitectos, 101 Gestión del rendimiento empresarial, 405.
Diagramas de diseño arquitectónico, 115 Reglas de negocio, 289.
arquitectura, 97 Datos críticos y, 474–75
diseños de arquitectura, 116 Integración de datos y, 295
Marco de arquitectura, 102 Vocabulario de negocios, 154
Proyectos de iniciación a la arquitectura, 118 BYOA. Consulte Traiga sus propias aplicaciones
Proceso de archivo, 189, 279 BYOD. Consulte Traer sus propios dispositivos (BYOD)
Principios ARMA GARP®, 340, 343 C, 71
ARMA Internacional, 306 CAD/CAM. Consulte Diseño y fabricación asistidos por computadora
Evaluaciones, 79–80 Canadá Bill 198, 49, 316 Ley de privacidad canadiense
activo, 20 (PIPEDA), 54–55, 236 Identificación de candidatos, 363 Modelo de
software de gestión de activos, 115 datos canónicos, 279–80 Teorema CAP, 180 Proyecciones de
seguimiento de activos, 213 capacidad y crecimiento, 190 CDMP, 65 CDO Puntos de contacto
Flujo de datos asíncrono, 277 organizacionales, 81 Bases de datos centralizadas, 175 Capacidad
Decreto autoritario, 590 de cambio para, 80 Lista de verificación para la gestión, 576–77
lista de autoridades, 312 Leyes de, 574 Sostenimiento, 603 Gestión del cambio, 573 Agente
Actividades de copia de seguridad y recuperación, 327. de cambio, 574, 577, 590, 597 Cambio de datos, 190 Cambio de
archivos de copia de seguridad, 198 captura de datos, 276 Gestión del cambio Comunicación y, 590
software de copia de seguridad, 198 Complacencia y, 577 Errores de, 577–78, 582 Transición y, 575–
BASE, 179 77 Visión para, 578 Change Management Institute, 85
Acuerdo de Basilea II, 247
Captura de datos de cambio de lote, 393
Integración de datos por lotes, 276, 291
Interacción por lotes, 275–76
Principios de Belmont, 52
Parcialidad
Procesamiento de datos y, 58–59
Tipos de, 58–59
Arquitectura de metadatos bidireccional, 433
Grandes datos, 497–99, 502–4
Almacenamiento en la nube y, 520
Principios de, 500
fuentes de, 504
Herramientas para, 517–18
Modelado de grandes datos, 522
615
616 • DMBOK2
Gestores de cambio, 575, 577 Visión Fábrica de Información Corporativa (CIF), 386–88, 388
de cambio, 604 Cuadros y gráficos, Categoría de corrección, 165
57 Director de datos, 81 Director de Covey, Stephen, 598
información, 32 Chisholm, Malcolm, Datos críticos, 474–75
350, 351 Palabras de clase, 161 Datos de riesgo crítico (CRD), 224
Esquemas de clasificación, 313 Conjuntos de datos de referencia cruzada, 354
Informática en la nube, 177, 265 CRUD, 258
Almacenamiento en la nube, 520 Cambio cultural, 119.
Integración basada en la nube, 285 Gestión de las relaciones con los clientes (CRM), 84, 366, 368
CobiT. Ver Objetivos de control para Marco de la función de gestión de datos de DAMA, 35–39, 42
información y tecnología relacionada. Dependencias del área funcional de DAMA, 41
DAMA Internacional, 64
Gestión de datos certificada de DAMA International
Preparación colaborativa, 80 Certificación profesional (CDMP), 65
Colección, 319 Arquitectura de Áreas de conocimiento de DAMA, 40
dispositivos en columnas, 519 Bases de datos en Rueda DAMA, La, 35, 40, 43, 44
columnas, 181 Bases de datos orientadas en la misión de DAMA, 44
columnas, 186–87 Commercial of the Shelf (COTS), DAMADMBOK, 35–39, 43–46
479 Preguntas de comunicación, 103 Plan de Datos
comunicación, 605–6, 608 Ventaja competitiva, 18, análisis, 514
237 Complacencia, 578, 584 Categoría de integridad, Como activo, 17, 20, 23, 52
165 Soluciones de procesamiento de eventos Aceptación comercial de, 411–12
complejos (CEP), 284, 292 Actividades de crítico, 454
cumplimiento, 255–56 Diseño y fabricación asistidos Enfoque ético de, 20
por computadora, 189 Gusano informático, 244 Clasificación de Principios éticos de, 52–53
confidencialidad, 248 Restricciones de datos de confidencialidad, 235 Valor monetario de, 24
Configuración gestión, 409 Herramientas de gestión de configuración, propiedad de, 56
427 Categoría de consistencia, 166 Captura de contenido, 326 Definición Riesgos y, 28, 30
de, 307 Ciclo de vida de, 307 Canales de entrega de contenido, 330 Sensible, 217–20
Métodos de entrega de contenido, 308 Políticas de manejo de contenido, Contenedores de almacenamiento para, 201
324 Arquitectura de información de contenido, 325 Ciclo de vida del tipos de, 29
contenido, 307 Gestión de contenido , 307, 324 Software de gestión de Comprensión de, 18–20
contenido, 311 Sistema de gestión de contenido (CMS), 323, 330, 332 Valor de, 24–25
Metadatos de contenido, 307–8 Modelo de contenidoi ng, 308 Diagrama Acceso a datos, 197
de contexto, 36 Big data y ciencia de datos, 499 Componentes de, control de acceso a datos, 249
37–39 Arquitectura de datos, 100 Gobernanza y administración de Adquisición de datos, 361–62
datos, 69 Modelado de datos, 124 Calidad de datos, 451 Seguridad Administración de datos, 170
de datos, 219 Almacén de datos/inteligencia empresarial, 382 Definido , Agregación de datos, 60
37 Documentos y contenidos, 304 Área de conocimiento, 37 Metadatos, Herramientas de análisis de datos, 485
419 Datos maestros y de referencia, 348 Arquitectura empresarial y de datos, 109
Relación de datos e información, 20, 33
Arquitectos de datos, 101, 567
Arquitectura de datos, 45, 98, 110
Goles de, 99
Pautas de implementación y, 117–18
Artefactos de arquitectura de datos, 90
Gobernanza de la arquitectura de datos, 119
Datos como servicio (DaaS), 285
Activo de datos, 91
Valoración de activos de datos, 77–79
Atributo de datos, 155
Auditorías de datos, 213
Disponibilidad de datos, 227
Captura de datos
Cambio, 276
Categoría de datos, 166
Limpieza de datos, 471
Coherencia de datos, 249
Consumidores de datos, 399
Diccionario de datos, 402, 429
Descubrimiento de datos, 287
Restricciones contractuales, 237; Mejora de datos, 471–72
Actividad de control, 38 Diseño de especificación de intercambio de datos, 290
Objetivos de control de la tecnología de la información y afines, 71 Estándares de intercambio de datos, 286
Vocabulario controlado, 309, 311, 313, 333 Federación de datos, 285
Administrador coordinador de datos, 77 Flujos de datos, 107–9
ÍNDICE • 617
Diagrama, 108 Actividades de gestión de datos
Integración, 291 controlar, 38
Gobierno de datos, 45, 53, 64, 67, 73 Desarrollo, 38
Goles de, 71–72 Operativo, 38
Principios rectores para, 71, 73, 305, 421 Planificación, 38
Implementación de, 88 Marco de gestión de datos, 33
Gestión de problemas, 86 Hoja de ruta para la implementación de la gestión de datos, 32
Gestión de problemas para, 85 Madurez de gestión de datos, 80
cultura organizacional y, 93 plan de gestión de datos, 605
Organizaciones y, 79 Prácticas de gestión de datos, 89, 573.
Trámites para, 87 Evaluación de, 80
Evaluaciones de preparación y, 79–80 Procedimientos de gestión de datos
Cumplimiento normativo y, 70–71 Componentes, 89
Herramientas y técnicas para, 92 Profesionales de la gestión de datos, 17, 573.
Gobierno y gestión de datos, 72 programa de gestión de datos, 609
Comunidad de interés de gobierno de datos, 91 recursos humanos y, 607
consejo de gobierno de datos, 32, 83, 84, 86, 90, 91, 93, 248 Carta del programa de gestión de datos, 32
Marco operativo de gobierno de datos, 83 Declaración del alcance de la gestión de datos, 32
Partes de la organización de gobierno de datos, 74 Estrategia de gestión de datos, 31–33, 94
Organizaciones de gobierno de datos, 73, 91 Componentes de, 32
programa de gobierno de datos, 43 Entregables de, 32
Pautas de implementación para, 93 Mapa de datos, 318, 337
Medición y, 94 Marcado de datos, 60
Cuadro de mando de gobierno de datos, 93 Mercados de datos, 392
Estándares de gobierno de datos, 88–90 Mashups de datos, 511
Comités Directivos de Gobernanza de Datos, 93 Métodos de enmascaramiento de datos, 60, 227, 228, 253
estrategia de gobierno de datos, 31, 82 Migración de datos, 208–9, 292
equipo de gobierno de datos, 445 Minería de datos, 507–8
Manejo de datos Espionaje de minería de datos, 58
Estado actual y, 61 Modelo de datos
Estrategias de mejora y, 62 Integración en, 164
Reducción de riesgos y, 61–62 Versionado de, 164
Ética en el manejo de datos, 49, 51 Gestión de modelos de datos, 360
Perspectivas de datos, 500, 517 Repositorios de modelos de datos, 115
Integración de datos, 59–60, 299 Modelador de datos, 160
Tiempo casi real, 277 Modelado de datos, 45, 123–26
perfilado y, 288 Goles de, 125
Sincrónico, 277–78 Normas para, 161, 162
Integración e interoperabilidad de datos (DII), 45, 269–71, 272, Herramientas de modelado de datos, 115, 209, 295, 430, 485
286 Modelos de datos
Actividades de integración de datos, 286–89 evaluación de, 515
Procesos de integración de datos, 372, 376, 392–94 Movimiento de datos, 272
Soluciones de integración de datos Estándares de nombres de datos, 161
Reglas de negocio y, 295 Operaciones de datos y actividades de almacenamiento, 193–96
diseño de, 289 Orquestación de datos, 291
Mapeo de fuentes y, 290 proceso de análisis de datos, 472
Herramientas de integración de datos, 402–3, 403, 428 parches de datos, 469
Integridad de datos, 226 Política de datos, 77, 83
Ruta de escalada de problemas de datos, 86 Leyes de privacidad de datos, 53–56
Lago de datos, 505 Errores de procesamiento de datos, 193
Ciclo de vida de los datos, 28–29, 41, 287 Productor de datos, 162
Actividades clave del ciclo de vida de los datos, 29 Aplicaciones productoras de datos, 292
Linaje de datos, 264, 287, 298 Ciclo de vida de desarrollo de productos de datos, 400–401
Requisitos de carga de datos, 201 Profesionales de datos, 63, 162
Pérdida de datos, 211 Procesos de perfilado de datos, 288, 470, 476
Gestión de datos, 17, 30–31, 67 Herramientas de perfilado de datos, 295, 485
Retos de, 20 Calidad de los datos, 25–26, 46, 449–52, 453–54
Consumidores para, 38 Goles de, 452–53
Calidad de los datos y, 25 Normas ISO para, 461–62
Perspectiva empresarial y, 27 Medición de, 479–81
Goles de, 18 Procesos de información sobre, 484
Iniciativas y, 84 Estadísticas sobre, 25
Entradas y, 38 Diseño de sistemas y, 468
Metadatos y, 417–19 Análisis de calidad de datos, 80
Participantes en, 38 Evaluación de la calidad de los datos, 475.
Hardware especializado para, 182 Reglas comerciales de calidad de datos, 25–26
618 • DMBOK2
Dimensión de calidad de datos, 454–60 Equipo para, 86, 91
objetivos de calidad de datos, 477 Almacenamiento de datos y operaciones, 45
Mejora de la calidad de los datos Áreas de almacenamiento de datos, 391–92
Cambio cultural y, 492–93 Entorno de almacenamiento de datos, 201
Pautas de implementación para, 490–91 Metas de almacenamiento de datos, 171, 181
Evaluación de riesgos y, 491 Gobierno del almacenamiento de datos, 213
Ciclo de vida de mejora de la calidad de los datos, 462–64 Métricas de almacenamiento de datos, 212
Problemas de calidad de datos Sistemas de almacenamiento de datos, 184–89
Causas de, 465–70 estrategia de datos, 32
Acciones correctivas y, 486–87 Componentes de, 32
Entrada de datos y, 466 propiedad de, 32
Tratamiento de datos y, 468 Estructuras de datos, 290
Liderazgo y, 465–67 Requisitos de tecnología de datos, 194
parches de datos manuales y, 469 Transformación de datos, 397, 473
Procedimientos operativos para, 481–83 Motor de transformación de datos, 294
Acciones preventivas y, 486 Validación de datos, 213, 362
Métricas de calidad de datos, 494 Valoración de datos, 24–25
Política de calidad de datos, 493–94 Bóveda de datos, 393
Gobierno del programa de calidad de datos, 493 virtualización de datos, 285
estrategia de calidad de datos, 474 Servidores de virtualización de datos, 294
Plan de recuperación de datos, 197 Visualización de datos, 510–11, 516, 520
software de recuperación de datos, 198 Almacén de datos, 381–83, 384
Reglamento de datos, 220, 248 Aproximaciones a, 385
Reparación de datos, 60, 397 Captura de datos de cambios por lotes para, 393
Proceso de replicación de datos, 191, 202 Factores críticos de éxito para, 523
Plan de retención de datos, 193, 286 Pistas de desarrollo para, 396
Riesgos de datos, 70 Goles de, 383
Plantillas de reglas de datos, 485 Gobernanza en, 411
Escalado de datos, 191 Datos históricos y, 392–93
Ciencia de datos, 497–502, 514 Población de, 397
Herramientas de ciencia de datos, 517–18 Requisitos de, 394
Seguridad de datos, 45, 193, 217–20 Almacenamiento de datos, 46, 385
Declaración de Derechos, 252 Factores críticos de éxito, 410
Requisitos comerciales, 217–20, 245 base de datos, 172
Goles de, 222 Jerárquico, 184
Supervisión de, 226, 253–55 multidimensional, 185
Subcontratación, 264 temporal, 185
contraseña para, 234 Tipos de, 175
Requisitos reglamentarios para, 246 Abstracción de base de datos, 172
Requisitos para, 225 control de acceso a base de datos, 200
Evaluación de riesgos y, 262–63 Administrador de base de datos (DBA), 170, 173, 194, 195, 196, 201,
Declaración de derechos de seguridad de datos, 252 211–12
Gobernanza de seguridad de datos, 265 Base de datos como servicio (DaaS), 178
Gestión de seguridad de datos Disponibilidad de la base de datos
Cuatro A de, 225 Factores que afectan, 204
Principios rectores para, 222 Factores de pérdida de, 204
Política de seguridad de datos, 247–48, 251 Criterios en línea para, 204
Prácticas de seguridad de datos, 262. Copia de seguridad de la base de datos, 198
Requisitos de seguridad de datos, 218 Catálogos de bases de datos, 428
Restricciones de seguridad de datos, 234–37 ejecución de base de datos, 205
Riesgos de seguridad de datos, 220 Técnicas de registro de bases de datos, 393
Estándares de seguridad de datos, 245, 248 Gestión de base de datos
Vocabulario de seguridad de datos, 229–32 Cambio organizacional y, 211–12
Servicios de datos, 291 Sistema de gestión de bases de datos (DBMS), 185
Acuerdos de intercambio de datos, 298, 377 Tecnología de gestión de bases de datos.
Gobernanza de fuentes de datos, 413 convenciones de nomenclatura y, 210
Fuentes de datos, 512–13 Archivos de script y, 210
Evaluación de, 370–72 software para, 194
Ingerir, 512–13 Herramientas, 209
Normalización de datos, 473. Herramientas de gestión de bases de datos, 209
Comité Directivo de Estándares de Datos, 89 Herramientas de monitoreo de bases de datos, 209
Administradores de datos, 76–77, 90, 247, 252, 255, 263, 356, 371 Espectro de organización de base de datos, 184
Coordinando, 77 Rendimiento de la base de datos
Ejecutivo, 76 Seguimiento para mejorar, 205;
Administración de datos, 75 Tuning para mejorar, 173
Comité para, 86 Procesos de base de datos
ÍNDICE • 619
Archivo, 189 Bases de datos distribuidas, 175
Proyecciones de capacidad y crecimiento de, 190 Tecnologías de soluciones basadas en archivos distribuidos, 519–20
Cambiar datos dentro, 190 Pirámide DMBOK, 39–40 Documento/registro, 315 Auditoría de, 329
Purga, 191 Gestión de, 328 Retención de, 328 Conocimiento de documentos y
Réplica de, 191 contenidos, 305–6 Gestión de documentos y contenidos, 45, 303
Resiliencia de, 192 Cumplimiento normativo y, 304–5 Sistema de biblioteca de
Retención de, 193 documentos, 330 Gestión de documentos, 305, 315–17, 323, 331
fragmentación de, 193 Sistema de gestión de documentos, 330 Herramienta de gestión de
Procesamiento de bases de datos, 179 documentos, 93 Repositorio de documentos, 331 Desinfección de
Sistemas de almacenamiento de bases de datos, 196. documentos, 262 Desglose, 407 Dublín Núcleo, 309 métricas de
Soporte de base de datos, 169, 196 uso de DW, 413 arquitectura DW/BI, 395 método de enmascaramiento
Tareas de administración de sistemas de bases de datos, 199 de datos dinámicos, 228 ECM. Consulte Evaluación de preparación de
tecnología de base de datos ECM de Enterprise Content Management Systems, 338 Ediscovery,
Gestión, 194–96 305, 336 Indicadores clave de rendimiento (KPI) y, 343–44 Evaluación
Seguimiento de, 195 de Ediscovery, 339 EDM. Consulte Modelo de datos empresariales
apoyo de, 170 EDRM. Ver modelo de referencia de descubrimiento electrónico (EDRM)
bases de datos
Entornos alternativos para, 207 Centralizado,
175 Basado en columnas, 181 Orientado a
columnas, 186–87 Carga de datos y, 201
Entorno de desarrollo y, 182 Distribuido, 175
Archivo plano, 187 Par clavevalor, 188
Multimedia, 187 No relacional, 186 Objeto/
Multimedia, 187 Procesos de, 189–93 Relacional,
185 Espacial, 187 Especializado, 188 Triplestore,
188 Tipos de, 184–89 Patrones de uso de, 196
Proceso de bases de datos, 189–93 Organización
centrada en datos, 73 DBA. Ver Administrador
de base de datos Sistemas de soporte de Intercambio electrónico de datos (EDI), 266 Modelo
decisiones (DSS), 381 Contraseñas de referencia de descubrimiento electrónico (EDRM), 318 Documentos
predeterminadas, 241 Categoría de definiciones, electrónicos, 318 Aplicaciones de punto de venta electrónico (EPOS),
166 Deming, W. Edward, 51 Desnormalización, 309 Registros electrónicos, 305, 323 Tecnología electrónica y crecimiento
150 Revisión de diseño, 163 Destino (VISION), comercial, 221 ELT. Consulte Flujo de proceso de ELT de extracción,
575 Riesgo de detección y recuperación, 254 carga y transformación, 275 Cifrado, 226, 227, 241, 258, 262 Inglés,
Herramientas de soporte para desarrolladores, Larry, 457 Enriquecimiento, 362 Modelo de integración de aplicaciones
209 Desarrolladores, 183 Actividad de desarrollo, empresariales (EAI), 283 Marco arquitectónico empresarial, 102–4
38 DBA de desarrollo, 174 Entorno de desarrollo, Arquitectura empresarial, 98 , 109, 110, 265 Activo empresarial, 17
182, 183 Políticas de acceso a dispositivos, 325 Gestión de contenido empresarial (ECM), 307 Cambio cultural y, 339
Sistema decimal Dewey, 313 Dados, 406 Acuerdo Directrices para, 337 Indicadores clave de rendimiento (KPI) y, 344
clave DiffieHellman, 227 Teoría de difusión de Arquitectura de datos empresariales, 119–23 Comité directivo de
innovaciones, 599 Gestión de activos digitales (DAM), arquitectura de datos empresariales, 90 Consejo de gobierno de datos
318, 331 Gobernanza DII, 297–98 Soluciones DII, empresariales, 74 Modelo de datos empresariales, 90, 105–7, 106
293 Almacén de datos dimensional, 388–90 Directorio, Almacén de datos empresariales, 385 Herramienta de integración
428, 429, 430 Plan de recuperación ante desastres, empresarial, 296–97 Formato de mensaje empresarial, 279 Perspectiva
327 Desastres, 192 Descubrimiento, 80, 287, 318– empresarial y gestión de datos, 27 Planificación de recursos
20 Almacenamiento en disco, 181 empresariales (ERP), 84, 201, 271, 368 Bus de servicio empresarial
(ESB), 281, 283, 294 Estándares empresariales, 289 Resolución de
entidad, 362 Hexágono de factores ambientales, 35, 36 Relación de
términos equivalentes, 311 ERP. Consulte Planificación de recursos
empresariales Gestión ética de datos, 49, 51, 60–61, 61–62, 62, 64
Gestión ética de datos, 49, 57 Modelo de riesgo ético, 64 Riesgos éticos,
59
620 • DMBOK2
Ética, 49 Sistema de gestión de almacenamiento jerárquico, 187
Flujos de datos ETL, 291 Taxonomía jerárquica, 312 Datos de alto riesgo (HRD), 224
Flujo de procesos ETL, 274 Datos históricos, 392–93 HOLAP. Véase Procesamiento
Procesos ETL, 485 Acuerdo analítico en línea híbrido Copias de seguridad activas, 198
de Basilea II de la UE, 247 Patrón de datos concentrador y radio, 279 Modelo de interacción
Directivas de privacidad de la UE, concentrador y radio, 280–81 Procesamiento analítico en línea
236 Convenio Europeo de Derechos Humanos, 53 híbrido, 407 Identidad, 56 Tecnología de administración de
Supervisor Europeo de Protección de Datos, 52 Método identidad, 257 Resolución de identidad, 364 IM. Ver Mensajería
de procesamiento de eventos, 284, 292 Evento integración instantánea (MI)
de datos impulsada, 277 Everett Rogers Difusión de
innovaciones, 600 Privilegios excesivos, 238 Administradores
ejecutivos de datos, 76 Interfaz de marcado extensible, 334
Lenguaje de marcado extensible, 334 Datos externos, 202
ExtraerCargarTransformar (ELT), 274 Proceso de extracción, Tecnología de procesamiento de imágenes, 331–
el, 273 ExtraerTransformarCargar (ETL), 205, 273, 275 32 Imhoff, Claudia, 386 Explicación de
Taxonomías facetadas, 311, 313 Ley de privacidad y derechos inconsistencias, 597–98 Algoritmo en base de
educativos de la familia, 237 FASB. Consulte la Junta de datos, 520 Indexación, 157 Datos de referencia
Normas de Contabilidad Financiera Integración rápida de de la industria, 356 Regulaciones basadas en la
datos, 278 Reglas Federales de Procedimiento Civil, 316 industria, 237 Investigación de tecnología de
Comisión Federal de Comercio, 55 Arquitecturas federadas, información y comunicación, 52 Información y
176 Datos de disposiciones de la Federación, 176 FERPA. relación de datos, 20 Arquitectura de la información,
Consulte la Ley de Privacidad y Derechos Educativos de la Familia 320 Activo de la información, 30 Seguimiento de los activos de la información,
Junta de Normas de Contabilidad Financiera, 87 Activos financieros, 213 Consumidor de la información, 162 Arquitectura del contenido de la
23 Datos maestros financieros, 367 Datos financieramente información, 329 Consejo de la información, 342 Economía de la información,
confidenciales, 237 Cortafuegos, 230, 257 Memoria flash, 182 Bases 17 Brechas de información, 30, 91 Gobernanza de la información, 340–42
de datos de archivos planos, 187 Folcsonomías, 309, 313 Marcos. Modelo de madurez de la gobernanza de la información (IGMM) , 338 Modelo
Consulte Marcos de gestión de datos Libertad de expresión, 56 de referencia de gobierno de la información (IGRM), 341 Iniciativa de cambio de
GASB. Consulte la Junta de Normas de Contabilidad del Gobierno (EE. UU.) gestión de la información, 588 Contexto de gestión de la información, 596
Disciplinas de gestión de la información, 52 Cambio de calidad de la información,
599 Seguridad de la información Clasificación de datos y, 220 Técnicas de
gestión, 258–59 Herramientas utilizadas en, 256–58 Vocabulario para, 223–24
Reglamento general de protección de datos, 54
Principios de mantenimiento de registros generalmente aceptados,
338 Clasificación geográfica, 356 Sistemas de información geográfica
(SIG), 325 Datos de referencia geoestadísticos, 356 Geuens, Sue, 40
Fórmula de Gleicher, 577 Glosario, 90 Godin, Seth, 599 Registro de Seguridad de la Información y Asesoría Corporativa, 255
oro , 358–59 Buena voluntad, 20 Gobernanza. Véase también Equipo de seguridad de la información, 224–25
Gobierno de datos Consejo de Normas de Contabilidad del Gobierno Método de planificación de sistemas de información (ISP), 109
(EE. UU.), 87 Aplicaciones de diseño gráfico, 115 Group Think, 589 Tecnología de la información y gestión de datos, 30–31
Principios rectores Gobierno de datos, 71, 73, 305, 421 Gestión de Biblioteca de infraestructura de tecnología de la información (ITIL), 194, 199
seguridad de datos, 222 Hacking/Hacker, 241 Hadoop, 519 Algoritmos Bases de datos en memoria (IMDB), 181
hash, 177 Cifrado hash, 227 Ley de Portabilidad y Protección de Inmón, Bill, 385
Información de Salud (EE. UU.), 49 Ley de Responsabilidad y Innovación, 601
Portabilidad de Información de Salud (HIPAA), 254 Organización Mensajería instantánea (MI), 244
jerárquica de la base de datos, 184 Relación jerárquica, 312 Integración sistema basado en la nube, 285
Pruebas de integración, 183
Abuso intencional, 239;
Interacción, 280–81, 290
Hubandspoke, 280–81 punto a
punto, 280
Publicar y suscribir, 281;
Requisitos de integración interna, 285;
Sistema de detección de intrusos (IDS), 240, 257
Sistema de prevención de intrusiones (IPS), 239, 240, 257
islas de datos, 249
ISO 15489, 316
ISO 8000, 461
Código estatal ISO, 354
ÍNDICE • 621
Gestión de problemas, 86–87 Categorización y, 324
Gobierno de TI, 71 ITIL. Ver Contenido, 307–8 Calidad
Biblioteca de infraestructura de tecnología de la información (ITIL) de los datos y, 461 Riesgos
JSON. Ver Notación de objetos de JavaScript (JSON) de los datos y, 418 Definición
Principio ético de justicia/equidad, 58 de, 417 Mecanismos de
Intercambio de claves, 227 Indicadores entrega de, 439 Directorio de, 429
clave de rendimiento (KPI), 343 Clavevalor, 144 Análisis de impacto de, 441–43
Base de datos de pares clavevalor, 188 Kimball, Importancia de, 417–19 Integración
Ralph, 388 Agrupación de KMeans, 514 de, 439 Gestionado entorno para,
Conocimiento, 18 Kohonen M, 508 Kotter , John 436 Gestión de, 308 Repositorio
P., 578, 581, 582, 584, 586, 593 Diseño de para, 426, 440 Modelo de repositorio
arquitectura Lambda, 181 Latencia, 275 Leyes para, 437 Alcance de, 434 Fuentes
del cambio, 574 Manifiesto de datos del líder, de, 425–26 Tipos de, 422–24 No
El, 31, 450 Liderazgo, 588 Alineación de liderazgo, confiable, 60 Datos no estructurados
560 Datos maestros legales, 367 Abuso legítimo de y, 307, 424–25 Usos de, 440
los privilegios de la base de datos, 238–39 Arquitectura de metadatos, 431, 433
Cumplimiento de los acuerdos de licencia, 213 Gestión Centralizada, 431 Distribuida, 432
del ciclo de vida, 41, 323 Lista, 353–54 Manual de Entorno de metadatos, 444
litigios, 336 Procesos de carga, 274, 401 Datos Gobernanza de metadatos, 445 Iniciativas
maestros de ubicación, 368 Envío de registros frente de metadatos, 445 Aprovechamiento de
a duplicación, 192 Nombres de datos lógicos, 161 metadatos, 420 Sistema de gestión de
Escenario de CEO solitario, 587 Sistemas débilmente metadatos, 436 Herramientas de gestión
acoplados, 177 Loshin, David, 351 Comité de baja de metadatos, 440 Registros de metadatos
credibilidad, 587 Aprendizaje automático, 506–7, 507 (MDR), 210 Estándar de registro de metadatos,
Catálogo legible por máquina, 331 Hacker malicioso, 424 Repositorio de metadatos, 402 Metamodelo
242 Malware, 242 Alojamiento de base de datos de repositorio de metadatos, 437 Modelo de
administrado, 178 Ciclo de vida de administración, 316 repositorio de metadatos, 258, 296, 436–37
Gestores, 586 Herramientas de gestión de mapeo, 429 Requisitos de metadatos, 435–36 Estándares
Proceso de mapeo, 275 MapQuest, 189 MapReduce, de metadatos, 437, 446 Almacenes de
176 MARC. Consulte el catálogo de lectura mecánica metadatos, 430 Estrategia de metadatos, 434
Market timing, 57 Martin, James, 109 Mashups, 511 Fases, 435 Evaluación de riesgos y 444
Procesamiento masivo en paralelo (MPP), 517, 518– Metadatos etiquetas, 443 Metadatos, 447 M
19 Datos maestros, 347–48, 357 etrics, 94, 259 Protección de datos, 261
Seguridad, 259–60 Conciencia de seguridad, 260
Vocabulario microcontrolado, 311 Microgestión, 590
Visualizaciones engañosas, 57 Síndrome de misión
cumplida, 581 Modelos y diagramas Claridad de, 116–
17 Datos de riesgo moderado (MRD ), 224 MOLAP.
Véase Procesamiento analítico en línea
multidimensional Supervisión de la autenticación,
253 Morris, Henry, 405 Tecnologías de bases de datos
multidimensionales, 185 Expresión multidimensional,
185 Procesamiento analítico en línea multidimensional,
407 Replicación multimaestro, 191 Base de datos
multimedia, 187 Base de datos multitemporal, 185
Nacional Modelo de intercambio de información
(NIEM), 286 Modelo casi en tiempo real, 295 Datos
casi en tiempo real, 394 Administradores de
almacenamiento de red (NSA), 196
Impulsores comerciales y, 349
Política de gobierno y, 373
Gestión de ID de datos maestros, 365
Integración de datos maestros, 369
Gestión de datos maestros (MDM), 70, 359–61, 370–71, 372 Objetivos
de, 349–50 Herramientas y técnicas de, 375 Arquitectura de
intercambio de datos maestros, 370, 376 Coincidencia. Consulte
Identificación de candidatos Coincidencia de flujos de trabajo, 364
Supervisión de medios, 507 Datos médicamente confidenciales, 237
Informe Menlo, 52 Interacción de mensajería, 394 Metadatos, 19, 27,
46, 221, 417
622 • DMBOK2
Taxonomía de red, 313 PIPEDA. Ver Protección de Datos Personales y Electrónicos
Dispositivo de auditoría basado en red, 254 Acta de Documentación
Zona neutral, 575 Marco de gestión de riesgos Pivot, 407 Planificación de la
NIST, 225 Nodo, 172 Base de datos no relacional, actividad, 38 PMO. Consulte
186 NoSQL, 124, 129, 130, 136, 137, 143, 144, POC de la oficina de gestión de proyectos.
152, 154, 165, 188, 196, 334 Nulidad, 165 Consulte Prueba de concepto Modelo de
Ofuscación de datos, 60, 227, 228 Objeción al tratamiento de datos interacción punto a punto, 280 Políticas y manejo
personales, 54 Observabilidad, 603 OCM. Ver Gestión del cambio de contenido, 324 Política Seguridad de datos,
organizacional (OMC) 247 Gobernanza política, 73 Polijerarquía, 313
Portabilidad, 54 Algoritmos predictivos, 59
Análisis predictivo, 508–9, 515 Lenguaje de
marcado de modelo predictivo (PMML), 521
Modelos predictivos, 514 Entornos de
Software OCR, 330 preproducción, 182 Análisis prescriptivo, 509
ODBC. Consulte OLAP de conectividad abierta de Preservación, 319 PRISM, 161 Ley de privacidad
bases de datos. Consulte Procesamiento analítico canadiense, 54–55 Cifrado de clave privada, 227 Privilegios Base
en línea OLTP. Ver Procesamiento de transacciones en línea (OLTP) de datos legítima, 238–39 No autorizado, 239 DBA de
Procesamiento analítico en línea, 405 procedimiento , 174 Controles de procesos, 282 Datos de
Datos en línea Usos éticos de, 56 Libertad productos en sistemas de ejecución de fabricación (MES), 368
de expresión en línea, 56 Procesamiento Gestión de datos de productos (PDM), 368 Gestión del ciclo de
de transacciones en línea (OLTP), 189 vida de productos (PLM), 367 DBA de producción, 173, 174
Ontología, 102, 314, 355 Conectividad de base de Entorno de producción, 182 Oficina de gestión de proyectos, 84
datos abierta, 172 Estándar de Open Geospatial Prueba de concepto, 195 Datos de referencia de propiedad,
Consortium, 187 Marco operativo, 71 Actividad 356 Políticas públicas y leyes, 53 Cifrado de clave pública, 227
operativa , 38 Análisis operativo, 510 Almacén de datos Modelo de publicación y suscripción, 281 Depuración, 191
operativos (ODS), 392 Metadatos operativos, 423 Certificación de control de calidad, 173 Pruebas de control
Informes operativos, 387, 395, 404 Datos de de calidad (QA), 183 Qual ity data Alto, 473–74 Métricas
orquestación, 291 Proceso de orquestación, 282 para, 487–88 Datos de auditoría consultables, 408 Control de
Organización Cambio cultural y, 119 Centrado en datos, acceso a nivel de consulta, 238 RACI. Ver Responsable,
73 Organización para la cooperación económica Responsable, Consultado e Informado
operación y desarrollo (OCDE), 53 Comportamiento
organizacional, 92 Gestión del cambio organizacional
(OCM), 85–86 Organizaciones y cambio cultural, 263,
297 Subcontratación y seguridad de datos, 264 OWL.
Consulte W3C Web Ontology Language Propiedad
de los datos, 56 Datos maestros de las partes, 366–
67 Contraseña, 234, 257 Estándar de seguridad de datos de la industria de
tarjetas de pago (PCIDSS), 87,
237, 247
PCI obligaciones contractuales, 236 PCI
DSS. Consulte el Estándar de seguridad de datos de la industria de tarjetas de
pago (PCIDSS) RDBMS. Ver Sistema de administración de bases de datos relacionales
Métricas de desempeño, 119–23 (RDBMS)
Pruebas de desempeño, 183 RDF. Ver Marco de descripción de recursos (RDF)
Perímetro, 230 Método de Categoría de legibilidad, 166
enmascaramiento de datos persistente, 227 Evaluación de preparación, 210
Datos personales, 54 Información de salud Really Simple Syndication (RSS), 309 Datos en
personal (PHI), 237 Protección de información tiempo real, 394 Flujos de integración de datos
personal y en tiempo real, 292 Solución de procesamiento
Ley de Documentación, 49 de datos en tiempo real, 293 Sincronización de
Información personal privada (PPI), 236 datos en tiempo real, 277–78 Calidad de registro,
PGP (Privacidad bastante buena), 227 342 Registro sistema de, 358 Registros, 315
suplantación de identidad, 242 Gestión de registros, 305, 317–18, 323, 332
activos físicos, 23 Documentos electrónicos y, 318 Indicadores clave
Nombres de datos físicos, 161 de rendimiento (KPI) y, 343
Listas de selección, 311
ÍNDICE • 623
Modelo de madurez para, 338–39 SAN. Consulte Red de área de
Principios de, 306 almacenamiento Sandbox, 184 Sarbanes
Tipos de recuperación, 192 Oxley Act, 30, 49, 71, 254, 316 Scaling. Ver Repositorios
Redacción de datos, 60 de escaneo de escalado de datos, 439 Esquema, 172
Datos maestros y de referencia, 46 Schema.org, 336 Categoría de esquema, 165
Datos de referencia, 351, 350–57 Optimización de motores de búsqueda (SEO), 321,
Cambio y, 376–77 324 Actos de violación de seguridad de la información,
Geoestadística, 356 236 Administradores de cumplimiento de seguridad,
Industria, 356 253 Métricas de seguridad, 259–60 Parches de seguridad,
ontologías y, 355 258 Cumplimiento de la política de seguridad, 255–56
dominical, 356 Datos de restricciones de seguridad, 234–37 Evaluación
estándar, 357 de riesgos de seguridad de, 250 Mapas autoorganizados,
estructura, 353 508 Modelado semántico, 321 Búsqueda semántica, 321
Taxonomías en, 355 Datos semiestructurados, 322 Datos confidenciales, 221–
Gestión de datos de referencia, 430 22, 325 Opinión análisis, 507 Equipos de administración
Conjuntos de datos de referencia de servidores, 205 Virtualización de servidores, 178
Evaluación de, 373 Cuentas de servicio, 239–40 Acuerdos de nivel de servicio
Gobernanza y, 375 (SLA), 203, 412, 483–84 Registro de servicios, 430
Directorios de referencia, 368 Arquitectura basada en servicios (SBA), 505–6 Proceso de
Datos regulados, 236 Información fragmentación, 193 Cuentas compartidas, 240 Tecnologías
regulada, 248 Clasificación de bases de datos de nada compartido, 518 Ciclo de
regulatoria, 252 Cumplimiento normativo, Shewhart/Deming, 462 Sistema de organización del
87 Gobierno de datos y, 70 Preguntas conocimiento simple (SKOS), 335 Regulaciones
sobre, 87 Requisitos regulatorios y unifamiliares, 236–37 SKOS. Consulte SLA del sistema de
seguridad de datos, 246 Riesgo organización del conocimiento simple. Ver Acuerdos de
regulatorio, 254 Transformaciones de cosificación , 103 nivel de servicio Sliceanddice, 406 SMART, 32 Smartphone, 602
Relación de términos relacionados, 312 Base de datos Ingeniería social, 242 Políticas de redes sociales, 324 Sitios de redes
relacional, 185 Sistema de gestión de bases de datos sociales, 244 Sistema social, 601 Amenazas sociales, 242 Software
relacionales (RDBMS), 185 OLAP relacional, 407 Ventaja como servicio (SaaS), 285 Configuración de software (SCM), 199
relativa, 602 Gestión de versiones, 399 Remediación, 397 Proceso de prueba de software, 207 Unidades de estado sólido
Replicación, 191 Patrones de replicación Envío de registros, 192 (SSD), 182 Solvencia II, 30, 87 Asignación de origen a destino, 396
Duplicación, 192 Proceso de replicación, 202 Esquema de replicación, 193 Sousa, Ryan, 386 Spam, 244–45 Base de datos espacial, 187 Base
Soluciones de replicación, 278–79 Estrategias de generación de informes, de datos especializada, 188 Hardware especializado, 182 Spyware,
412–13 Escaneo de repositorio, 439 Análisis de requisitos, 155 Resiliencia, 243 Ataque de inyección SQL, 241 Etapas de adopción, 601–2 Análisis
192 Marco de descripción de recursos (RDF), 335 Esquema de marco de de las partes interesadas y planificación de la comunicación, 606
descripción de recursos (RDFS), 314 Responsable, Responsable, Estándar, 88 Lenguajes de marcado estándar, 333–34 Datos de
Consultado , e informado, 264 Recuperar métricas de respuesta o referencia estándar, 357 Estandarización, 362 Categoría de estándares,
desempeño, 414–17 Derecho al olvido, 56 Riesgo, 223–24 Evaluación 165 Estándares , seguridad de datos, 245, 248 Esquema en estrella,
de riesgo nt, 210 Clasificaciones de riesgo, 224 Modelo de riesgo, 63 388
Riesgo de dependencia de herramientas de auditoría nativas inadecuadas,
254 Reducción de riesgos y seguridad de datos y, 220 RivestShamir
Adelman (RSA), 227 Hoja de ruta, 111–13, 409 Rogers, Everett, 599
ROLAP. Ver Procesamiento analítico relacional en línea Cuadrícula de
asignación de roles, 250 Jerarquía de asignación de roles, 250 Resumen,
407 Análisis de causa raíz, 490 Aplicaciones SaaS. Consulte también
Datos como servicio (SaaS)
624 • DMBOK2
'Suavizado' estadístico, 58 base de datos triplestore, 188
Control estadístico de procesos, 488–90 caballo de Troya, 243
Mayordomía, 366, 372, 374 Fuente confiable, 358–59
Red de área de almacenamiento (SAN), 181, 196 Elevación de privilegios no autorizados, 239
Gestión del entorno de almacenamiento, 199–200 Localizadores uniformes de recursos (URL), 321
Soluciones de almacenamiento, 279 Abuso involuntario, 239;
Modelo de alineación estratégica, 33–35 Datos no estructurados, 322
plan estratégico, 31 Gobernanza y, 342 Gestión
estrategia, 31 de, 342 Metadatos para, 307
transmisión, 394 Análisis de datos no
Marco de StrongWang, 455 estructurados, 509 Urgencia, 583, 584
Categoría de estructura, 165 Reglas federales de procedimiento civil
Lenguaje de consulta estructurado (SQL), 185 (FRCP) de EE. UU., 318 Requisitos de la FTC de EE. UU., 236
Cobertura de área temática y almacén de datos, 413 Clasificación de la Biblioteca del Congreso de EE. UU., 313 Códigos
Discriminador de área temática, 107 estatales del servicio postal de EE. UU. , 354 Ley de privacidad de
Modelo de área temática, 107 EE. UU., 53 Prueba de aceptación del usuario (UAT), 183 Titularidad
Gobernanza de datos de sostenibilidad y, 91, 94 de los datos del usuario, 263 Informática utilitaria, 178 Validación,
Sindicación, 308 362 Valor de los datos, 17 Imagen de máquina virtual, 178 Máquinas
Anillo sinónimo, 312 virtuales (VM), 184 Virtualización, 177–78 Virus , 243 Visión
base de datos del sistema, 201 Comunicando el, 586–88, 595–96 Efectivo, 592–93 Encuadre, 604
Ciclo de vida de desarrollo del sistema (SDLC), 126, 298 Importancia de, 591 Visualización, 57, 510–11, 516 Registro vital,
Sistema de registro, 358. 317 Vocabulario controlado, 309, 311, 313, 333 Micro controlado,
Riesgos de seguridad del sistema, 238. 311 Manejo de vocabulario. Véase también Vocabulario controlado
Taxonomía, 312, 355, 397 Vista de vocabulario, 310–11 Vulnerabilidad, 223 W3C Web
faceta, 313 Ontology Language (OWL), 335 Warren, Samuel, 53 Wearyour
facetado, 311 owndevices (WYOD), 325 Dirección web, 256 Sitios web, 92 Pirata
jerárquico, 312 informático de sombrero blanco, 242 Desarrollo de contenido de
red, 313 flujo de trabajo y, 322 Herramientas de flujo de trabajo, 93, 333
costo total de propiedad, 213 Gusano, computadora, 244 WYOD. Consulte Useyourown
Herramientas de colaboración en equipo, 333 devices (WYOD)
Equipo, construyendo un, 589
Metadatos técnicos, 423
Preparación tecnológica, 210
base de datos temporal, 185
Gestión de plazos, 311–12
Términos, 311
Datos de prueba, 208
Entorno de prueba, 183
Minería de textos, 507–8
Las cuatro A de la gestión de la seguridad de datos, 225
El Reglamento General de Protección de Datos de la UE, (GDPR),
54
Datos de terceros, 202
Amenazas, 223, 242
Sistemas estrechamente acoplados,
177 Tiempo, 57 Costo total de propiedad
(TCO), 213 Secretos comerciales, 237 Copia de
seguridad del registro de transacciones, 198
Volcado, 198 Proceso de transformación, 273
Gestión de transición. Véase también XMI. Consulte XML de interfaz de marcado
Gestión de cambios Transición, lista de extensible. Consulte Bases de datos XML de lenguaje
verificación para la gestión, 576–77 Feeds de marcado extensible, 189 Zachman Framework,
lentos, 394 102, 103, 104 Zachman, John A., 102

DAMA DMBOK v2 (394-628) .En - Es

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

DAMA DMBOK v2 (394-628) .En - Es

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Puesta en escena de datos Datos Acceso a los datos

Método Complejidad de los requisitos del sistema de origen Hecho Dimensión Eliminaciones superpuestas

Entradas: Actividades: 1. Entregables:

Cuerpos comerciales • Analistas de sistemas • Trabajadores del

Técnicas: • Linaje Herramientas: Métricas: •

Análisis • Herramientas de gestión Tanteador

BI Modelado ETL Servicios SGBD Referencia Datos Mensajería Configurar

Modelo de datos Almacén de datos Glosario

Atributo Campo/Columna Conjuntos de códigos Valor del código Valor de negocio

Historial de pedidos orden activa Pedido pendiente total

Entradas: Actividades: Entregables:

• Calidad de datos 3. Definir el Alcance de la Evaluación Inicial (P) • Organización del programa de

Proveedores: Participantes: • CDO Consumidores:

Falta de educación Información

Practicante educación Administrado

Dimensión y Medida Métrica Estado

La población del campo completan los datos, registros en la tabla o base de datos y multiplíquelo 80% de población

completarse en la tabla Recuento no poblado: Medida negativa: Inaceptable

Debe haber solo un identificados; informar sobre y multiplíquelo por 100

Ejemplo 2: Recuento de duplicados: 10,000/1,000,000*100 = 1.0% de los códigos Resultado

sólo una fila actual Conteo total: 1,000,000 fila Inaceptable

granularidad Tratamiento en corriente (Flujo en proceso) Tratamiento por lotes

Entradas: Actividades: 1. Entregables:

Proveedores: Participantes: Consumidores:

Técnicas: Herramientas: Métrica:

Retrospectiva Profético Preceptivo

descriptiva Visión Previsión

Velocidad Variedad Veracidad

Almacenamiento EDW/BW web 2.0 Internet de las Cosas

Entradas: Actividades: Entregables:

Marcos y 2. Realizar la evaluación 3. • Inversión y

Proveedores: Participantes: Consumidores:

Técnicas: Herramientas: Métrica:

Selección • Plan de Comunicaciones • Utilización de recursos

facilitador organizacional datos • Métricas de rendimiento calidad de los datos y la

Datos Solicitud Negocio Datos

Negocio Datos Datos Técnico

Gestión Gestión Gestión

Negocio Negocio Negocio

Conocimiento Persuasión Decisión

Jalid Abu Shamleh mike beauchamp Susana Burk

Zaher Alhaj León Bernal pedro campbell

Ricardo Volver Ciaran Breen Elisio Henrique de Souza

Ian Batty Pablo marrón Tejas Desaí

cynthia dionisio Nicholene Kieviets susana navarro

Adrianos Evangelidis daniel koger Hirofumi Onozawa

gary mosca Edwin Landale Marcos Ouska

carolyn frey Tom LaVerdure Shailesh Palival

Alex Friedgan Richard Leacton Mijaíl Parfentev

lowell freyman miguel lee melanie parker

Andy Hazelwood colin maguire emarie papa

José Howard melanie la meca Pushpack Sarkar

marca humphries klaus meyer Toshiya Seki

cristobal johnson Decano Myshrall Sandeep Shinagare

masacre alicia akira takahashi Roy Verharen

También podría gustarte