El Rincon del BI

Descubriendo el Business Intelligence…

Archive for the ‘Formacion’ Category

200 mil razones…

Posted by Roberto Espinosa en 7 abril 2011


Hoy es un día feliz para mi, por muchos motivos. Uno de ellos es poder compartir con vosotros que, lo que empezo como un experimiento, como una experiencia de autoformación (con el famoso Learn by doing), como una recopilación de ejemplos prácticos, pruebas, revisión de aspectos teóricos en el mundo del Business Intelligence, se ha hecho mayor y ha alcanzado la cifra de 200 mil visitas.

Toda una alegria para mi el que, lo que empezo como un juego, haya sido visitado por tanta gente y haya sido útil a muchos de vosotros en el inicio al BI o en el descubrimiento y profundización de algunos de los productos que hemos destripado mas o menos a fondo. A pesar de que ultimamente no le he podido dedicar demasiado tiempo por motivos profesionales y personales, que me tienen mas que absorbido, sigo recibiendo consultas, preguntas, a las que intento contestar o dar un punto de vista de ayuda. Y también sigo recibiendo correos de muchisima gente que me agradece toda la información que he compartido y lo útil que les ha resultado para muchos de los retos que se les han planteado en sus proyectos tanto de estudio o de trabajo en casos de empresa real.

Por si teneis curiosidad, aquí os dejo la tabla con algunas de las entradas más populares, donde destaca sin duda la comparativa entre las herramientas ETL Open Source Talend Open Studio y Pentaho Data Ingration (Kettle), que ha superado las 10 mil visitas (en su versión en Ingles y Castellano):

Título Visitas
Home page More stats 73.821
ETL´s: Talend Open Studio vs Pentaho Data Integration (Kettle). Comparative. More stats 7.415
16.3. Construccion procesos ETL utilizando Kettle (Pentaho Data Integration). More stats 5.855
I. DESCUBRIENDO EL BI (Microstrategy) More stats 3.884
Aplicaciones para gestión de Incidencias y Bugs. Productos OpenSource. More stats 3.366
16.4. Comparativa ETL Talend vs Pentaho Data Integration (Kettle). More stats 3.115
11. Herramientas ETL. ¿Que son, para que valen?. Productos mas conocidos. ETL´s Open Source. More stats 3.037
17.1. Instalación y configuración de la plataforma BI de Pentaho. More stats 2.878
II. BI OPENSOURCE CON PENTAHO. More stats 2.838
14.2. Diseño de hechos, atributos y jerarquia de dimensiones en Microstrategy 9. More stats 2.737
12. Proceso ETL para la carga de la Dimensión Tiempo. Ejemplo de uso de la ETL Talend. More stats 2.720
2.2. Cubos OLAP (On-Line Analytic Processing). More stats 2.700
15.2.Kimball vs Inmon. Ampliación de conceptos del Modelado Dimensional. More stats 2.571
17.4. Reporting en Pentaho con Pentaho Report Designer. Otras posibilidades de reporting (Birt y JasperReports). More stats 2.478
17.3. Preparando el analisis dimensional. Definición de cubos utilizando Schema Workbench. More stats 2.478
5. Fases en la implantación de un sistema DW. Metodologia para la construcción de un DW. More stats 2.391
14.1. Instalación y configuración del servidor Microstrategy 9. More stats 2.336
Bases de Datos OpenSource. ¿Porque elegimos Mysql para nuestro proyecto?. More stats 2.128
Ejemplo Talend para conectarnos a Sap More stats 2.017
8. El modelo Lógico de nuestro DW. Revisión. Construcción de un prototipo para validación. More stats 1.846
16.3.1. ETL Dimensión Tiempo con PDI. More stats 1.828
14.6.2. Reporting en Microstrategy 9 (II). More stats 1.805
15. Business Intelligence Open Source. Proyecto EnoBI usando Pentaho. More stats 1.689
13.4.1. Tabla Hechos Venta. Particionado en MySql. More stats 1.674
15.4.1. Particionado de tablas en Oracle. More stats 1.631
17.5. Cubos Olap y navegación dimensional con Mondrian y Jpivot. More stats 1.590
3. La base de datos analítica (el Datawarehouse o Almacén de Datos) More stats 1.585
17.6. Cuadros de Mando en Pentaho con Community Dashboard Framework (CDF). More stats 1.575
1. ¿Que es Business Intelligence? More stats 1.479
2.3. EIS (Executive information system). Cuadros de Mando Integral. DSS (Decission Support System). More stats 1.477
14. Implementación del sistema BI utilizando Microstrategy. More stats 1.476
2.4. DataMining o Mineria de Datos. More stats 1.474
14.6.1. Reporting en Microstrategy 9 (I). More stats 1.421
16. Procesos ETL. Escenarios para el diseño de los procesos. More stats 1.408
13.3. ETL Talend Dimension Cliente.Tipos de Mapeo para lookup. Gestión de SCD (Dimensiones lentamente cambiantes). More stats 1.402
14.7. Navegación Dimensional y cubos OLAP en Microstrategy 9. More stats 1.399
15.4. Modelo Fisico. Modelo normalizado y desnormalizado (Dimensional). More stats 1.314
7. Definición de objetivos. Analisis de requerimientos. More stats 1.272
Teoria de cuadros de mando. Tarjetas de puntuación y Dashboard. More stats 1.243
13.2. ETL para carga Dimension Producto. Mas ejemplos de Talend. Uso de logs, metricas y estadisticas. More stats 1.200
14.11. Ejemplo de BI con Datos Públicos. More stats 1.195
17.2. Preparando el reporting. Definición de metadatos con Metadata Editor. More stats 1.152
14.8.2. Dashboard y Cuadros de Mando en Microstrategy 9. Utilizando documentos de Report Services (II). More stats 1.130
15.3. Analisis de Dimensiones y Hechos. Modelo Lógico Final. More stats 1.125
14.3. Diseño de Indicadores, Filtros y Selecciones Dinámicas en Microstrategy 9. More stats 1.083
15.1. Definición de Objetivos. Análisis de Requerimientos. More stats 1.056
Sobre mi More stats 1.050
14.8.1. Dashboard y Cuadros de Mando en Microstrategy 9. Utilizando documentos de Report Services (I). More stats 1.040
14.12. Conclusiones. Evaluación final de Microstrategy 9. More stats 1.001
Tratamiento de Dimensiones Lentamente Cambiantes (SCD) con PDI. More stats 995
16.1. Identificación origenes de datos. Utilizando Data Profiling. More stats 951

Muchos de estos contenidos están también publicados en el portal de conocimiento Dataprix.com. En esta web podeís acceder a parte de los contenidos en formato Manual (ebook), pudiendo descargar todo el material o imprimirlo de forma completa y conjunta.

Otro motivo de alegria es presentaros al hermano pequeño del Rincon del BI, que se llama Saptricks y en el que llevo trabajando un par de meses. En este nuevo blog, en el que trabajare con mas asiduidad a partir de ahora, ire compartiendo mi experiencia con el ERP Sap, como un cuaderno de bitacora y anotaciones para el trabajo en el día a día, con ejemplos prácticos y enlaces, tanto a nivel técnico (administración y programación), como a nivel funcional (en los principales módulos de la aplicación). Es mas un blog personal, de trabajo diario, notas y documentación, pero que también voy a compartir con todos aquellos de vosotros que os peleais en el día a día con Sap, con todas las dudas y necesidades que surgen tanto en los proyectos de implantación o mantenimiento del sistema. Intentando también de alguna manera suplir la falta de documentación y tutoriales escritos en castellano.

Esta herramienta ha sido mi ocupación durante los últimos 11 años, primero más nivel técnico y de programación, y despues a nivel funcional en esta etapa en la que estoy embarcado en la actualidad (en la que también estoy preparando mi certificación tras realizar un interesante curso de Sap MM Logistica con la gente de AprendeSap.com, que sin duda ha valido la pena).

Espero seguir compartiendo experiencias y conocimiento con todos vosotros. Y que todo os sea tan útil y práctico como me resulta a mi.

¡¡¡¡Saludos!!!!

Posted in Business Intelligence, Formacion, Sap | 9 Comments »

16.2. Definición Area Stage. Tecnicas ETL.

Posted by Roberto Espinosa en 7 mayo 2010


Area de Stage.

Como ya indicamos anteriormente, vamos a disponer de un area de Stage para la orquestación de los procesos de carga de nuestro DW. Esta area es un espacio orientado a almacenar la información proveniente de nuestro sistema operacional o de otras fuentes, con una vida temporal o no, que será el punto de partida de los procesos de depuración, transformación y carga en el DW. El enfoque va a ser el siguiente:

  • Carga de datos de dimensiones: tendremos unas tablas persistentes en el area de stage. Cuando realizamos la carga de las dimensiones, se extrae la información de los origenes de datos y se deposita sin realizar niguna transformación en las tablas de stage. A partir de ahí se lanzaran los procesos que llenaran el DW, pero ya trabajando siempre en local. De esta forma, siempre nos vamos a guardar un histórico o foto de los datos tal y como nos los trajimos. Incluso se podrían preparar procesos de carga que reprocesasen una de las fotos de las dimensiones (o volver a lanzar el proceso de carga sin volver a acceder al sistema operacional, en el caso de que se haya producido cualquier problema). Cada lote de registros de las dimensiones traidos tendrá una clave única, además de la fecha y hora de extracción. Esta información nos puede ser util para los procesos de debug que tengamos que realizar en el caso de comportamientos inesperados o erroneos.

Esquema Area Stage

  • Carga de datos de hechos: el origen de los hechos de venta está en los pedidos de nuestro sistema operacional. Para agilizar el proceso, vamos a replicar la información de las tablas implicadas en el area de Stage. Pero borraremos en cada procesamiento todo el contenido referente a pedidos, pues no es una información de la que nos interese tener ningún registro. Por tanto, en este caso estaremos trabajando con un area de stage temporal.

El area de Stage la vamos a tener en una base de datos paralela, utilizando Mysql. Este enfoque es solo un ejemplo de como podemos orquestar los procesos y que alternativas podemos plantear para cada casuistica. Por ejemplo, puede ser que tengamos muy poca ventana de tiempo para extraer los datos y nos interese realizar una extracción masiva sin procesamiento para luego continuar con el resto de procesos desvinculados del sistema origen. También puede ser que la extracción de datos se haga a través de ficheros Dump, que transportaremos hasta el sistema ETL y preferamos cargarlos en un lugar temporal antes de procesarlos. Como veis, habrá muchas cosas a tener en cuenta antes de decidir los pasos a seguir y como montar el sistema (ventana de tiempo, volumenes de información, tipo de extracción del sistema origen, etc).

Algunas técnicas ETL.

El termino ETL es solo una categorización muy amplia de las actividades de integración de datos. Para cada uno de los procesos principales, podemos identificar varias actividades (cada una con sus correspondientes técnicas).

Para la extracción de datos, podemos indicar:

  • Captura de cambios en los datos: comprende las tareas de identificar los cambios en los datos de los sistemas origen. En muchos casos, la extracción de datos se limita a la porción de datos que ha cambio desde la última extracción, aunque en otras ocasiones incluira la extracción de toda la información de un periodo(los pedidos de una semana o el inventario a una fecha). El proceso de identificar los datos que han cambiado se suele llamar CDC (Change Date Capture). Las tecnicas a utilizar pueden ser analizar los registros de cambios de los datos (como en Sap, que tiene implementado en muchos sitios un historial de modificaciones de los datos), o trabajando con claves secuenciales.
  • Data Staging: no siempre es efectivo o posible procesar inmediatamente los datos extraidos. A menudo, es aconsejable almacenarlos temporalmente antes de las transformaciones (como vamos a hacer nosotros en nuestro ejemplo con la creación del area de stage). Podemos pensar en el caso de que un sistema operacional en el que no esta permitido por temas de rendimientos y disponibilidad el lanzamiento de procesos contra la base de datos. En ese caso, extraeremos los datos de la forma mas eficaz y rapida posible sin procesamiento y la cargaremos en el area de stage, que nos servira como un buffer intermedio entre el sistema operacional y nuestro DW.

Para la transformación, podriamos enumerar:

  • Validación de datos: verificación de la corrección de los datos y filtrado de los datos erroneos. Aunque estemos trabajando con aplicaciones que validan los datos y los ficheros maestros, no podemos asegurar que la información sea correcta. Por tanto sera necesario realizar este proceso (utilizando el data profiling que vimos anteriormente, por ejemplo). Esto seguramente permita arreglar errores y partir de unos datos limpios.
  • Limpieza de datos: correción de los datos incorrectos o incompletos. Los datos incorrectos podrían ser rechazados, aunque puede resultar mas útil etiquetarlos de una forma determinada para luego sean mas faciles de identificar y de corregir.
  • Decodificación y renombrado: conversión de la información de los códigos de los sistemas operacionales a otros mas descriptivos, fáciles de usar o recordar. Podemos incluir aquí la normalización de la información que puede tener diferentes construcciones según el sistema origen.
  • Agregación: en ocasiones, la agregación de la información  para estar disponible en los sistemas de análisis se elabora como parte de los procesos de transformación.
  • Generación claves y gestión: los registros nuevos o modificados en las dimensiones requieren una gestión de claves, que han de ser generadas y gestionadas. Ademas esas nuevas claves que identifican los registros tendrán que ser tenidas en cuenta en las tablas de hechos.

Pueden existir otros muchisimas tareas asociadas a la transformación de datos, siendo las vistas las mas habituales.

En el proceso de carga, hay dos actividades principales:

  • Carga y mantenimiento de dimensiones: las dimensiones no suelen ser estaticas (excepto la dimensión tiempo), y por tanto hay que gestionar todos los procesos de actualización y mantenimiento de los datos dentro los procesos de integración.
  • Carga de tablas de hechos: es uno de los procesos mas importantes dentro de los procesos de construccion de un DW.

Tratamiento SCD.

En la imagen podemos observar un algoritmo que puede sernos muy util para procesar las dimensiones donde hemos implementado el tratamiento de las SCD y estemos utilizando claves subrogadas. El planteamiento es muy sencillo. Realizamos la extracción de datos del sistema origen y vamos procesando cada uno de los registros que formaran la dimensión (una vez han sido depurados, transformados y normalizados), justo antes de realizar la carga. Podemos tener varios casos:

Algoritmo para el tratamiento de las SCD

  • Nuevo registro: se le asociara una nueva clave subrogada a este, y se llenaran los campos de control de fechas de validez y el indicador de registro activo (también el numerador de versión, que empezara por 1).
  • Registro no modificado: en el caso de que el registro no tenga ninguna modificación, lo ignoraremos y pasaremos al siguiente registro.
  • Registro modificado:cuando el registro tiene alguna modificación en alguno de los campos, se pueden dar dos casos, al menos:
    • Campo modificado del tipo SCD 1 o 3: actualizamos el atributo de la dimensión. En este caso, no se va a generar un nuevo registro ni una nueva clave subrogada.
    • Campo modificado del tipo SCD 2: el cambio es en alguno de los campos que consideramos relevante. En este caso, se genera una nueva clave subrogada para el registro, y se llenan los correspondientes campos de fecha, versión y registro activo. Además, se ha de procesar el registro valido anterior, cerrando la fecha fin de validez al dia anterior a la validez inicial del nuevo registro, y desmarcando el flag de registro activo (pues deja de ser el registro actual).

Veremos que Kettle incorpora una parte del algoritmo (con el step Dimension lookup/update), al igual que lo hacia Talend con su componente tMySqlSCD de una forma completa (tal y como vimos en una entrada anterior).

Carga tabla hechos. Tener en cuenta claves subrogadas.

Cuando realizemos la carga de la tabla de hechos (normalmente despues de haber realizado el procesamiento y carga de las dimensiones de las que depende), habrá que tener en cuenta que hemos “dado el cambiazo” a los códigos originales del sistema operacional por los códigos inventados de las claves subrogadas. Por tanto, esto habrá que tenerlo en cuenta antes de realizar la inserción. En la imagen vemos una alternativa posible a la forma de procesar este aspecto:

Conversion a claves subrogadas en la tabla de Hechos

El paso consiste en, previamente a la inserción en la base de datos, vamos recorriendo las diferentes claves naturales y buscamos su clave alternativa (subrrogada) en la dimensión, realizando su sustitución. Para hacer la conversión nos valdremos de los periodos de validez que hemos incluido en el tratamiento de la dimensión lentamente cambiante, o en el caso de no tener un periodo de validez, nos puede vale el registro activo en el momento del proceso (este aspecto habrá que analizarlo bien antes de tomar una decisión).

Algunas recomendaciones previas al diseño de los procesos ETL. Metadatos y Nomenclatura.

Al igual que al definir nuestro modelo de datos o al realizar la identificación de los origenes de datos, es recomendable disponer dentro del sistema ETL un Metadatos y una nomenclatura bien definida que permitar una mejor gestión y comprensión de todo el sistema.

Por un lado, podemos documentar los diferentes procesos que tenemos de una forma general, incluyendo su proposito y los elementos que intervienen en cada job.

Documentación Jobs

Ademas, al construir los procesos, sería conveniente utilizar una nomenclatura unificada tanto para sus nombres como para los nombres de los componentes que los formaran, lo que puede permitir una mejor comprensión y mantenimiento posterior de los trabajos. Luego habrá que detallar cada proceso en particular e incluir en esa documentación todos los elementos que intervenienen en el proceso, todas las tareas que se realizan, incluyendo también información de los momentos de ejecución de cada proceso, las dependencias con otros procesos, las acciones a realizar en el caso de errores o parada, etc.

Os recomiendo sin duda para preparar todos estos aspectos  la lectura de libro The Data Warehouse ETL Toolkit de Ralph Kimball y Joe Caserta. En el se abordan muchisimos temas que podriamos tener en cuenta en la construcción de nuestros procesos ETL en los que no hemos entrado, como pueden ser:

  • Técnicas de optimización a la hora de realizar las cargas: realizando ajustes en los  indices (incluso desactivandolos antes de las cargas), separando actualizaciones e inserciones, utilizando bulk loader (o cargadores masivos), desactivación del log de cambios de la base de datos (pues es superfluo en un sistema DW), desactivación de la verificación de claves foraneas durante las cargas, calculo de agregaciones fuera de la base de datos, etc.
  • Particionado de tablas para mejorar el rendimiento del sistema.
  • Lanzamiento de procesos batch, procesamiento en paralelo.
  • Realizar cargas incrementales de los datos en lugar de cargas completas (será posible o no según el tipo de dimensión y el tipo de tabla de hechos).
  • Borrado o ocultación de datos históricos que ya no se utilizan.
  • Tratamiento de actualizaciones tardias en las tablas de hechos.
  • Gestión de tablas de hechos agregadas, usando, por ejemplo, vistas materializadas.
  • Uso de herramientas y utilidades de script para realizar parte de los procesos.
  • Uso de centinelas para gestionar la correcta realización o no de procesos.
  • Tecnicas de programación de tareas. Frecuencia de procesos de carga.
  • Trabajar con un sistema de desarrollo y uno productivo al menos (aunque seria ideal disponer también de un sistema de Test intermedio).
  • Trabajar con versiones de los procesos, de forma independiente para gestionar mejor los cambios.
  • Documentación de procesos, etc., etc.

Posted in ETL, Formacion | Leave a Comment »

16.1. Identificación origenes de datos. Utilizando Data Profiling.

Posted by Roberto Espinosa en 3 mayo 2010


Es fundamental antes de abordar la construcción del sistema ETL, la correcta identificación de los origenes de datos que  permitirán el llenado de nuestro DW. Para ello, sería conveniente la realización del llamado Mapa de Datos Lógico. Este mapa lógico será la guia que utilizaremos durante todo el desarrollo de los procesos ETL, pues los criterios y premisas que establezcamos en el deberán ser seguidas y cumplidas por todas las tareas a realizar hasta la finalización de todos los procesos de llenado. En una entrada anterior del blog realizamos una aproximación a este mapeo lógico, que vamos a ampliar un poco.

Ejemplo sencillo de mapeo Sistema Origen - Sistema Destino

Básicamente, el mapa lógico debería de incluir al menos los siguientes componentes (siempre queda en la creatividad de cada uno añadir otros aspectos de interes o cosas a tener en cuenta de cara a la construcción de procesos):

  • Origen de datos: identificar la tabla, columna, el tipo de datos, el tipo de objeto dentro de nuestro modelo dimensional (dimensión, tabla de hechos, etc) y que tipo de gestión de Dimensiones Lentamente Cambiantes (SCD) vamos a realizar en el caso de que haya cambio en los valores del campo. Estableceremos los origenes de datos candidatos que habrá que validar antes de considerarlos definitivos (por si no tuviesen la calidad necesaria) o por si no cumpliesen los requisitos deseados.
  • Destino: aquí indicaremos cual va a ser el destino de los datos. Detallaremos exactamente la/s tabla/s y campos que forman las tablas de dimensiones y hechos y su tipo de datos. Sera el lugar de destino de los datos extraidos de los sistemas origen.
  • Transformación a realizar: finalmente, determinaremos la transformación necesaria a aplicar en los datos origen para realizar el llenado de los datos destino. Es necesario en esta sección considerar cualquier operación que haya que realizar sobre los datos ( codificación/decodificación, suma, tratamiento de cadenas, mapeo contra otras tablas, corrección de valores incorrectos, transformación a valores normalizados, etc). Para esto, habrá que realizar una verificación profunda de los valores de los datos en el sistema origen, e intentar no dejar sin considerar ninguna excepción o caso especial que se pueda presentar en los valores de los datos.

Teniendo en cuenta todos estos aspectos, un buen Mapa de Datos Lógico podría ser el siguiente:

Ejemplo de mapa lógico de procesos ETL

Como ayuda para la realización del mapa lógico, hemos de basarnos en herramientas y técnicas que nos permitan descubrir, por un lado, las características del diccionario de datos, y por otro lado, las características de los propios valores de los datos para descubrir casuisticas especiales, problemas de calidad en los datos que habrá que corregir, procesamientos a realizar,  etc.

Origenes de datos más habituales.

Podemos disponer de multitud de origenes de datos para llenar nuestro Dw. Algunos de los más habituales pueden ser los siguientes:

  • Sistemas ERP: la mayoria de empresas trabaja hoy con sistemas ERP (Enterprice Resource Planning), desde los más sencillos a los grandes como son Sap, Oracle Financials, JDEdwards o Navision. Estos sistemas suelen dar soporte a todas las actividades de negocio de una empresa, desde las ventas, compras, fabricación, finanzas, mantenimiento o recursos humanos. Esto hace que sean sistemas complejos a los que puede ser complicado atacar sin conocer en profundidad su modelo de datos (pensar que Sap  pueden tener hasta 70 mil tablas). En muchas ocasiones, por temas de licencias, no se puede atacar directamente la base de datos y hay que utilizar una API para poder acceder a estos sitemas. Por ejemplo, para Sap tenemos un conector libre en Talend (y uno de pago en Kettle), pero para otros fabricantes habrá que utilizar otro tipo de herramientas. En estos sistemas también puede ser útil la utilización de las herramientas propias para intercambio de datos de las que dispone el propio sistema y que posiblemente ya estarán siendo utilizadas en la organización para otros cometidos.
  • Mainframes: en grandes empresas como bancos y compañias de seguros aun se siguen utilizando este tipo de sistemas.
  • Hojas de cálculo: no debería de ser habitual o fomentarse el uso de hojas de cálculo en las empresas. Pero vamos a ser realistas. Las hojas de cálculo se utilizan frecuentemente en todas las organizaciones, incluso formando completos subsistemas (o complementarios) en los departamentos de finanzas, ventas, etc. También en ocasiones en ellas se almacena información complementaria que no esta en los sistemas operacionales.
  • Bases de datos de escritorio (tipo Access, OpenOffice Base, etc): con el mismo planteamiento que las hojas de cálculo.
  • Datos estructurados externos: en muchas ocasiones vamos a tener organizaciones externas que nos proporcionan datos en formatos estructurados. Por ejemplo, podriamos tener información de estudios de mercado, de códigos postales, de encuestas, de resultados electorales, etc.
  • Datos en formato XML: el lenguaje XML (Extensible Markup Language) se ha convertido en un estandar de hecho para la comunicación entre sistemas. La gran ventaja es que un fichero XML es un fichero de texto donde se almacen la información de una forma estructurada.
  • Datos Online: muchisima información puede ser obtenida en la actualidad de internet y sus web, en forma de servicios web o Rss.

La mayoría de herramientas ETL disponen de complementos, conectores o utilidades para trabajar con todos estos  origenes de datos.

Por otro lado, en la mayoría de organizaciones, se da una combinación de todos estos orígenes de datos. Aunque casi siempre  partiremos de un ERP o aplicación de gestión integrada que almacenará la información en una base de datos relacional (de una forma estructurada), no toda la información podrá ser obtenida de este sistema  integrado. Ademas tendremos otros origenes de datos donde habra información de presupuestos, tesorería, estimaciones, mucha veces mantenidos en hojas de cálculo. El reto sera descifrar el contenido de estos datos, su estructura, calidad, significado de los datos y ser capaces de utilizarlos.

Utilizar herramientas de modelado de datos para ingenieria inversa. Analisis del diccionario de datos.

No siempre va a ser sencillo descubrir las tablas y campos en los sistemas origen donde se alojan los datos que son de nuestro interes. Si estamos trabajando con un ERP, seguramento dispongamos de un diccionario de datos donde poder analizar las características de las tablas donde estan los datos que nos interesan. Por ejemplo, en Sap tenemos una transacción, la SE13, donde podemos ver las características de cada tabla de la base de datos, incluyendo información adicional de los campos e incluso lógica de la aplicación (dominios de datos, posibles valores de campos, etc).

Diccionario de datos en el ERP Sap

Pero no siempre vamos a tener la suerte de trabajar con Sap y de tenerlo tan facil para descubrir el diccionario de datos. En otros casos, nos tocará “rascar” directamente en la base de datos o en estructuras de ficheros. Para descubrir la estructura de las tablas y campos de la base de datos tendremos multitud de opciones:

  • Gestores de base de datos: en el caso de estar utilizando un motor de base de datos especifico, siempre vamos a tener la opción de utilizar el lenguaje Sql (con las características propias en lo referente al diccionario de datos de cada gestor RDBMS)  o las propias herramientas de administración donde poder analizar la estructura de datos de una tabla en concreto.
  • Herramientas de modelado de datos: las herramientas de modelado de datos suelen tener utilidades de conectividad a diferentes bases de datos, que nos permiten hacer ingenieria inversa y, a partir de las tablas físicas de la base de datos, construir un modelo dentro de la herramienta, que podremos analizar con tranquilidad. Por ejemplo, Mysql Workbench nos permite hacer ingenieria inversa sobre una base de datos Mysql y recuperar en el modelo el diccionario de datos de las tablas que deseemos. Tiene la limitación de que solo se puede trabajar con Mysql. Si trabajamos con Oracle, puede ser interesante trabajar con Oracle Sql Developer, que nos permite analizar características del diccionario de datos (y conectarnos a otras bases de datos que no son Oracle a través de Jdbc). La herramienta Data Modeler de Oracle también incluye características de ingenieria inversa, al igual que herramientas mas avanzadas de modelado como Sybase Power Designer.

Ingenieria inversa con MySQL Workbench

  • Herramientas ETL que incluyen metadata: la mayoria de herramientas ETL incluyen características para conectarnos y navegar por el diccionario de datos de las BD mas conocidas. Por ejemplo, podemos usar Kettle para este cometido, o de una forma mas avanzada el gestor de esquemas de Talend (tal y como vemos en la imagen). Con el uso de los componentes de que disponen esta herramientas para atacar diferentes fabricantes de bases de datos via Jdbc podemos facilmente “bucear” por los esquemas de datos.

Recuperacion esquema de BD con Talend

  • Herramientas de Data Profiling: tambien suelen incluir características de metadatos para recuperar la información del diccionario de datos de una BD, y previsualizar el contenido de las tablas de una forma rápida.

En el caso de estar trabajando con ficheros, no nos quedará mas remedio que tirar de documentación (en el caso de que este debidamente realizada o exista) o utilizar herramientas para analizar el contenido y la estructura de los datos (os recomiendo la utilidad notepad++ (para el caso de ficheros de texto). También podemos utilizar herramientas ETL para analizar los ficheros, como Talend o Kettle, cuyos asistentes o visores nos pueden ser de gran utilidad, así como los asistentes de importación de datos de herramientas como Access o similares.

Utilizar el Data Profiling para revisar la calidad de los datos y para identificar transformaciones sobre los datos.

El Data Profiling es el proceso de recopilación de estadísticas y otra información sobre los datos existentes en nuestros origenes de información. Esta información va a ser de gran utilidad para el diseño de los procesos ETL. El Data Profiling también puede ser parte importante de cualquier iniciativa de calidad de datos, ya que antes de que la calidad de estos se pueda mejorar, habrá que establecer cual es el estado actual de los datos, y para ellos podemos valernos de estas técnicas.

El Profiling puede ser desarrollado a 3 niveles:

  • Column profile: recopilación de estadísticas sobre los datos existentes en una columna individual.
  • Dependency profile: analisis entre las dependencias de las diferentes columnas de una tabla.
  • Join profile: chequeos de dependencias entre diferentes tablas.

El punto de partida  para el Profiling siempre es el Column Profile, que nos puede proporcionar información tan interesante como:

  • Numero de valores distintos: cuantas entradas unicas contiene una determinada columna (en un análisis de clientes, que un valor exista varias veces puede, por ejemplo, reflejar registros duplicados).
  • Numero de valores nulos (Null) o vacios en la columna: nos puede ayudar a identifcar registros cuyos datos estan incompletos.
  • Valores mínimos y máximos en el campo, no solo a nivel númerico, sino también a nivel de texto.
  • El uso de funciones estadísticas como suma, mediana, media o desviación estandar puede ser util también para sacar conclusiones sobre los datos.
  • Longitud de los campos y patrones de cadenas: en muchas ocasiones los campos tendran que tener un formato determinado que obligara a una determinada longitud o al uso de unos determinados patrones (como por ejemplo el código postal, que en España ha de contener 5 dígitos). El control de la longitud de los valores de la columna o la busqueda de valores que no cumplan los patrones nos puede ayudar a encontrar valores incorrectos. Con los patrones de cadenas y expresiones regulares podemos buscar determinadas ocurrencias de valores que determinen datos incorrectos igualmente.
  • Numero de palabras,numero de caracteres en mayusculas y minúsculas.
  • Contadores de frecuencia de ocurrencia de valores.

Una vez estamos realizando estos análisis sobre los campos, las herramientas ofrecen funcionalidades de navegación por los datos para ver los valores exactos asociados a cada tipo de análisis o a cada tipo de valor.

Ademas de los análisis por columna, las herramientas Data Profiling nos pueden permitir descubrir dependencias entre diferentes campos de una misma tabla, como por ejemplo el análisis de los datos geográficos de un cliente y las relaciones entre los diferentes campos (codigo postal, población, provincia, región, etc).

El análisis de las relaciones entre tablas (Join profile) es más fácil de realizar, pues la verificación de dependencia entre valores de diferentes tablas puede ser sencilla de establecer (por ejemplo, buscar clientes en una tabla de pedidos que no existen en el maestro de clientes o materiales que no existen en el fichero maestro de productos).

Como Pentaho no dispone de una herramienta de Data Profiling, podriamos utilizar otras herramientas Open Source como DataCleaner y Talend Open Profiler para este cometido. Vamos a vemos un ejemplo utilizando esta última herramienta.

Data Profiling con Talend Open Profiler.

Vamos a realizar un analisis del tipo Column Profile sobre una columna de la tabla de clientes, en concreto sobre el campo código postal. Queremos validar que todos los códigos postales son correctos y que cumplen el patron de construcción de los valores. Para la prueba, hemos replicado un maestro de clientes de Sap en una base de datos externa con Oracle. Los pasos para realizar el análisis con Talend Open Profiler serán los siguientes:

  • Definición de la conexión a la base de datos: al igual que en la herramienta ETL, Open Profiler tiene características de metadatos muy avanzadas. En primer lugar, definiremos la conexión a nuestra base de datos Oracle. En la conexión podemos navegar por las tablas y sus campos, filtrar las tablas visualizadas, etc.

Metadata en Talend Open Profiler

  • Selección del tipo de análisis: a continuación, vamos a seleccionar el tipo de análisis que queremos realizar. Talend tiene un amplio repertorio de posibilidades de análisis, desde un análisis global sobre una base de datos o un catalogo/esquema (donde podremos ir profundizando en los diferentes elementos que los forman), análisis de columnas (de sus valores utilizando diferentes indicadores o patrones), hasta analísis de dependencia con otros campos, análisis de redundancia o correlación. En nuestro ejemplo, nos vamos a centrar en el análisis de una columna determinada, el código postal, para el que queremos validar su corrección y descubrir errores en los datos que tendremos en cuenta para construir los procesos ETL.

Selección del análisis a realizar

  • Configuración del análisis de la columna: a continuación indicamos el tipo de indicadores que queremos analizar para la columna. Hay un montón de indicadores disponibles, que pueden variar según el tipo de columna que estemos tratando. Por ejemplo, podemos contar los registros, los valores nulos, el numero de valores distintos, los valores en blanco, valores mínimos y máximos de longitud del campo, valores estadísticos, etc.

Analisis de columna - selección de indicadores de análisis

  • Selección de patrones de análisis: además de los indicadores, podemos seleccionar patrones de análisis para verificar, por ejemplo, que los valores de los campos cumplen unas determinadas reglas. En nuestro caso, vamos a verificar que los códigos postales de España tienen una longitud de 5. Para este cometido, Talend tiene un lote de patrones predefinidos (tanto Sql como a través de expresiones regulares), ademas de dejarnos la posibilidad de crear nuestro propios patrones.  En nuestro caso, vamos a definir un nuevo patrón para los códigos postales de España, con la siguiente expresión regular  ( ‘^(0[1-9]|[1-4][0-9]|5[0-2])[0-9]{3}$’ ), y el patrón lo vamos a añadir al análisis. Con esta funcionalidad podemos añadir todos los chequeos y validaciones que se nos puedan ocurrir. Para el tema de indicadores, también nos dejan la puerta abierta para incluir código en Java para añadir los propios. En este momento también podemos añadir filtros condiciones para limitar el ambito de análisis a unos valores determinados (por ejemplo, solo los clientes de un pais o de un canal de distribución).

Una vez están definidos todos los elementos a tener en cuenta en el análisis, procederemos a su ejecución. La herramienta se conecta a la base de datos para recopilar la información según los indicadores seleccionados y para realizar las validaciones según los  patrones que hayamos indicado. Los resultados se muestran en un visor gráfico tal y como vemos en la imagen siguiente:

Análisis gráfico de los resultados

Se nos muestra información numérica y gráfica de los diferentes análisis seleccionados. Tendremos una lista de frecuencia de valores, el menor y mayor valor descubierto, etc. Igualmente, se nos muestran los porcentajes de valores que cumplen el patrón de los códigos postales y cuales no. Desde el visor de resultados, podemos acceder con el menú contextual del botón derecho del ratón a visualizar los registros asociados a cada uno de los casos. Por ejemplo, para los registros que no cumplen el patrón, al seleccionar la opción de ver registros, nos aparecerá el visor de registros. Ahí también vemos la sentencia SQL que nos determina los valores devueltos con dicha condición:

VIsor de registros en el análisis de resultados

A partir de la visualización de los valores erroneos o incompletos, podremos establecer medidas de calidad a establecer en los sistemas origen, corregir los registros originales  o definir las transformaciones a realizar en los datos en el caso de que se cumplan determinadas condiciones. Pensar en lo utiles que pueden llegar a ser análisis de este tipo cuando estemos trabajando con grandes volumenes de información, en los que analizar los datos de forma manual puede ser una tarea artesanal muy compleja de realizar y en la que se nos pueden estar escapando muchas cosas. Este ejemplo es solo una introducción para ver las posibilidades de este tipo de análisis y lo que nos pueden ayudar en la a veces compleja de determinar las transformaciones a realizar sobre los datos para llenar nuestro DW con datos de calidad.

Este mismo tipo de analisis lo podemos utilizar para analizar validación de claves, dependencias e interelaciones de campos (por ejemplo, analisis de datos geográficos), desviación de valores determinados en un universo de valores, etc.

Bibliografía utilizada para elaborar esta entrada:

Pentaho  Solutions: Business Intelligence and Data Warehousing with Pentaho and  MySQL. Roland Bouman y Jos van Dongen.
The Data  Warehouse ETL Toolkit. Ralph Kimball y Joe Caserta.
Talend Open Profiler User Guide.
Ayuda Online de Java sobre expresiones regulares.

Posted in Data Profiling, ETL, Formacion | 1 Comment »

16. Procesos ETL. Escenarios para el diseño de los procesos.

Posted by Roberto Espinosa en 1 mayo 2010


En una entrada anterior del blog hicimos un repaso de las herramientas ETL, viendo cual era su cometido, las características que debería de tener una herramienta de ese tipo, enumerando igualmente los productos comerciales y open source mas conocidos.

Llega el momento de profundizar un poco mas antes de abordar la construcción de los procesos de carga de nuestro DW pero utilizando, esta vez, Pentaho Data Integration (Kettle). En la serie de ejemplos anteriores utilizamos Talend Open Studio con exito para la construcción de procesos y vimos que era una herramienta muy completa y potente, y con un gran futuro por delante por todos los recursos que se estan utilizando en su desarrollo.

Procesos ETL utilizando Talend

Introducción.

Los sistemas o procesos ETL (Extact-Transform-Load) son la base de la construcción de cualquier sistema Data Warehouse (aunque ademas puedan ser utilizados para otros muchisimos cometidos). Un sistema bien diseñado extrae la información de los sistemas origen, asegura la calidad y consistencia de los datos, homogeniza los datos de sistemas divergentes para que puedan ser utilizados de una forma conjunta (procesando y transformando la información si es necesario) y finalmente genera los datos en el formato apropiado para que puedan ser utilizados por las herramientas de análisis.

Como bien dice Ralph Kimball en su libro “The Datawarehouse ETL Toolkit“, los sistemas ETL construyen o “se cargan” un Data Warehouse. La construcción de un sistema este tipo es una actividad que no esta en primera linea de fuego y no es visible para los usuarios finales, pero facilmente consume el 70% de las necesidades de recursos para el desarrollo y mantenimiento de un sistema DW. Ademas, estos procesos no son solamente un mero traspaso de información de un sistema o otro. Son mucho mas, pues pueden dar un valor significativo a los datos. Unos procesos mal definidos, mal validados, pueden cargarse un sistema de BI impecablemente diseñado, pero mal alimentado por unos procesos mal construidos.

El proceso de construcción de un sistema ETL puede ser extraordinariamente exigente y complejo, estando ademas limitado por muchos aspectos, como pueden ser los requerimientos, los formatos y deficiencias de los datos de origen, las habilidades del personal disponible, las necesidades de los usuarios finales, el presupuesto del proyecto, las ventanas de tiempo para los procesos de actualización, etc. Teniendo en cuenta esto, no se debe nunca despreciar la importacia, el tiempo y recursos que se han de utilizar para su construcción.

Los requerimientos afectan a como va a ser nuestro sistema ETL.

Existen diferentes elementos que van a afectar en como va ser o como vamos a construir nuestro sistema ETL. Los mas importantes son los requerimientos. La elección de uno o varios procesos de negocio, las dimensiones e indicadores que vamos a analizar, su granuralidad, etc., van a determinar cosas tan dispares como los origenes de datos que vamos a tener que utilizar,la forma de procesar la información, la complejidad de los procesos, etc. Esto nos va a hacer darnos cuenta de lo importante que son dichos requerimientos y su correcta definicion en todas las tareas que realizemos a continuación, incluyendo la definición de la arquitectura de nuestros procesos ETL. Ademas el estudio de los sistema origen debe permitir añadir nuevas funcionalidades que pueden no haber sido tenidas en cuenta antes.

Otros elementos que van a influir en mayor o menor medida serán:

  • Data Profiling: cuando nos ponemos a analizar los datos de los sistemas origen nos encontraremos sorpresas, seguramente debido a que nunca se establecio ningún control o mecanismo para asegurar la calidad de dichos datos en los sistemas operacionales o en cualquier otro origen de datos. La información no tiene la calidad deseada y eso puede ser un incoveniente a la hora de construir el sistema de análisis. Para ello emplearemos técnicas de Data Profiling, que con metodos analiticos revisan los datos para obtener una comprensión completa de su contenido, estructura y calidad. Esto nos permitirá analizar grandes volumenes de información y descubrir todo tipo de cuestiones que deberan de abordarse (y tenerse en cuenta en el diseño del ETL). Imaginaros el caso de que la fuente de información no tenga la calidad esperada y ello puedo obligarnos a buscar otro origen de datos para cubrir los requerimientos. Si las técnicas de data profiling se hubieran aplicado en los sistemas origen, seguramente no se producira ningún tipo de problema. En caso contrario, deberemos seguramente eliminar el contenido de determinados campos, corregir valores corruptos, revisar errores manualmente para decidir como corregirlos, etc, etc, lo que puede complicar los procesos o obligarnos a incluir pasos para realizar el tratamiento de esos casos excepcionales.
  • Requerimientos de seguridad: aunque habitualmente los mecanismos de seguridad para acceder a los datos estan establecidos en las aplicaciones de análisis mediante roles de usuario, de forma que cada uno de ellos solo deberá de acceder al nivel de información para el que este autorizado. En los sistemas ETL, habrá que establecer también los mecanismos oportunos para evitar accesos no deseados o perdida de información, que en muchos casos puede ser muy delicada.
  • Data Integration: la información a lo largo de los sistemas es deseable que sea homogenea e integrada. Cuando hablamos de un ERP, esto suele ser habitual, pero no va a ser asi en todos los sistemas. A nivel de procesos ETL, esta integración de datos se referira a la hora de construir las dimensiones conformadas (los atributos comunes a lo largo de diferentes procesos de negocio), utilizando convenios de nombrado de campos, estructuras de datos o tipos, dominios de valores, etc. Lo mismo para el diseño de los indicadores, que deberán de ser construidos con criterios comunes.
  • Frecuencias de actualización: la frecuencia con la que la información del DW deberá de ser actualizada desde los sistemas operacionales también puede influir significativamente en los procesos de actualización y su estructura.
  • Habilidades disponibles en la organización: a la hora de construir y diseñar un sistema ETL hemos de tener en cuenta quien va a gestionar posteriormente el sistema. Sus habilidades, conocimientos habrán de ser tenidos en cuenta a la hora de seleccionar las herramientas, lenguajes de programación, etc. También podra influir el hecho de disponer ya de determinadas herramientas licenciadas para la construcción de procesos. Por ejemplo, si los procesos ETL se desarrollan en C++, sería conveniente disponer de un técnico que dominará ese lenguaje de cara a al posterior mantenimiento del sistema.
  • Presupuesto: el presupuesto economico para desarrollar un proyecto, los plazos, los precios del hardware, licencias, herramientas pueden influir también en las decisiones que se tomen, y por tanto, afectarán también a la forma de construir el sistema ETL.
  • Otros elementos a considerar: procesos batch vs procesos online, automatización de procesos, etc.

Arquitectura del sistema. Herramienta ETL vs Desarrollos a medida.

Una de las decisiones mas importantes que se va a tomar cuando se construyen los procesos ETL es la elección de una arquitectura. Ademas, es una decisión que hay que tomar en un momento inicial del proyecto y que puede condicionarlo en muchos aspectos. Basicamente, podemos plantear dos escenarios o arquitecturas diferentes (aunque en ocasiones podría darse el caso de que se complementasen):

  • Herramienta ETL: uso de herramientas diseñadas para la construcción de un sistema ETL. Estan especializadas en este ambito y suelen incluir alguna o todas de las siguientes características:
    • Conectividad / capacidades de Adaptación (con soporte a origenes y destinos de datos): habilidad para conectar con un amplio rango de tipos de estructura de datos, que incluyen bases de datos relacionales y no relacionales, variados formatos de ficheros, XML, aplicaciones ERP, CRM o SCM, formatos de mensajes estandar (EDI, SWIFT o HL7), colas de mensajes, emails, websites, repositorios de contenido o herramientas de ofimatica.
    • Capacidades de entrega de datos: habilidad para proporcionar datos a otras aplicaciones, procesos o bases de datos en varias formas, con capacidades para programación de procesos batch, en tiempo real o mediante lanzamiento de eventos.
    • Capacidades de transformación de datos: habilidad para la transformación de los datos, desde transformaciones básicas (conversión de tipos, manipulación de cadenas o calculos simples), transformaciones intermedias (agregaciones, sumarizaciones, lookups) hasta transformaciones complejas como analisis de texto en formato libre o texto enriquecido.
    • Capacidades de Metadatos y Modelado de Datos: recuperación de los modelos de datos desde los origenes de datos o aplicaciones, creación y mantenimiento de modelos de datos, mapeo de modelo fisico a lógico, repositorio de metados abierto (con posiblidad de interactuar con otras herramientas), sincronización de los cambios en los metadatos en los distintos componentes de la herramienta, documentación, etc.
    • Capacidades de diseño y entorno de desarrollo: representación grafica de los objetos del repositorio, modelos de datos y flujos de datos, soporte para test y debugging, capacidades para trabajo en equipo, gestion de workflows de los procesos de desarrollo, etc.
    • Capacidades de gestión de datos (calidad de datos, data profiling, etc.).
    • Adaptación a las diferentes plataformas hardware y sistemas operativos existentes: Mainframes (IBM Z/OS), AS/400, HP Tandem, Unix, Wintel, Linux, Servidores Virtualizados, etc.
    • Las operaciones y capacidades de administración: habilidades para gestion, monitorización y control de los procesos de integración de datos, como gestión de errores, recolección de estadisticias de ejecución, controles de seguridad, etc.
    • La arquitectura y la integración: grado de compactación, consistencia e interoperabilidad de los diferentes componentes que forman la herramienta de integración de datos (con un deseable minimo número de productos, un unico repositorio, un entorno de desarrollo común, interoperabilidad con otras herramientas o via API), etc.
    • Capacidades SOA.
  • Desarrollos a medida: los procesos ETL se desarrollan utilizando desarrollos a medida en un lenguaje de programación especifico. Algunas de las ventajas de utilizar los lenguajes de programación pueden ser:
    • Herramientas de Debug: que permiten verificar procesos y datos.
    • Reutilización de código ya existente. Diseño de código consistente a traves de las características de los lenguajes orientados a objetos.
    • Uso de recursos humanos internos especializados en el lenguaje.
    • Flexibilidad a la hora de construir los procesos y abordar cualquier tipo de tarea que ofrecen los lenguajes de programación.

La elección de un enfoque u otro va a determinar de una forma muy profunda el diseño del sistema ETL. Una herramienta ETL tiene muchisimas ventajas, tal y como hemos visto al enumerar sus características, y su continua evolución hace que cada día sea plantee menos la opción de los desarrollos a medida. Aunque esta opción tampoco se puede descartar nunca, pues en algunos casos puede ser necesario para realizar procesos muy complejos donde sacar partido a la flexibilidad de un lenguaje de programación especifico.

Implementación de Procesos ETL.

Como explica muy bien Kimball en su libro, los procesos ETL son similares a un restaurante y su cocina. En el comedor, los comensales degustan los platos como lo harian los analistas de negocio con los datos utilizando sus correspondientes herramientas de análisis. Puertas atras, en el interior, en la cocina, se preparan los platos, se analizan y limpian los ingredientes, desechando aquellos que no estan en condiciones, se trocean,  se cocinan, hasta elaborarlos tal y como serán presentados a los clientes.

El area de Staging según Kimball

De forma similar, el area de Stage sera lo mismo para nuestro DW. Es un lugar al que solo acceden las personas especializadas en la integración de datos, fuera del alcance de los usuarios. Allí los datos son extraidos, depurados, limpiados, conformados y normalizados, manipulados o calculados, y preparados para ser cargados en el DW donde podrán ser accedidos por los usuarios para realizar análisis con las diferentes herramientas de las que dispongan.

Los procesos en el area de Staging pueden incluir o no un almacenamiento de datos (aunque sea temporal), cuestión que dependera de como se diseñen los procesos, de los volumenes de información o de otras cuestiones. Básicamente, tenemos 4 tipos de pasos en esta area:

  • Extracción: los datos son extraidos de los sistemas origen, que pueden ser tanto bases de datos, como ficheros (estructurados o no) u otros origenes. Los procesos de extracción pueden ser a veces el lugar idóneo para realizar las primeras acciones sobre los datos, como formateo, conversiones de tipos, conversión de juegos de caracteres, etc.
  • Depuración: en esta etapa de los procesos ETL se procesa la calidad de los datos, revisando valores válidos, consistencia, eliminación de valores redundantes, chequeo de reglas complejas, etc. Puede ser necesaria la intervención humana en determinados casos.
  • Conformación/normalización: la información es unificada, conformada y normalizada. Los indicadores y ratios son calculados de una forma racional, lo mismo que los atributos de las dimensiones, para que esten unificados y en todos los sitios donde aparezcan tengan la misma estructura y el mismo significado.
  • Entrega: la información esta preparada para ser analizada. Se entrega al DW para que las herramientas de análisis puedan utilizarla, en los formatos idoneos para dicha tarea.

Creación o no de un Area de Datos en el Stage.

La decisión de almacenar los datos fisicamente en el area de Stage o no (y realizar su procesamiento en memoria) es una elección de diseño a la hora de construir los procesos ETL. Muchas veces puede ser la busqueda de un equilibrio entre el procesamiento en memoria o disco, o la busqueda de la forma más rapida de extraer la información de los sistemas origen para luego procesarla de una forma independiente, o la posibilidad de relanzar los procesos en el caso de que haya algún problema, lo que determine esta elección.

Teniendo en cuenta esto, pueden ser razones de peso para tener esta area de almacenamiento intermedio las siguientes:

  • Recuperabilidad: los datos son almacenados en el area stage una vez son extraidos del sistema origen. A partir de ahí, se lanzan los procesos de transformación. En el caso de que haya algún problema, estas tablas de staging nos permiten recuperar y relanzar los procesos sin volver a interferir en los sistemas operacionales (esto solo tendrá sentido cuando los volumenes de información sean lo suficientemente grandes).
  • Backup: nos pueden permitir disponer de backups de los datos en un punto determinado, lo que nos puede permitir relanzar procesos o recuperar situaciones en un punto anterior en el tiempo.
  • Auditoria: el area de stage nos puede permitir realizar auditoria o verificación de procesos, así como realizar comprobaciones en como estaban los datos antes y despues de los procesos (igualmente sin recurrir a los sistemas origen).

Ejemplo de sistema ETL con almacenamiento en el area de Stage

En nuestro caso, vamos a construir un area de stage que será un punto intermedio de almacenamiento de la información a procesar antes de su carga en el DW. El area de Stage puede ser procesada de muchas maneras, desde ser limpiada cada vez que comienza un proceso de extracción y ser un mero lugar temporal donde realizar los procesos, hasta ser persistente y accesible para repetir procesos de carga o para validación. Normalmente se utiliza un enfoque hibrido según el tipo de procesos a realizar.

El area de Stage es un area reservada donde solo podran acceder los procesos ETL (en ningun caso los usuarios), y deberá de estar debidamente dimensionada para contener los volumenes de información necesarios, según el tipo de persistencia de los datos en ella que hayamos elegido.

A continuación, vamos a repasar algunas formas de analizar y documentar los origenes de información, como paso previo a la realización de cualquier tipo de proceso ETL. Despues definiremos y documentaremos nuestra area Stage y detallaremos posteriormente algunas técnicas ETL para el tratamiento de determinadas situaciones, para pasar finalmente al diseño de los procesos.

Posted in ETL, Formacion | 3 Comments »

Learn by doing: less theory, more results.

Posted by Roberto Espinosa en 28 abril 2010


No puedo negarlo, desde que lei la frase me encanto. Con la cita “Learn by doing: less theory, more results” abre en portada el ultimo libro que ha salido al mercado sobre Pentaho Data Integration, escrito por Maria Carina Roldan. Lo estoy leyendo y os lo recomiendo totalmente si quereis empezar con Kettle como es mi caso.

Si traducimos la frase en el traductor de Google nos responde con algo así: “Aprender haciendo: Menos teoría, más resultados”. Y la lectura de la frase me da que pensar sobre muchas cosas. Cuantas veces hemos hecho un curso que luego no hemos llevado a la práctica y se ha quedado todo en el fondo muy profundo de nuestra memoria. O pensar en cuanta gente hay haciendo análisis de cosas sin haberlas puesto en práctica nunca (hasta llegar en ocasiones al limite del bloqueo de acción por el exceso de análisis), que podriamos reducir en un “pienso mucho, pero luego nunca hago nada”. O pensar en la forma de utilizar una situación delicada (como puede ser esta gran crísis que estamos viviendo y que a muchos nos afecta de una forma muy directa), para hacer aquellas cosas para las que nunca tuvimos tiempo, como formarnos, utilizando una situación desfavorable como punto de partida para mejorar en el futuro. Internet, los blogs, los foros, el open source, la apertura de muchos fabricantes de software a versiones “abiertas”, etc,  nos ofrece un sinfín de posibilidades para aprender, para formarnos, para iniciarnos. Y de la mejor forma, haciendo.

No se si por mi trabajo o por el hecho de que mi mente es análitica y siempre intento, cuando planteo cualquier problema o situación, bajar al mínimo nivel de detalle para entender mejor las cosas, que esto me permita tener una visión global, aunque se que a veces intentar entederlo todo puede ser un problema, pues para eso esta la especialización, y una visión generalista no puede abordarlo todo. Entiendo que muchos puedan decir que esta no siempre es la mejor forma de aprender, sobre todo cuando nos vamos a temas muy complejos y que requieren una gran especialización. Pero si puede ser un punto de partida para llevar las cosas a la práctica, para luego continuar con cursos de formación o con la experiencia de un trabajo en el ámbito de lo que estemos estudiando, o para simplemente colaborar de una forma mas activa en un proyecto que se pueda llevar a cabo en el lugar donde trabajemos.

También la reflexión me lleva a pensar en como los políticos afrontan las crisis, siempre llenandonos de demagogía, de cortinas de humo para desviar la atención, de sacar temas absurdos del pasado para dividir en lugar de unir. Y hacer, hacer, realmente poco. Cuantas medidas imaginativas se podrían poner en marcha, con creatividad y conocimiento de causa, para cambiar cosas y aprender como afrontar los problemas, y salir reforzados de las situaciones complicadas. Al paso que van, me veo trabajando a los 70…

Roberto retocando su ultima entrada del Blog (con 70 años...)

Aprovecho para comunicaros que mi blog ha llegado a las 20 mil visitas, sin contar las visitas en dataprix.com, donde he ido publicando todo lo realizado gracias a la oportunidad que me ha dado Carlos Fernandez. Ha sido un trabajo de hormiguita durante estos 6 meses para darle forma a algo que solo estaba en mi cabeza. Siempre con el proposito de aprender, revisar teoria, probar cosas, trastear programas, e intentar transmitir la experiencia a todo el mundo que se esta iniciando en el mundo del Business Intelligence y no encontraba una guia completa para empezar desde un punto de vista amplio. Intentando ademas que el contenido sea de calidad, de no meter la pata, con un enfoque muy práctico, con ejemplos, haciendo hincapie en los temas mas complicados en los que nos surgen dudas cuando estamos empezando.

El dia 3 de mayo es mi cumpleaños, 40 años que ahí es nada, y para mi es un regalo haber sido capaz de darle forma a esto, y que ademas a alguién le interese o le sirva de ayuda en su aprendizaje. Lo dicho, seguimos con el que a partir de ahora va a ser mi lema: “Aprender haciendo: Menos teoría, más resultados”.

¡¡¡¡Muchas gracias!!!! Y gracias a Ana por ayudarme y aguantar esas largas horas delante del ordenador para preparar todo esto…

Posted in Formacion | 14 Comments »

15.2.Kimball vs Inmon. Ampliación de conceptos del Modelado Dimensional.

Posted by Roberto Espinosa en 19 abril 2010


Como hemos visto en la entrada anterior del Blog, estamos utilizando la metodología desarrollada por Kimball (y su enfoque dimensional), para la construcción de nuestro DW. Aunque existen otras metodologias o enfoques para la construcción de un Data Warehouse, las mas importantes son la propia de Ralph Kimball y la definida por Will Inmon (y su enfoque Enterprise Warehouse o CIF).  Es ahí donde llegamos al que parece eterno dilema entre Kimball e Inmon.

Para entender las diferencias entre ambos enfoques, es necesario en primer lugar tener claro algun concepto, como es la diferencia entre Data Warehouse y Data Mart ( Josep Curto nos lo explica muy bien en su blog).

  • Definición de Data Warehouse: Un Data Warehouse proporciona una visión global, común e integrada de los datos de la organización, independiente de cómo se vayan a utilizar posteriormente por los consumidores o usuarios. Normalmente en el almacén de datos habrá que guardar información histórica que cubra un amplio período de tiempo. Pero hay ocasiones en las que no se necesita la historia de los datos, sino sólo sus últimos valores, siendo además admisible generalmente un pequeño desfase o retraso sobre los datos operacionales. En estos casos el almacén se llama almacén operacional (ODS, Operational Data Store).
  • Definición de Data Mart: Podemos entender un Data Mart como un subconjunto de los datos del Data Warehouse con el objetivo de responder a un determinado análisis, función o necesidad y con una población de usuarios específica. Al igual que en un data warehouse, los datos están estructurados en modelos de estrella o copo de nieve y un data mart puede ser dependiente o independiente de un data warehouse. Por ejemplo, un posible usos sería para el data mining.¿Qué diferencia existe entonces entre un data mart y un data warehouse? Su alcance. El data mart está pensado para cubrir las necesidades de un grupo de trabajo o de un determinado departamento dentro de la organización. Es el almacén natural para los datos departamentales. En cambio, el ámbito del data warehouse es la organización en su conjunto. Es el almacén natural para los datos corporativos comunes.

Teniendo en cuenta esto, vamos a intentar realizar un resumen de los aspectos mas importantes de cada una de las metodologías:

Paradigma Bill Inmon.

Bill Inmon ve la necesidad de transferir la información de los diferentes OLTP (Sistemas Transaccionales) de las organizaciones a un lugar centralizado donde los datos puedan ser utilizados para el analisis (sería el CIF o Corporate Information Factory). Insiste ademas en que ha de tener las siguientes características:

  • Orientado a temas.- Los datos en la base de datos están organizados de manera que todos los elementos de datos relativos al mismo evento u objeto del mundo real queden unidos entre sí.
  • Integrado.- La base de datos contiene los datos de todos los sistemas operacionales de la organización, y dichos datos deben ser consistentes.
  • No volátil.- La información no se modifica ni se elimina, una vez almacenado un dato, éste se convierte en información de sólo lectura, y se mantiene para futuras consultas.
  • Variante en el tiempo.- Los cambios producidos en los datos a lo largo del tiempo quedan registrados para que los informes que se puedan generar reflejen esas variaciones.

La información ha de estar a los máximos niveles de detalle. Los Dw departamentales o datamarts son tratados como subconjuntos de este Dw corporativo, que son construidos para cubrir las necesidades individuales de analisis de cada departamento, y siempre a partir de este Dw Central (del que también se pueden construir los ODS ( Operational Data Stores ) o similares).

Enfoque Inmon - DW Corporativo

El enfoque Inmon tambien se referencia normalmente como Top-down. Los datos son extraidos de los sistemas operacionales por los procesos ETL y cargados en las areas de stage, donde son validados y consolidados en el DW corporativo, donde ademas existen los llamados metadatos que documentan de una forma clara y precisa el contenido del DW. Una vez realizado este proceso, los procesos de refresco de los Data Mart departamentales obtienen la información de el, y con las consiguientes transformaciones, organizan los datos en las estructuras particulares requeridas por cada uno de ellos, refrescando su contenido.

La metodologia para la construcción de un sistema de este tipo es la habitual para construir un sistema de información, utilizando las herramientas habituales (esquema Entidad Relacion, DIS (Data Item Sets, etc). Para el tratamiento de los cambios en los datos, usa la Continue and Discrete Dimension Management (inserta fechas en los datos para determinar su validez para las Continue Dimension o bien mediante el concepto de snapshot o foto para las Discrete Dimension).

Al tener este enfoque global, es mas dificil de desarrollar en un proyecto sencillo (pues estamos intentando abordar el “todo”, a partir del cual luego iremos al “detalle”).

Paradigma Ralph Kimball.

El Data Warehouse es un conglomerado de todos los Data Marts dentro de una empresa, siendo una copia de los datos transaccionales estructurados de una forma especial para el analisis, de acuerdo al Modelo Dimensional (no normalizado), que incluye, como ya vimos, las dimensiones de análisis y sus atributos, su organización jerarquica, asi como los diferentes hechos de negocio que se quieren analizar. Por un lado tenemos tablas para las representar las dimensiones y por otro lado tablas para los hechos (las facts tables). Los diferentes Data Marts estan conectados entre si por la llamada bus structure, que contiene los elementos anteriormente citados a traves de las dimensiones conformadas (que permiten que los usuarios puedan realizar querys conjuntos sobre los diferentes data marts, pues este bus contiene los elementos en común que los comunican). Una dimensión conformada puede ser, por ejemplo, la dimensión cliente, que incluye todos los atributos o elementos de analisis referentes a los clientes y que puede ser compartida por diferentes data marts (ventas, pedidos, gestión de cobros, etc).

Enfoque Kimball - Arquitectura Bus del DW

Este enfoque también se referencia como Bottom-up, pues al final el Datawarehouse Corporativo no es mas que la unión de los diferentes datamarts, que estan estructurados de una forma común a través de la bus structure. Esta caracteristica le hace mas flexible y sencillo de implementar, pues podemos construir un Data Mart como primer elemento del sistema de análisis, y luego ir añadiendo otros que comparten las dimensiones ya definidas o incluyen otras nuevas. En este sistema, los procesos ETL extraen la información de los sistemas operacionales y los procesan igualmente en el area stage, realizando posteriormente el llenado de cada uno de los Data Mart de una forma individual, aunque siempre respetando la estandarizacion de las dimensiones (dimensiones conformadas).

La metodología para la construcción del Dw incluye las 4 fases que vimos en la entrada anterior del blog, que son: Selección del proceso de negocio, definición de la granuralidad de la información, elección de las dimensiones de análisis e identificación de los hechos o métricas. Igualmente define el tratamiento de los cambios en los datos a través de las Dimensiones Lentamente Cambiantes (SCD).

Si quereis profundizar en cada una de las filosofias, incluyendo las similitudes y diferencias, os recomiendo leer la presentación realizada por Ian Abramson:

Ahora llega el momento de elegir cual de los enfoques es el mas apropiado para nuestro proyecto (suponiendo que aun no lo hubieramos hecho). En la entrada de blog de Jorge Fernández se planteo un interesante debate sobre la conveniencia de utilizar uno u otro enfoque. Podemos resumir que el enfoque Inmon es mas apropiado para sistemas complejos, donde ademas queremos asegurar su perdurabilidad y consistencia aunque cambien los procesos de negocio en la organización. Pero para pequeños proyectos, donde ademas queremos asegurar la usabilidad de los usuarios con un sistema facil de entender y el rapido desarrollo de la solución, el enfoque Kimball es mas apropiado.

En nuestro caso, vamos a realizar un DW departamental, que ademas es un proyecto piloto. Dado el ambito, y los recursos que se van a destinar a el, es mas conveniente utilizar el enfoque Kimball para el diseño del DW. El DW seria lo mas cercano a un datamart, y lo vamos a desarrollar intentando que las dimensiones esten conformadas (dentro del concepto de datawarehouse bus), con lo que dejaremos la puerta abierta a una ampliación posterior dentro el ámbito de la compañia, añadiendo nuevos cubos que utilizaran las dimensiones conformadas ya definidas.

Ademas de estos dos enfoques, existen otros de los que no hablaremos, como el Hybrid DW o el Federated DW, que utilizan una aproximación intermedia para la construcción del sistema.

Ampliación de Conceptos del Modelado Dimensional

Veamos algunos conceptos más sobre el modelado dimensional:

Dimensiones

Las dimensiones, como ya vimos son los diferentes puntos de vista por los que queremos analizar la información. Las dimensiones incluyen los diferentes atributos que queremos analizar, que ademas se estructuran de forma jerárquica, conforme a diferentes niveles de detalle. Las tablas de dimensiones se construyen incluyendo todos los atributos que la incluyen de una forma desnormalizada, con una clave que identifica el mínimo nivel de detalle. Podemos distinguir varios tipos de dimensiones:

  • Dimensiones Normales: aquellas que agrupan diferentes atributos que estan relacionados por el ambito al que se refieren (todas las características de un cliente, los diferentes componentes de la dimensión tiempo, etc).
  • Dimensiones Causuales: aquella que incluye atributos que pueden causar cambios en los procesos de negocio (por ejemplo la dimensión promoción en el proceso de negocio de ventas).
  • Dimensiones Heterogeneas:  dimensiones que agrupar conjuntos heterogeneos de atributos, que no estan relacionados entre si.
  • Dimensiones Roll-Up: es una dimensión que es un subconjunto de otra, necesarias para el caso en que tenemos tablas de hechos con diferente granuralidad (ver la entrada anterior del blog).
  • Dimensiones Junk: dimension que agrupa indicadores de baja cardinalidad como pueden ser flags o indicadores.
  • Dimensiones Role-playing:  cuando una misma dimensión interviene en una tabla de hechos varias veces (por ejemplo, la fecha en una tabla de hechos donde se registran varias fechas referidas a conceptos diferentes), es necesario reutilizar la misma dimension, pues no tiene sentido crear tantas dimensiones como usos se hagan de ella. Para ello se definen las dimensiones Role-playing. Podemos crear vistas sobre la tabla de la dimensión completa que nos permiten utilizarla varias veces o jugar con los alias de tabla. La misma dimensión juega un rol diferente según el sitio donde se utiliza.
  • Dimensiones Degeneradas: son dimensiones que no tienen ningún atributo y por tanto, no tienen una tabla especifica de dimensión. Solo se incluye para ellas un identificador en la tabla de hechos, que identifica completamente a la dimensión (por ejemplo, un pedido de ventas). Nos interesa tener identificada la transacción (para realizar data mining, por ejemplo), pero los datos interesantes de este elemento los tenemos repartidos en las diferentes dimensiones (cliente, producto, etc).
  • Mini dimensiones o Dimensiones Outrigger: conjunto de atributos de una dimensión que se extraen la tabla de dimensión principal pues se suelen analizar de forma diferente. El tipico ejemplo son los datos sociodemográficos asociados a un cliente (que se utilizan, por ejemplo, para el datamining).

Es necesario gestionar de una forma correcta los cambios que se producen en los atributos de las dimensiones (por ejemplo, el cambio de comercial o de canal de un cliente, el cambio de familia de un material, etc), que nos permitan realizar de una forma correcta el análisis histórico de los datos. Para ello se introduce el concepto de Dimensión Lentamente Cambiante (SCD), estableciendo varios metodos para su procesamiento (que tendran que ser tenidos en cuenta en los procesos ETL). Resumiendo, tenemos varios tipos de metodos para el tratamiento (ampliar información en el blog de Bernabeu Dario o en BI Facil):

  • SCD Tipo 1: Sobreescribir: cuando hay un cambio en los valores de un atributo, sobrescribimos el valor antiguo con el nuevo sin registrar una historia. Esto significa perder toda la historia del dato, y cuando hagamos un análisis veremos la información histórica desde el punto de vista actual.
  • SCD Tipo 2: Añadir fila: cuando hay un cambio, creamos un nuevo registro en la tabla. El nuevo registro tiene una nueva clave subrogada, de forma que una entidad de sistema operacional (por ejemplo, un cliente), puede tener varios registros en la tabla de la dimensión según se van produciendo los cambios. Estamos gestionando un versionado, que ademas puede incluir unas fechas para indicar los periodos de validez, numerador de registros o un indicador de registro activo o no.
  • SCD Tipo 3: Añadir columna: cuando hay un cambio, nos guardamos el valor anterior en una columna distinta, actualizando el campo con el nuevo valor (para cada campo, tendremos una tupla valor anterior, valor actual). Solo nos vamos a guardar, por tanto, los dos ultimos valores.

Cada una de las dimensiones tiene una clave que identifica cada uno de los registros que la conforman. Para definir esta clave, podemos utilizar los mismos valores que se utilizan en los sistemas operacionales (con lo que nos estamos limitando a la forma en que estan definidos alli y seguramente estableciendo limitaciones para el futuro) o bien utilizar las llamadas Surrogated Keys (Claves Subrogadas), que son identificadores que nos inventamos en el Dw, que nos va a permitir optimizar las consultas sql y evitar las posibles limitaciones de la definicion de las claves existentes, desvinculandola totalmente de los sistemas origen, ademas del tratamiento de las SCD. Os recomiendo la lectura de la entrada del blog de BI Facil referente a este tema.

Hechos

Los hechos son los indicadores de negocio que dan sentido al análisis de las dimensiones. Las tablas de hechos incluyen los indicadores asociados a un proceso de negocio en concreto, ademas de las claves de las dimensiones que intervienen en dicho proceso, en el mínimo nivel de granuralidad o detalle. Podemos tener varios tipos de tablas de hechos, como describe muy bien otra vez Josep Curto:

  • Transaction Fact Tables: representan eventos que suceden en un determinado espacio-tiempo. Se caracterizan por permitir analizar los datos con el máximo detalle. Reflejan las transacciones relacionadas con nuestros procesos de negocio (ventas, compras, inventario, contabilidad, etc).
  • Factless Fact Tables: Son tablas que no tienen medidas y representan la ocurrencia de un evento determinado. Por ejemplo, la asistencia a un curso puede ser una tabla de hechos sin metricas asociadas.
  • Periodic Snapshot Fact Tables: Son tablas de hecho usadas para recoger información de forma periódica a intervalos de tiempo regulares sobre un hecho. Nos permiten tomar una foto de la situación en un momento determinado (por ejemplo al final del dia, de una semana o de un mes). Un ejemplo puede ser la foto del stock de materiales al final de cada día.
  • Accumulating Snapshot Fact Table: representan el ciclo de vida completo de una actividad o proceso, que tiene un principio y final. Suelen representar valores acumulados.
  • Consolidated Fact Tables: tablas de hechos construidas como la acumulación, en un nivel de granuralidad o detalle diferente, de las tablas de hechos de transacciones.

Podemos distinguir diferentes tipos de medidas o indicadores, basadas en el tipo de información que recopilan así como su funcionalidad asociada (ver blog de Josep Curto):

  • Métricas: valores que recogen el proceso de una actividad o los resultados de la misma. Esto medidas proceden del resultado de la actividad de negocio.
    • Métricas de realización de actividad (leading): miden la realización de un actividad. Por ejemplo, la participación de una persona en un evento.
    • Métricas de resultado de una actividad (lagging): recogen los resultados de una actividad. Por ejemplo, la cantidad de unidades vendidas.
  • Indicadores clave: entendemos por este concepto, valores correspondientes que hay que alcanzar, y que suponen el grado de asunción de los objetivos. Estas medidas proporcionar información sobre el rendimiento de una actividad o sobre la consecución de una meta.
    • Key Performance Indicator (KPI): Indicadores clave de rendimiento. Más allá de la eficacia, se definen unos valores que nos explican en qué rango óptimo de rendimiento nos deberíamos situar al alcanzar los objetivos. Son métricas del proceso.
    • Key Goal Indicator (KGI): Indicadores de metas. Aquí podriamos incluir por ejemplo, el objetivo de rentabilidad del proceso de negocio de ventas.

Las medidas se pueden clasificar igualmente como aditivas, semiaditivas y no aditivas según si se pueden sumarizar a lo largo de todas las dimensiones, solo para algunas o para ninguna. Igualmente, las medidas son derivadas cuando se calculan a partir de los valores de otras medidas o indicadores.

Según si desnormalizamos  las tablas de dimensiones o no, tendremos un esquema de estrella (star) o copo de nieve (snowflaked). Kimball recomienda utilizar siempre la desnormalización total, pero esta claro que hay situaciones en las que no queda mas remedio que pasarnos al esquema copo de nieve (aunque solo sea para alguna dimensión).

Para terminar, si quereis realmente profundizar en el modelado dimensional y en las multiples variantes de situaciones que os podeis encontrar, os recomiendo la lectura del libro Advanced Data Warehouse Design, en formato electrónico.

Posted in Business Intelligence, Formacion, Modelado de Datos | 10 Comments »

Teoria de Data Mining.

Posted by Roberto Espinosa en 26 febrero 2010


En una entrada anterior del Blog (2.4. DataMining o Mineria de Datos.) intentamos hacer una aproximación inicial a la teoria del Data Mining. Los procesos de data mining tratan de extraer información oculta en los datos mediante el uso de diferentes técnicas (la mayoría relacionadas con la estadística y los modelos matemáticos, en combinación con aplicaciones informáticas).

Dada la complejidad de estas técnicas, y no siendo el cometido de esta blog entrar en profundidad en esta materia (por cuestiones de tiempo y de conocimientos), nos limitaremos a ver un par de metodologias de datamining, enumerar las técnicas mas habituales y a recordar los conceptos de tres de estas técnicas mediante ejemplos prácticos. Esos mismos ejemplos nos permitirán la posterior utilización de las herramientas de DataMining que proporciona Microstrategy 9 (también incluidas en la Microstrategy Reporting Suite) y explicar que visión tiene el producto de las técnicas de Data Mining.

Antes de comenzar, os recomiendo ver la presentación Data Mining.Extracción de Conocimiento en Grandes Bases de Datos, realizada por José M. Gutiérrez, del Dpto. de Matemática Aplicada de la Universidad de Cantabria, Santander.

Para quien quiera o necesite profundizar en la teoria de data mining, sus técnicas y posibilidades, os dejo la lista de referencias a algunos de los libros mas importantes en este ámbito:

  1. Data mining: practical machine learning tools and techniques.
  2. Data Mining Techniques: For Marketing, Sales, and Customer Relationship.
    Management, 2nd Edition
  3. The elements of statistical learning : data mining, inference, and prediction.
  4. Advanced Data Mining Techniques.
  5. Data Mining: Concepts and Techniques.
  6. Data Preparation for Data Mining.

Pasos a seguir en un proyecto de Data Mining

Existen varias metodologias estandar para desarrollar los analisis DataMining de una forma sistematica. Algunas de las mas conocidas son el CRISP, que es un estandar de la industria que consiste en una secuencia de pasos que son habitualmente utilizados en un estudio de data mining. El otro metodo es el SEMMA, especifico de SAS. Este metodo enumera los pasos a seguir de una forma mas detallada. Veamos un poco en que consiste cada uno.

CRISP-DM (Cross-Industry Standard Process for Data Mining).

El modelo consiste en 6 fases relacionadas entre si de una forma cíclica (con retroalimentación). Podeis ampliar información de la metodologia en la sección de manuales de Dataprix.com. Igualmente, podeis acceder la web del proyecto Crisp aquí. Las fases son las siguientes:

  • Business Understanding: comprensión del negocio incluyendo sus objetivos, evaluación de la situación actual, estableciendo unos objetivos que habran de cumplir los estudios de data mining y desarrollando un plan de proyecto. En esta fase definiremos cual es el objeto del estudio y porque se plantea. Por ejemplo, un portal de ventas de viajes via web quiere analizar sus clientes y habitos de compra para hacer segmentación de ellos y lanzar campañas de marketing especificas sobre cada target con el objetivo de aumentar las ventas. Ese sera el punto de partida de un proyecto de datamining. Información detallada de la fase en Dataprix.com.
  • Data Understanding: una vez establecidos los objetivos del proyecto, es necesario la comprensión de los datos y la determinación de los requerimientos de información necesarios para poder llevar a cabo nuestro proyecto. En esta fase se pueden incluir la recogida de datos, descripción de ellos, exploración y la verificación de la calidad de estos. En esta fase podemos utilizar técnicas como resumen de estadísticas (con visualización de variables) o realizar analisis de cluster con la intención de identificar patrones o modelos dentro de los datos. Es importante en esta fase que este definido claramente lo que se quiere analizar, para poder identificar la información necesaria para describir el proceso y poder analizarlo. Luego habrá que ver que información es relavante para el analisis (pues hay aspectos que se podrán desestimar) y finalmente habrá que verificar que las variables identificadas son independientes entre si. Por ejemplo, estamos en un proyecto de data mining de analisis de clientes para segmentación. De toda la información disponible en nuestros sistemas o de fuentes externas, habrá que identificar cual esta relacionada con el problema (datos de clientes, edad, hijos, ingresos, zona de residencia), de toda esa información, cual es relevante (no nos interesan, para el ejemplo, las aficiones de los clientes) y finalmente, de las variables seleccionadas, verificar que no estan relacionadas entre si (el nivel de ingresos y la zona de residencia no son variables independientes, por ejemplo). La información normalmente se suele clasificar en Demografica (ingresos, educación, numero de hijos, edad), sociografica (hobbys, pertenencia a clubs o instituciones), transaccional (ventas, gastos en tarjeta de credito, cheques emitidos), etc. Ademas, los datos pueden ser del tipo Cuantitativo (datos medidos usando valores numericos) o Cualitativo (datos que determinan categorias, usando nominales u ordinales). Los datos Cuantitativos pueden ser representados normalmente por alguna clase de distribución de probabilidad (que nos determinara como los datos se dispersan y agrupan). Para los Cualitativos, habrá que previamente codificarlos a numeros que nos describiran las distribuciones de frecuencia. Información detallada de la fase en Dataprix.com.
  • Data Preparation: una vez los recursos de datos estan identificados, es necesario que sean seleccionados, limpiados, tranformados a la forma deseada y formateados. En esta fase se llevara a cabo los procesos de Data Cleaning y Data Transformation, necesarios para el posterior modelado. En esta fase se puede realizar exploración por los datos  a mayor profundidad para encontrar igualmente patrones dentro de los datos. En el caso de estar utilizando un Data Warehouse como origen de datos, ya se habran realizado estas tareas al cargar los datos en el. También puede darse el caso de que necesitemos información agregada (por ejemplo, acumulación de ventas de un periodo), información que podremos extraer de nuestro DW con las herramientas tipicas de un sistema BI. Otro tipo de transformaciónes pueden ser convertir rangos de valores a un valor identificativo (ingresos desde/hasta determinan la categoria de ingresos n), o relizar operaciones sobre los datos (para determinar la edad de un cliente utilizamos la fecha actual y su fecha de nacimiento), etc. Ademas, cada herramienta software de Data Mining puede tener unos requerimientos especificos que nos obliguen a preparar la información en un formato determinado (por ejemplo, Clementine o PolyAnalyst tienen diferentes tipos de datos). Información detallada de la fase en Dataprix.com.

Esquema del Metodo CRISP

  • Modeling: en la fase de modelización, utilizaremos software especifico de data mining como herramientas de visualización (formateo de datos para establecer relaciones entre ellos) o analisis de cluster (para identificar que variables se combinan bien). Estas herramientas pueden ser utiles para un analisis inicial, que se podran complementar  con reglas de inducción para desarrollar las reglas de asociación iniciales y profundizar en ellas. Una vez se profundiza en el conocimiento de los datos (a menudo a traves de patrones de reconocimiento obtenidos al visualizar la salida de un modelo), se pueden aplicar otros modelos apropiados de analisis sobre los datos (como por ejemplo arboles de decisión). En esta fase dividiremos los conjuntos de datos entre de aprendizaje y de test. Las herramientas utilizadas nos permitiran generar resultados para varias situaciones. Ademas, el uso interactivo de multiples modelos nos permitira profundizar en el descubrimiento de los datos. Información detallada de la fase en Dataprix.com.
  • Evaluation: el modelo resultante debera de ser evaluado en el contexto de los objetivos de negocio establecidos en la primera fase. Esto nos puede llevar a la identificación de otras necesidades que pueden llevarnos a volver a fases anteriores para profundizar (si encontramos por ejemplo, una variable que afecta al analisis pero que no hemos tenido en cuenta al definir los datos). Esto sera un proceso interactivo, en el que ganaremos comprensión de los procesos de negocio como resultado de las tecnicas de visualización, tecnicas estadísticas y de inteligencia artificial, que mostraran al usuario nuevas relaciones entre los datos, y que permitiran conocer mas a fondo los procesos de la organización. Es la fase mas critica, pues estamos haciendo una interpretacion de los resultados. Información detallada de la fase en Dataprix.com.
  • Deployment: la mineria de datos puede ser utilizada tanto para verificar hipotesis previamente definidas (pensamos que si hacemos un descuento de un 5% aumentaran las ventas, pero no lo hemos comprobado con un modelo antes de aplicar la medida), o para descubrir conocimiento (identificar relaciones utiles y no esperadas). Este conocimiento descubierto nos puede servir para aplicarlo a los diferentes procesos de negocio y aplicar cambios en la organización donde sea necesario. Por ejemplo, pensar en el tipico ejemplo de la compañia de telefonos moviles que detecta que hay fuga de clientes de larga duración por un mal servicio de atención al cliente. Ese aspecto detectado hará que se realicen cambios en la organización, para mejorar ese aspecto. Los cambios aplicados se podrán monitorizar, para verificar en un tiempo determinado su corrección o no, o si tienen que ser ajustados para incluir nuevas variables. Tambien será importante documentarlos para ser utilizados como base en futuros estudios. Información detallada de la fase en Dataprix.com.

El proceso de seis fases no es un modelo rígido, donde usualmente hay mucha retroalimentación y vuelta a fases anteriores. Ademas, los analistas experimentados no tendran la necesidad de aplicar cada fase en todos los estudios.

SEMMA (Sample, Explore, Modify, Model and Assess).

Con el objetivo de ser aplicadas correctamente, una solución de datamining debe de ser vista como un proceso mas que como un conjunto de herramientas o técnicas. Esto es lo que pretende la metodologia desarrollada por el instituto SAS, llamada SEMMA, que significa sample=muestreo, explore=explora, modify=modifica, model=modeliza y assess=evalua. Este metodo pretende hacer mas facil la realización de exploración estadistica y las tecnicas de visualización, seleccionar y transformar las variables predictivas mas significantes, modelizar las variables para predecir resultados y finalmente confirmar la fiabilidad de un modelo. Al igual que el modelo Crisp, es posible la retroalimentación y el volver a fases anteriores durante el proceso. La representación grafica es la siguiente:

Esquema del Metodo SEMMALas fases serían las siguientes:

  • Sample: de un gran volumen de información, extraemos una muestra lo suficientemente significativa y con el tamaño apropiado para poder manipularla con agilidad. Esta reducción del tamaño de los datos nos permite realizar los analisis de una forma mas rapida y conseguimos también obtener información crucial de los datos de una forma mas inmediata. Las muestras de datos las podemos clasificar en tres grupos, segun el objeto para el que se usan: Training (usadas para la construcción del modelo), Validation( usadas para la evaluación del modelo) y Test (usadas para confirmar como se generalizan los resultados de un modelo).
  • Explore: en esta fase de exploración el usuario busca tendencias imprevistas o anomalias para obtener una mejor comprensión del conjunto de datos. En esta fase se explora visualmente y numericamente buscando tendencias o agrupaciones. Esta exploracion ayuda a refinar y a redirigir el proceso. En el caso de que los analisis visuales no den resultados, se exploraran los datos con tecnicas estadisticas como analisis de factor, analisis de correspondencia o clustering.
  • Modify: aqui es donde el usuario, crea, selecciona y transforma las variables con el objetivo puesto en la construcción del modelo. Basandonos en los descubrimientos de la fase de exploración, modificaremos los datos para incluir información de las agrupaciones  o para introducir nuevas variables que pueden ser relevantes, o eliminar aquellas que realmente no lo son.
  • Model: cuando encontramos una combinación de variables que predice de forma fiable un resultado deseado. En este momento estamos preparados para construir un modelo que explique los patrones en los datos. Las tecnicas de modelado incluyen las redes neuronales, arboles de decision,  modelos logisticos o modelos estadisticos como series de tiempo, razonamientos basados en memoria, etc.
  • Assess: en esta fase el usuario evalua la utilidad y fiabilidad de los descubrimientos realizados en el proceso de datamining. Verificaremos aqui lo bien que funciona un modelo. Para ello, podremos aplicarlo sobre muestreos de datos diferentes (de test) o sobre otros datos conocidos, y asi confirmar su vaildez.

Tecnicas de DataMining

Análisis estadístico:

Utilizando las siguientes herramientas:
1.ANOVA: o Análisis de la Varianza, contrasta si existen diferencias significativas entre las medidas de una o más variables continuas en grupo de población distintos.

2.Regresión: define la relación entre una o más variables y un conjunto de variables predictoras de las primeras.

3.Ji cuadrado: contrasta la hipótesis de independencia entre variables. Componentes principales: permite reducir el número de variables observadas a un menor número de variables artificiales, conservando la mayor parte de la información sobre la varianza de las variables.

4.Análisis cluster: permite clasificar una población en un número determinado de grupos, en base a semejanzas y desemejanzas de perfiles existentes entre los diferentes componentes de dicha población.

5.Análisis discriminante: método de clasificación de individuos en grupos que previamente se han establecido, y que permite encontrar la regla de clasificación de los elementos de estos grupos, y por tanto identificar cuáles son las variables que mejor definan la pertenencia al grupo.

Métodos basados en árboles de decisión:

El método Chaid (Chi Squared Automatic Interaction Detector) es un análisis que genera un árbol de decisión para predecir el comportamiento de una variable, a partir de una o más variables predictoras, de forma que los conjuntos de una misma rama y un mismo nivel son disjuntos. Es útil en aquellas situaciones en las que el objetivo es dividir una población en distintos segmentos basándose en algún criterio de decisión.

El árbol de decisión se construye partiendo el conjunto de datos en dos o más subconjuntos de observaciones a partir de los valores que toman las variables predictoras. Cada uno de estos subconjuntos vuelve después a ser particionado utilizando el mismo algoritmo. Este proceso continúa hasta que no se encuentran diferencias significativas en la influencia de las variables de predicción de uno de estos grupos hacia el valor de la variable de respuesta.

La raíz del árbol es el conjunto de datos íntegro, los subconjuntos y los subsubconjuntos conforman las ramas del árbol. Un conjunto en el que se hace una partición se llama nodo.

El número de subconjuntos en una partición puede ir de dos hasta el número de valores distintos que puede tomar la variable usada para hacer la separación. La variable de predicción usada para crear una partición es aquella más significativamente relacionada con la variable de respuesta de acuerdo con test de independencia de la Chi cuadrado sobre una tabla de contingencia.

Algoritmos genéticos:

Son métodos numéricos de optimización, en los que aquella variable o variables que se pretenden optimizar junto con las variables de estudio constituyen un segmento de información. Aquellas configuraciones de las variables de análisis que obtengan mejores valores para la variable de respuesta, corresponderán a segmentos con mayor capacidad reproductiva. A través de la reproducción, los mejores segmentos perduran y su proporción crece de generación en generación. Se puede además introducir elementos aleatorios para la modificación de las variables (mutaciones). Al cabo de cierto número de iteraciones, la población estará constituida por buenas soluciones al problema de optimización.

Redes neuronales:

Genéricamente son métodos de proceso numérico en paralelo, en el que las variables interactúan mediante transformaciones lineales o no lineales, hasta obtener unas salidas. Estas salidas se contrastan con los que tenían que haber salido, basándose en unos datos de prueba, dando lugar a un proceso de retroalimentación mediante el cual la red se reconfigura, hasta obtener un modelo adecuado.

Red Neuronal en Microstrategy

Lógica difusa:

Es una generalización del concepto de estadística. La estadística clásica se basa en la teoría de probabilidades, a su vez ésta en la técnica conjuntista, en la que la relación de pertenencia a un conjunto es dicotómica (el 2 es par o no lo es). Si establecemos la noción de conjunto borroso como aquel en el que la pertenencia tiene una cierta graduación (¿un día a 20ºC es caluroso?), dispondremos de una estadística más amplia y con resultados  más cercanos al modo de razonamiento humano.

Series temporales:

Es el conocimiento de una variable a través del tiempo para, a partir de ese conocimiento, y bajo el supuesto de que no van a producirse cambios estructurales, poder realizar predicciones. Suelen basarse en un estudio de la serie en ciclos, tendencias y estacionalidades, que se diferencian por el ámbito de tiempo abarcado, para por composición obtener la serie original. Se pueden aplicar enfoques híbridos con los métodos anteriores, en los que la serie se puede explicar no sólo en función del tiempo sino como combinación de otras variables de entorno más estables y, por lo tanto, más fácilmente predecibles.

Clasificación de las técnicas de Data Mining

Las tecnicas de Data Mining las podemos clasificar en Association, Classification, Clustering, Predictions y Series Temporales.

  • Association (asociacion):  la relacion entre un item de una transaccion y otro item en la misma transacción es utilizado para predecir patrones. Por ejemplo, un cliente compra un ordenador (X) y a la vez compra un raton(Y) en un 60% de los casos. Este patron ocurre en un 5,6% de las compras de ordenadores. La regla de asociación en esta situación es que “X implica Y, donde 60% es el factor de confianza y 5,6% el factor de soporte. Cuando el factor de confianza y al factor de soporte estan representados por las variables linguisticas alto y bajo, la regla de asociacion se puede escribir en forma de logica difusa, como: “cuando el factor de suporte es bajo, X implica Y es alto”. Este seria el tipico ejemplo de datamining de estudio realizado en supermercados con la asociación entre la venta de pañales de bebe y cerveza (ver entrada del blog Bifacil). Usan los algoritmos de reglas de asociación y arboles de decisión.

Modelo Asociacion en Microstrategy - Compra de Peliculas de DVD

  • Classification (clasificacion): en la clasificación, los metodos tienen la intención de aprender diferentes funciones que clasifiquen los datos dentro de un conjunto predefinido de clases. Dado un nuevo de clases predefinidas, un numero de atributos y un conjunto de datos de aprendizaje o entrenamiento, los metodos de clasificación pueden automaticamente predecir la clase de los datos previamente no clasificados. Las claves mas problematicas relacionadas con la clasificación son las evaluacion de los errores de clasificación y la potencia de predicción.  Las tecnicas matematicas mas usadas para la clasificación son los arboles de decisión binarios, las redes neuronales, programación lineal y estadistica. Utilizando un arbol de decisión binario, con un modelo de inducción de arbol en el formato Si-No, podremos posicionar los datos en las diferentes clases según el valor de sus atributos. Sin embargo, esta clasificación puede no ser optima si la potencia de predicción es baja. Con el uso de redes neuronales, se puede construir un modelo de inducción neuronal.  En este modelo, los atributos son capas de entrada y las clases asociadas con los datos son las capas de salida. Entre las capas de entrada y de salida hay un gran numero de conexiones ocultas que aseguran la fiabilidad de la clasificación (como si fuesen las conexiones de una neurona con las de su alrededor).El modelo de induccion neuronal ofrece buenos resultados en muchos analisis de data mining, cuando hay un gran numero de relaciones se complica la implementación del metodo por el gran numero de atributos. Usando tecnicas de programación lineal, el problema de la clasificación es visto como un caso especial de programación lineal.  La programación lineal optimiza la clasificación de los datos, pero puede dar lugar a modelos complejos que requieran gran tiempo de computación. Otros metodos estadisticos, como la regresión lineal, regresion discriminante o regresión logistica tambien son populares y usados con frecuencia en las procesos de clasificación.

Arbol Decision en Microstrategy

  • Clustering (segmentación): el analisis de cluster toma datos sin agrupar y mediante el uso de tecnicas automaticas realiza la agrupación de estos. El clustering no esta supevisado y no requiere un set de datos de aprendizaje. Comparte un conjunto de metodologias con la clasificación. Es decir, muchos de los modelos matematicos utilizados en la clasificación pueden ser aplicados al analisis cluster tambien. Usan los algoritmos de clustering y de sequence clustering.
  • Prediction (predicción)/Estimación: el analisis de predicción esta relacionado con la tecnicas de regresión. La idea principal del analisis de predicción es descubrir las relaciones entre variables dependientes e independientes y las relaciones entre variables independientes. Por ejemplo, si las ventas es una variable independientes, el benefición puede ser una variable dependiente.
  • Series Temporales (pronostico): utilizando datos historicos junto con tecnicas de regresión lineal o no lineal, podemos producir curvas de regresión que se utilizaran para establecer predicciones a futuro. Usan los algoritmos de series de tiempo.

Ejemplo 1. Analisis de cesta de la compra (Asociacion).

Es el tipico ejemplo que se utiliza para explicar los ambitos de utilización del datamining ( con la asociación entre la venta de pañales de bebe y cerveza ). En nuestro caso, utilizando los ejemplos que proporciona Microstrategy en su plataforma, en el proyecto de aprendizaje que llaman Microstrategy Tutorial, veremos un ejemplo de utilización de técnicas de analisis de asociacion.

En el ejemplo, se analizan las ventas de DVD´s de unos grandes almacenes y se trata de encontrar la asociación entre la venta de diferentes peliculas. Es decir, intentamos encontrar que títulos se venden conjuntamente con el objetivo de establecer posteriormente promociones comerciales de esas peliculas (por ejemplo, venta de packs, ubicación de las peliculas juntas en los pasillos, promoción de descuento por la compra de la segunda unidad, etc), con el objetivo de aumentar las ventas. Para este tipo de analisis utilizaremos analisis de reglas de asociación.

Ejemplo 2. Segmentación de clientes (Analisis de cluster).

Con este analisis pretendemos analizar nuestros clientes y utilizando información demográfica de ellos (edad, educación, numero de hijos, estado civil o tipo de hogar), realizar una segmentación de mercado para preparar el lanzamiento de determinados productos o la realización de ofertas promocionales.

En este caso, realizaremos un analisis de cluster, utilizando el algoritmo k-means, que es el que soporta Microstrategy.

Ejemplo 3. Predicción de ventas en una campaña (Arbol de decisión).

En este analisis utilizaremos un arbol de decisión para determinar la respuesta de un determinado grupo de clientes a rebajas en determinados productos en la epoca de vuelta al colegio. Para ello, utilizaremos arboles de decisión del tipo binario (recordemos que los arboles de decisión se pueden utilizar tanto para clasificación como para analisis de regresión, como en este caso). Intentaremos determinar como influyen factores como la edad, el sexo o el numero de hijos en la probabilidad de realizar compras en esa campaña de rebajas.

En la proxima entrada del blog detallaremos estos ejemplos utilizando las herramientas de Data Mining de Microstrategy.

Posted in Business Intelligence, Data Mining, Formacion | Leave a Comment »

Teoria de cuadros de mando. Tarjetas de puntuación y Dashboard.

Posted by Roberto Espinosa en 14 febrero 2010


En una entrada anterior del Blog ( 2.3. EIS (Executive information system). Cuadros de Mando Integral. DSS (Decission Support System). )  hicimos una aproximación a la teoria de cuadros de mando y los sistemas de apoyo a la toma de decisiones (EIS/DSS). Vamos a profundizar un poco más antes de ver la forma de construir estos elementos utilizando Microstrategy, a través de los Documentos de Report Services.

Teoría de cuadros de mando (Norton y Kaplan)

La teoria de cuadros de mando, impulsada por Robert S.Kaplan y David P.Norton surgio en los años 90 como respuesta ante la necesidad de analizar las organizaciones desde un punto de vista diferente al financiero, que se estaba quedando obsoleto. Se pretendia establecer un nuevo modelo de medidas dentro de las empresas para generar valor añadido en el futuro y también para conocer mejor las organizaciones.

Para ello, el instituto Nolan Norton, patrocinó un estudio de un año con la participación de varias compañias, de todos los sectores ( industria, servicios, alta tecnología, etc), con el objetivo de definir un “Corporate Scorecard” o cuandro de mando corporativo, que contuviese, ademas de los indicadores financieros tradicionales, medidas referentes a los tiempos de servicio a los clientes, calidad, tiempos de fabricación o desarrollo de nuevos productos. Durante el estudio, se fueron añadiendo otras medidas de productividad o calidad, que fueron ampliando los elementos a incluir en este cuadro de mando.

De ahi surgio el concepto “Balanced Scorecard”, que organizaba los indicadores o medidas en cuatro grandes grupos o perspectivas: financiera, cliente, interna e innovación y aprendizaje. El nombre de Balanced refleja que los indicadores tratan de ser un equilibrio entre los objetivos a corto y largo plazo, entre las medidas financieras y las no financieras, entro los indicadores de retraso o liderazgo y entre las perspectivas internas y externas.

Durante el estudio, varias compañias construyeron prototipos de un “Balanced Scorecard” dentro de sus compañias y fueron realimentando el estudio con las ventajas, oportunidades o incovenientes que fueron surgiendo durante su implantación. Una de las cosas mas importantes descritas fue el hecho que este sistema era algo mas que un sistemas de medidas, sino un alineamiento de las organizaciones con sus nuevas estrategias, partiendo de la información historica y de la compañia, con el objetivo de generar nuevas oportunidades de negocio o valor añadido. Los indicadores tenían ademas que estar alineados con el plan estrategico de la empresa, por lo que sería importante elegir los indicadores apropiados para cada organización.

Las experiencias demostraron que con 20 o 25 medidas a traves de las 4 perspectivas descritas se podría implementar una estrategia simple, aunque la elección de las medidas apropiadas podría ser algo complejo, así como el hecho de ver las relaciones causa-efecto entre los diferentes indicadores (por ejemplo, como determinar que el aumento de la formación de los empleados, la inversión en tecnología o la innovación en productos pueden producir un aumento de los ratios financieros de la compañia en el futuro).

Los resultados del estudio y las experiencias posteriores de los autores fueron publicadas en el libro “Traslating Strategy into Action: The Balanced Scorecard”, del que vamos a tratar de hacer un pequeño resumen.

Necesidad de los cuadros de mando en la edad de la información

Los autores abren el libro con una comparación entre un avión y una empresa, entre un piloto y un gestor de compañias. En un moderno avión, todos nos quedariamos sorprendidos si entrasemos en la cabina y viesemos un sencillo cuadro de mandos con un solo instrumental. Pensariamos, ¿que medira este instrumental?, ¿el nivel de gasolina o la velocidad del aire?, ¿es suficiente para el caso de problemas?¿y la altitud?. Esta claro que un moderno avión necesita muchos indicadores que un piloto preparado es capaz de analizar para manejar el avión correctamente. Para el caso de las empresas, un gestor necesitara los correspondientes instrumentos que le monitorizen desde la situación actual hacia la situación futura.

Este es lo que ha de proporcionar el cuadro de mando o Balanced Scorecard. Este ha de traducir la estrategia de la empresa en un conjunto comprensible de medidas de rendimiento que proporcionen el marco de medida estrategica y de sistema de gestión. Los cuadros de mando van a seguir incluyendo los objetivos financieros tradicionales, pero ademas van a incluir los elementos para conseguir esos objetivos financieros, en un equilibrio a través de las cuatro perspectivas indicadas.

A esto habría que añadir que las compañias necesitan un instrumento para ser competitivas en los entornos empresariales actuales, de gran competencia, donde se hace necesario la gestión de activos intangibles que son fundamentales para competir con exito. Alguno de estos activos pueden ser las relaciones de clientes, innovacion de servicios y productos en nichos de mercado diferenciados, productos de alta calidad y bajo coste con tiempos de desarrollo cortos, desarrollo de tecnologias de información, bases de datos o sistemas, movilización de las habilidades de los empleados y su motivación para una continua mejora de los procesos, calidad o tiempos de respueta, etc.

En el modelo de contabilidad financiera tradicional, todos los nuevos programas, iniciativas o procesos de gestión del cambio se implementaban en un entorno gobernado por los informes financieros trimestrales y anuales, anclados en un modelo contable definido hace siglos. Este modelo todavia se sigue utilizando en todas las compañias, pero seria ideal poder complementarlo incorporando la información de los activos no tangibles de los que hablabamos antes.

De la colisión entre estos dos elementos surge una nueva sintexis, el Balanced Scorecard. Pero las medidas financieras hablan de la historia, del pasado, pero no ven como algo crítico  las relaciones con los clientes o la inversión en capacidades a largo plazo. Y esas medidas son inadecuadas para las transformaciones que ha de realizar la empresa con el objetivo de crear valor en el entorno de las relaciones con clientes y proveedores, empleados, procesos, tecnología e innovación.

The Balanced Scorecard complementa las medidas financieras del pasado con las medidas de los indicadores de rendimiento futuro, expandiendo los objetivos de negocio mas alla de las medidas financieras. Con un sistema como este, los ejecutivos podrán medir las unidades de negocio que crean valor para futuros y actuales clientes y como ellas deben mejorar su capacidades internas y la inversión en los empleados, sistemas o procedimientos, capturando las actividades críticas de creación de valor. Aunque retiene la visión financiera del corto plazo, incluye la visión de largo plazo que revela las posibilidades financieras y de competitividad a largo plazo.

Ademas, ha de ser algo mas que un sistema de medición. Requiere a nivel de organización el establecimiento de unos objetivos estratégicos que incluyan los objetivos estratégicos de cada unidad de negocio. Con estos objetivos globales a nivel financiero y de cliente establecidos, la compañia identificara sus objetivos y medidas a nivel de procesos internos, que habrán de ser convenientemente comunicados a lo largo de la organización para involucrar a todos los participantes en los procesos internos. Finalmente, esos objetivos tendrán que ser traducidos a nivel operacional en cada ambito de la compañia. Podemos ver que podemos estar hablando de un cambio de rumbo dentro de la organización, partiendo del BS en un escenario habitual de 3 o 5 años.

Las 4 perspectivas del Balanced Scorecard.

Veamos un poco en que consiten las 4 perspectivas del Balanced Scorecard:

La perspectiva financiera se sigue manteniendo porque es una forma de medir las consecuencias económicas de las acciones tomadas en las organizaciones. Incorpora la visión de los accionistas y mide la creación de valor de la empresa. Normalmente se referira a medidas como a la rentabilidad medida por los ingresos de explotación, rentabilidad sobre el capital empleado o sobre el valor económico añadido. Objetivos desde esta perspectiva podrían ser un aumento de las ventas o la generación de flujo de caja. Responde a la pregunta: ¿Qué indicadores tienen que ir bien para que los esfuerzos de la empresa realmente se transformen en valor? Esta perspectiva valora uno de los objetivos más relevantes de organizaciones con ánimo de lucro, que es, precisamente, crear valor para la sociedad.

La perspectiva del cliente refleja el posicionamiento de la empresa en el mercado o, más concretamente, en los segmentos de mercado donde quiere competir. Aquí podremos tener medidas como son la satisfacción del cliente, retención y adquisición de nuevos clientes, rentabilidad, cuota de mercado en segmentos especificos, nivel de precios respecto a los competidores. Objetivos de este perspectiva podrían ser mejorar plazos de entregar, desarrollar nuevos productos o anticiparnos a las necesidades de los clientes. La perspectiva de cliente permitira a los gestores de las unidades articular las medidas a nivel de cliente y estrategias mercado para conseguir unos mejores resultados financerios en el futuro.

La perspectiva interna pretende explicar las variables internas consideradas como críticas, así como, definir la cadena de valor generado por los procesos internos de la empresa. Será preciso llevar a cabo el análisis de la innovación de modo que partiendo de la identificación de las necesidades y demandas de los clientes, se desarrollen las soluciones idóneas para su satisfacción. Los procesos operativos, desde la recepción del pedido del cliente hasta la entrega del producto al mismo, vienen controlado por los indicadores de calidad, tiempo de ciclo, costos y análisis de desviaciones. Esta perspectiva finaliza con el servicio postventa que garantiza la adecuada atención y mantenimiento del cliente. La perspectiva interna también afecta a la perspectiva financiera, por su impacto sobre los conceptos de gasto.

La perspectiva de aprendizaje y crecimiento identifica la infraestructura que la organización debe de construir para crear crecimiento y valor a largo plazo. La perspectiva de cliente e interna identifican los valores mas criticos para el exito actual y futuro. Pero no conseguiremos llevarlos a cabo si el uso de las tecnologías y capacidades adecuadas. Los recursos materiales y las personas serán la clave del éxito. Pero sin un modelo de negocio apropiado, muchas veces es difícil apreciar la importancia de invertir, y en épocas de crisis lo primero que se recorta es precisamente la fuente primaria de creación de valor: se recortan inversiones en la mejora y el desarrollo de los recursos.

Permite analizar la capacidad de los trabajadores para llevar a cabo los procesos de mejora continua, la actuación de los sistemas de la información y el clima organizacional que posibilite la motivación, la delegación de responsabilidades, la coordinación del proceso de toma de decisiones y la coherencia interna de los objetivos. La satisfacción de los trabajadores y su fidelización constituyen las premisas indispensables para el incremento de la productividad y la mejora continua del sistema. Las actividades y expectativas del personal han de estar alineadas con los objetivos generales de la empresa, de modo que el logro de las metas personales establecidas para los trabajadores vaya paralela al grado de consecución de la estrategia.

Perspectivas Cuadro Mando Integral

El Balanced Scorecard traslada la vision y estrategia a objetivos y medidas a traves de un conjunto equilibrado de perspectivas. Las cuatro perspectivas se ha demostrado que son suficientes para la mayoria de empresas e industrias. Pero solo hemos de considerar esto como un modelo, no como un patrón rígido. Puede haber compañias que no las utilicen todas u otras que añadan nuevas perspectivas según las características de su negocio u organización (por ejemplo, la perspectiva de los proveedores, de los empleados exclusivamente o de la comunidad, que puede en algunos casos ya estar incluida en las otras perspectivas).

Ademas de incluir una colección de indicadores críticos o factores clave de éxito, ha de ser también como un simulador de vuelo, incorporando el complejo conjunto de relaciones causa-efecto entre las variables más críticas. Pues, al fin y al cabo, una estrategia no es mas que un conjunto de hipotesis sobre causas y efectos. Y el sistema de medida debera establecer las relaciones e hipotesis entre los objetivos y medidas que pueden ser gestionadas y medidas. Esta cadena causa-efecto debera impregnar todos las perspectivas del Cuadro de Mando Integral.

Para permitirnos realizar un seguimiento del cumplimiento de los objetivos, el CMI deberá de incluir un conjunto de medidas e indicadores de rendimiento, que nos indicaran en que medida se esta cumpliendo la estrategia establecida. Ademas, habrá que tener en cuentaq que el CMI es principalmente un mecanismo para implementar o desarrollar estrategias, pero no para formulacion de ellas. Aunque si sera un magnifico mecanismo para traducir la estrategia en objetivos especificos, medidas y objetivos, y como elemento para monitorizar que se esta llevando a cabo correctamente en los periodos futuros. La comparación de los resultados que obtendremos de las medidas con respecto a los objetivos también nos permitirá establecer las acciones de mejora o corrección que habrá que realizar para reconducir o ajustar la situación.

La correcta selección de los indicadores reviste particular importancia, ya que estos han de explicar las razones del éxito o fracaso de la empresa, así como el impacto de las variables analizadas sobre los resultados. Además deben servir de alarma para poner en marcha acciones correctoras inmediatas ante determinados cambios detectados, para ello, los indicadores, han de ser asequibles y de fácil medida.

Medidas de las estrategias de negocio. Construccion del CMI

Las compañias que utilizan los CMI tendrán que realizar dos tareas para implantar un sistema de este tipo en sus organizaciones. Por un lado, habrá que construir el cuadro de mando. En segundo lugar, habrá que hacer uso de el, en lo que sería la fase de seguimiento y control. Las dos fases no son independientes, pues en el momento se comienze a utilizar, se empezara también su rediseño y ajuste, por ejemplo, en las medidas que no funcionen, en las que habrá que modificar o en las que habrá que añadir.

1. Diseño del Cuadro de Mando Integral. Diseño de los objetivos.

La elaboración del Cuadro de Mando Integral se inicia con la correcta planificación de los objetivos estratégicos y la adecuada definición de los factores claves que van a marcar la pauta de actuación y control a medio y largo plazo. Paralelamente debe existir y de hecho suele darse una alineación de los objetivos estratégicos planteados hacia aquel que representaría la máxima aspiración de la empresa. Así dicho objetivo primordial se despliega en abanico a través del planteamiento de otra serie de objetivos prioritarios de segundo rango y que a su vez se correlacionan con los objetivos parciales por departamentos o áreas específicas de actividad.

La elaboración de diagramas de causa-efecto permite en un primer momento enlazar el entramado de objetivos orientados a la meta última y posteriormente desarrollar el sistema de indicadores vinculados a aquellos. El sistema de objetivos debe mostrar en la medida en que sea factible esta vinculación causal de los mismos.

Los objetivos variaran según el estado en el que se encuentre una empresa, pues no es lo mismo una empresa en construcción con productos con gran capacidad de crecimiento (para las que se requeriran grandes inversiones iniciales) que una empresa consolidada en un sector maduro, donde habrá quizas el objetivo de mantener cuota de mercado o aumentarla (con el principal objetivo de la rentabilidad para los accionistas).

Los objetivos mas habituales según la perspectiva pueden ser:

  • Perspectiva financiera: Crecimiento de los ingresos, reducción de costes / mejora de la productividad, Utilización de activos /retorno de inversión y Gestión de riesgos.
  • Perspectiva cliente: Identificación de clientes y de segmentos de mercado, definición de productos y servicios, retención de clientes, captación o satisfación, beneficios del cliente. Imagen y reputación.
  • Perspectiva interna: Identificación de procesos que son mas críticos para la captación de clientes y para cubrir los objetivos, mejoras en la cadena de valor interna (innovación, operaciones, servicio postventa)
  • Perspectiva del aprendizaje y crecimiento: Identificación de inversiones para mejorar la capacidad del personal, sistemas y procesos de la organización, sin considerarlos desde el punto de vista financiero de gasto

2. Diseño del sistema de indicadores.

Una vez que se tienen claros los objetivos de cada perspectiva, es necesario definir los indicadores que se utilizan para realizar su seguimiento. Para ello, debemos tener en cuenta varios criterios: el primero es que el número de indicadores no supere los siete por perspectiva, y si son menos, mejor. La razón es que demasiados indicadores difuminan el mensaje que comunica el CMI y, como resultado, los esfuerzos se dispersan intentando perseguir demasiados objetivos al mismo tiempo. Puede ser recomendable durante el diseño empezar con una lista más extensa de indicadores. Pero es necesario un proceso de síntesis para disponer de toda la fuerza de esta herramienta.

La selección del conjunto de indicadores adoptados a los objetivos estratégicos previamente establecidos constituye un proceso laborioso, ya que el indicador ha de recoger con precisión el contenido del objetivo buscando la relación de causa-efecto entre ambos. Los indicadores, además de medir los resultados obtenidos deben facilitar la búsqueda de causas de ineficiencia y apuntar la orientación a seguir para la resolución de los problemas. Por otra parte, las fuentes de información requerida para su elaboración han de estar disponibles y ser de fácil accesibilidad.

A continuación relacionamos algunos de los indicadores más relevantes en relación con las perspectivas comentadas anteriormente. Los cuadros de mando han de adaptarse al nivel de decisión para el que se diseñan, siendo distinto, como cabe suponer, el de la dirección general de la empresa, que aquel que sirve de soporte decisional para un departamento o área concretos de la entidad. Cada departamento deberá prestar una atención especial a los indicadores que más relacionados están con su actividad. No se debe perder en ningún momento la visión global de la empresa, poniendo de manifiesto como los indicadores más importantes se alinean con la estrategia general de la misma.

Perspectiva Financiera

  • Crecimiento de ventas: porcentajes de crecimiento de ventas o cuota de mercado por regiones, mercados o clientes. Crecimiento por segmentos de producto o por nuevos servicios/productos introducidos en un momento determinado. Porcentaje clientes no rentables.
  • Reducción gastos / mejora de la productividad: ingresos por empleado, costes unitarios, comparación de costes con los competidores, porcentajes de reducción de costes, gastos indirectos, etc.
  • Utilización de activos y capital: ratios de utilización de activos, ratios de generación de capital, retorno de inversión, etc.
  • Tesoreria: ciclo de caja, cash flow, etc.

Perspectiva de los clientes.

  • Cuota de mercado: proporcion de negocio en un mercado especifico (en termino de número de clientes, ingresos o unidades vendidas).
  • Segmentación de mercados.
  • Captación de clientes: medidas, en terminos absolutos o relativos, de los porcentajes de clientes ganados por una determinada unidad de negocio.
  • Satisfacción de los clientes: medida de la satisfacción de los clientes de acuerdo con unos criterios especificos.
  • Retención de los clientes: porcentajes, en terminos absolutos o relativos, de retencion o continuación de las relaciones con los clientes.
  • Rentabilidad por cliente: indicadores de rentabilidad de los clientes (pueden estar referidos a mercados, a segmentos, a clasificación de estos, etc).

Asimismo son relevantes los indicadores relativos a:

  • Los atributos de los productos y servicios: precios, tiempo de entrega, calidad.
  • La relación de los clientes.
  • La imagen y prestigio de la empresa.
  • La creación de valor para el cliente.

Perspectiva de los procesos internos.

  • Innovación e investigación básica o aplicada:  porcentajes de ventas de nuevos productos o de productos propietarios, introducción de nuevos productos con respecto a los competidores, tiempo de desarrollo de nueva generación de productos, etc.
  • Procesos operativos: costes, tiempos de servicio o producción, coste de inventarios, control de calidad (ratios de defectos, ratios de productos correctos en relación a los productos fabricados, devoluciones).
  • Servicio postventa: costes de mantenimiento, porcentajes de averias.

Perspectiva Interna - Modelo de Cadena de Valor

Perspectiva de la formación y crecimiento.

Formación

  • Nivel salarial/ salario medio
  • Grado de calificación del personal
  • Satisfacción de los trabajadores
  • Nivel de ausentismo de los trabajadores
  • Productividad de los trabajadores
  • Nivel de seguridad e higiene en el trabajo (Numero de accidentes laborales)
  • Estabilidad de los trabajadores
  • Competencias de los trabajadores. Formación.
  • Motivación: nivel de sugerencias y mejoras. Medidas de desarrollo de equipos.

Crecimiento

  • Diseños de nuevos productos y mejora de productos
  • Sistema de tratamiento de la información
  • Sistemas de distribución de la información
  • Inversiones en investigación y desarrollo
  • Horas dedicadas a la investigación y desarrollo
  • Resultados de la investigación y desarrollo
  • Porcentaje de nuevos productos lanzados al mercado
  • Acciones de protección al medio ambiente

Explotacion del CMI. El sistema de control (seguimiento).

Un buen sistema de control parte de la correcta definición de los presupuestos vinculados a cada una de las magnitudes previamente definidas como variable objeto de control especifico. La recogida de información ha de llevarse a cabo de forma rápida, sencilla y en tiempo oportuno, de modo que el análisis de las desviaciones y sus causas, así como las posibles acciones correctoras puedan desplegarse de forma eficaz. De igual modo, será preciso establecer un sistema de control de la efectividad de las modificaciones implantadas.

Un sistema integrado de control ha de tomar en consideración los siguientes aspectos:

  • Definición de las variables objeto de análisis en cada área (factores clave e indicadores).
  • Cuantificación de las variables.
  • Comparación de los valores reales obtenidos con las previsiones y objetivos.
  • Análisis de las causas de las desviaciones.
  • Solución de las desviaciones.

El control integrado de gestión, mediante la utilización del cuadro de mando integral, facilita la búsqueda de productos con mayor valor añadido, la consecución de los objetivos de aumento de eficiencia, productividad y rentabilidad, la optimización del rendimiento de los factores y del proceso productivo en su conjunto, la obtención de la calidad total, particularmente en lo relativo a la atención a los clientes, así como la evaluación de la actuación de las personas.

Conclusiones

El cuadro de mando integral no es un documento único, se han de elaborar diferentes cuadros adaptados a cada uno de los departamentos o niveles de decisión de la empresa. El cuadro de mando integral no es un modelo estático, su carácter dinámico se evidencia, cuando al cuestionar la validez de la estrategia actual, surge otra, que puede responder más rápidamente ante las nuevas situaciones que se origina en su entorno. La adopción del CMI se debe apoyar en los sistemas de control de gestión (entre otros, contabilidad y presupuesto) porque por sí solo no podrá promover las modificaciones necesarias para su factibilidad.

La aportación que ha convertido al CMI en una de las herramientas más significativas de los últimos años es que se cimenta en un modelo de negocio. El éxito de su implantación radica en que el equipo de dirección se involucre y dedique tiempo al desarrollo de su propio modelo de negocio.

Cuadro Mando Integral

Beneficios de la implantación de un Cuadro de Mando Integral

  • Define y clarifica la estrategia.
  • Suministra una imagen del futuro mostrando el camino que conduce a él.
  • Comunica la estrategia a toda la organización.
  • Permite alinear los objetivos personales con los departamentales.
  • Facilita la vinculación entre el corto y el largo plazo.
  • Permite formular con claridad y sencillez las variables más importantes objeto de control.
  • Constituye un instrumento de gestión.
  • La fuerza de explicitar un modelo de negocio y traducirlo en indicadores facilita el consenso en toda la empresa.
  • Una vez el CMI está en marcha, se puede utilizar para comunicar los planes de la empresa, aunar los esfuerzos en una sola dirección y evitar la dispersión. En este caso, el CMI actúa como un sistema de control por excepción.
  • Permita detectar de forma automática desviaciones en el plan estratégico u operativo, e incluso indagar en los datos operativos de la compañía hasta descubrir la causa original que dió lugar a esas desviaciones.

Riesgos de la implantación de un Cuadro de Mando Integral:

  • Un modelo poco elaborado y sin la colaboración de la dirección es papel mojado, y el esfuerzo será en vano.
  • Si los indicadores no se escogen con cuidado, el CMI pierde una buena parte de sus virtudes, porque no comunica el mensaje que se quiere transmitir.
  • Cuando la estrategia de la empresa está todavía en evolución, es contraproducente que el CMI se utilice como un sistema de control clásico y por excepción, en lugar de usarlo como una herramienta de aprendizaje.
  • Existe el riesgo de que lo mejor sea enemigo de lo bueno, de que el CMI sea perfecto, pero desfasado e inútil.

Tarjetas de puntuación y Dashboard.

Basandonos en el analisis de aspectos concretos de un area de actividad de la empresa o de un proceso de negocio concreto, podemos hablar de los Cuadros de Mando Operativo (CMO), es una herramienta de control enfocada al seguimiento de variables operativas, es decir, variables pertenecientes a áreas, actividades o departamentos específicos de la empresa. La periodicidad de los CMO puede ser diaria, semanal o mensual, y está centrada en indicadores que generalmente representan procesos, por lo que su implantación y puesta en marcha es más sencilla y rápida. Un CMO debería estar siempre ligado a un DSS (Sistema de Soporte a Decisiones) para indagar en profundidad sobre los datos.

Bajo esta consideración, y centrandonos en ambitos mas concretos, podemos hablar de los tableros de control o Dashboard como los documentos que muestran de una forma unificada los elementos clave de información que los componentes de una organización requieren para la realización de su trabajo de gestión, en un entorno grafico y altamente intuitivo e interactivo. Por ejemplo, un responsable comercial tendra uno o varios tableros de control donde se reflejara la información de ventas por diferentes criterios (geográfico, temporal, rentabilidad). Los tableros de control entran dentro del ambito de las tecnicas de sistemas de Business Intelligence.

Ejemplo de Tablero de Control (Dashboard)

Ademas, los cuadros de mando pueden sacar partido a otros elementos de los sistemas de Business Intelligence, como son los datawarehouse o las funcionalidades Olap. Aunque los Dashboard los podriamos utilizar de forma autonoma, tienen mas sentido en el ambito de una solución de BI. Igualmente, pueden formar parte de la estrategia de Cuadro de Mando Integral (como vimos anteriormente), como herramientas de control y seguimiento de la planificación, como herramienta de reporting o como herramienta de análisis, en el ambito de descubrir tendencias, oportunidades, etc.

Un cuadro de mando puede combinar indicadores de negocio, valores y componentes graficos para ayudar a la gestión o para mejorar el rendimiento de los empleados y encargados de la toma de decisión.

Evolucion de los tableros de control

Las ventajas de unos tableros de control bien construidos son evidentes y obvios, como por ejemplo:

  • Mejora en la toma de decisiones y el rendimiento: facilidad para identificar y corregir tendencias negativas, posibilidad de llevar a cabo análisis no previstos, mejor toma de decisiones basado en la información recogida en un sistema de BI, etc.
  • Mejora en la eficiencia de los empleados: incremento productividad, tiempos de analisis mas reducidos al fusionar varios informes en uno, reducción de tiempos de aprendizaje, reducción de la necesidad de crear nuevos informes.
  • Motivación del empleado: el usuario puede generar nuevos informes siguiendo las nuevas tendencias, es mas agradable trabajar con graficos que con los viejos informes, el usuario utilizara mas tiempo en el analisis y menos en la elaboración de la información. Ademas, pueden ser una herramienta para compartir estrategias, tacticas y datos de los sistemas operacionales que permitan al empleado una mejor comprensión de objetivos y una mejor toma de decisiones.

El uso de los Dashboard se ha hecho cada vez mas popular en las organizaciones y actualmente incluye todos los ambitos de las empresas y organizaciones. Podemos distinguir principalmente tres tipos de dashboard, que serian:

  • Estrategicos: soportan la alineacion organizacional con los objetivos estrategicos de una organización (como vimos en los CMI). Suelen ser informes de alto nivel de agregación que incluyen los indicadores de rendimiento alineados con los objetivos estrategicos de la empresa (por ejemplo, reducción de la devolución de produtos en un 2%, incremento de la retencionde empleados o mejora del flujo de tesoreria).
  • Tacticos: soportan la medida del progreso de un proyecto o iniciativa en concreto. Nos permitiran realizar el seguimiento de estos proyectos o la validación de cumpliento de iniciativas en concreto con respecto a un objetivo. Los utilizaran normalmente los ejecutivos de nivel alto o medio (por ejemplo, seguimiento del proyecto de implantación de un nuevo sistema de control de calidad, incremento de las ventas en la zona X un 20% a traves de medidas promocionales, etc).
  • Operacionales: soportan la monitorización de actividades de negocio especificas. Son normalmente los utilizados por los mandos intermedios o por los gestores departamentales. Se suelen usan con frecuencia para el trabajo diario y cotidiano dentro del ambito establecido (por ejemplo, ventas por departamento y mes con comparativa con el mes anterior, tablas de satisfacción de empleados, numero de llamadas gestionadas por el call center en el periodo, etc).

En la siguiente entrada del blog veremos la forma de construir nuestras tarjetas de puntuación o tableros de control (Dashboard) utilizando Microstrategy, en concreto utilizando los documentos de Report Services.

Cuadro de mando con Microstrategy

Bibliografía:

The balance scorecard: translating strategy into action.

Kaplan, Robert S.   Norton, David P.
ISBN: 978-0-87584-65 1-3

Monografia: El cuadro de mando integral como herramienta de Gestión.

Martinez Fernandez, Francisco (link a la publicación).

Business dashboards : a visual catalog for design and deployment.

Rasmussen, Nils   Chen, Claire   Bansal, Manish
ISBN 978-0-470-41347-0

Posted in Business Intelligence, Formacion | Leave a Comment »

 
A %d blogueros les gusta esto: