BI - Business Intelligence -

Jaspersoft

2009-05-27T13:29:00.002+02:00

Jaspersoft:

JasperSoft Business Intelligence Suite (de JasperSoft Corporation), es la denominación del conjunto de herramientas que permiten a las organizaciones generar información basada en sus propios datos de gestión para la evaluación y toma diaria de decisiones, en forma dinámica y on-line.

El framework de trabajo de JasperSoft permite integrar fácilmente las diversas fuentes de datos disponibles en la empresa, y por medio de técnicas de análisis multidimensional obtener indicadores que, presentados en tableros de control y reportes dinámicos, proveen de esta sensible información a la alta gerencia.
La Suite de productos Jasper BI se compone de:

Jasper Reports: JAsper reports para el diseño y presentacion de informes y dashboards que configuran cuadros de mando con indicadores requeridos por el Management de la organizacion:

Caracteristicas:

Es la libreria base del proyecto

Es el motor que ejecuta los reportes

Ampliamente usado en el mundo opensource

Integrable en aplicaciones desktop y web java

Gran funcionalidad y estabilidad

JasperServer: Jasperserver configurado como contenedor de aplicaciones stand-alone que contiene todos los elementos descritos anteriormente sumando las capacidades de seguridad y accesibilidad de recursos.

Caracterisiticas:

Es el servidor de reportes de la suite

Puede ser usando stand-alone o desde otras aplicaciones.

Provee el punto de ingreso para los reportes y analisis de datos

Interfaz de usuario muy sencilla de usar y personalizable

En el se pueden ejecutat, programar y distribuir los reportes a usuarios y grupos

Puede alamacenar los reportes emitidos

Administra los recursos compartidos.

Jasper ETL:

JAsper ETL se usa para la seleccion y procesamiento de multiples fuentes de datos que configuran y alimentan datawarehouse corporativos.

Caracteristicas:

Herramienta ETL basada en el IDE Eclipse

Entorno grafico drag &Drop

Genera codigo java para las transformaciones

Posee multiples fuentes de datos

JasperAnalysis :

JasperA nalysis se usa para el diseño y soporte de cubos OLAP que complementan la estructurade los caudros de mando brindando herramientas de investigacion y analisis de la informacion en forma online.

Carateristicas:

Es la aplicacion de usuario y servidor ROLAP.

Permite a los usuarios la exploracion de datos mucho mas alla de las capacidades de reportes habituales

El servidor realiza todo el trabajo pesado, de esta forma la capa de presentacion es muy liviana.

Se puede vincular con reportes, tanto como origen o destino de los mismos

Cuenta con un modelo dual de versiones:

1. Versión open source (Community Edition) bajo licencia GPL
2. Versiones comerciales (Professional Edition y Professional Edition OEM) para uso de negocios interno y para embeber en terceras aplicaciones

¿Cuándo usar la versión profesional?

- Versión PRO OEM para insertar los componentes en una aplicación a ser revendida (que no esté obligada a licencia GPL).
- Necesidad de plataforma certificada especialmente con SO o DB propietarias.
- Esquema de versiones planificado.
- Protección legal contra eventuales demandas.
- Soporte técnico extendido para viejas versiones.
- Requerimientos de funcionalidad avanzada.

Introducción a JasperReports

JasperReports es la mejor herramienta de código libre en Java para generar reportes. Puede entregar ricas presentaciones o diseños en la pantalla, para la impresora o para archivos en formato PDF, HTML, RTF, XLS, CSV y XML.

Está completamente escrita en Java y se puede utilizar en una gran variedad de aplicaciones de Java, incluyendo J2EE o aplicaciones Web, para generar contenido dinámico.

Requerimientos de JasperReports

· Se requiere tener instalado en el equipo el JDK 1.4 (SDK) o posterior. No basta con tener instalado el J2RE (Run Time Environment).

· Las siguientes librerías junto con la de JasperReports deben incluirse en el proyecto en que se desee incluir esta herramienta para generar reportes.

· Driver JDBC 2.0 (Usualmente incluido en el SDK)

· PDF. Librería libre Java-PDF iText por Bruno Lowagie y Paulo Soares

· XLS

Funcionamiento de JasperReports

JasperReports trabaja en forma similar a un compilador y a un intérprete, ver figura 1. El usuario diseña el reporte codificándolo en XML de acuerdo a las etiquetas y atributos definidos en un archivo llamado jasperreports.dtd (parte de JasperReports). Usando XML el usuario define completamente el reporte, describiendo donde colocar texto, imágenes, líneas, rectángulos, cómo adquirir los datos, como realizar ciertos cálculos para mostrar totales, etc.

Este archivo fuente XML debe ser compilado para obtener un reporte real. La versión compilada del fuente es nombrada "archivo jasper" (este termina con .jasper). Un Archivo jasper es el compilado de un código fuente. Cuando tenemos un archivo jasper, necesitamos otra cosa para producir un reporte: necesitamos datos. Esto no siempre es cierto. En algunos casos querríamos generar un reporte que no mostrara datos dinámicos, solo texto estático por ejemplo, pero esto puede simplificarse a un reporte que tiene solamente un registro vacío. Para proporcionar estos registros al “jasper engine” necesitamos presentarlos usando una interfaz especial específica llamada JRDataSource. Una fuente de datos + un Archivo jasper = un “archivo print”. Un “archivo print” puede exportarse en muchos formatos como PDF, HTML, RTF, XML, XLS, CVS, etc. La exportación se puede realizar utilizando clases especiales para implementar exportadores específicos.

Compilación, exportación de reportes de JasperReports

Para un novato, diseñar y crear el archivo jasper es la tarea mas dura. Cuando se haya diseñado y compilado el archivo jasper, se puede utilizar la librería JasperReports para llenar dinámicamente el reporte en varios entornos como una aplicación web (Usando un servlet de Java por ejemplo, pero también funciona para generar reportes PDF desde un script PHP).

Jasper tiene disponible un visualizador especial para desplegar la vista previa de un reporte; diseñado para aplicaciones tradicionales de Java basadas en Swing.

iReport

iReport es un diseñador visual de código libre para JasperReports escrito en Java. Es un programa que ayuda a los usuarios y desarrolladores que usan la librería JasperReports para diseñar reportes visualmente. A través de una interfaz rica y simple de usar, iReport provee las funciones más importantes para crear reportes amenos en poco tiempo.

iReport puede ayudar a la gente que no conoce la sintaxis XML para generar reportes de JasperReports.

Funcionamiento de iReport

iReport provee a los usuarios de JasperReports una interfaz visual para construir reportes, generar archivos “jasper” y “print” de prueba. iReport nació como una herramienta de desarrollo, pero puede utilizarse como una herramienta de oficina para adquirir datos almacenados en una base de datos, sin pasar a través de alguna otra aplicación.

iReport puede leer y modificar ambos tipos de archivo, XML y jasper. A través de JasperReports, es capaz de compilar XML a archivos jasper y “ejecutar reportes” para llenarlos usando varios tipos de fuentes de datos (JRDataSource) y exportar el resultado a PDF, HTML, XLS, CSV,…

Requerimientos de instalación (Windows 2000, NT, XP)

· Sun JDK 1.4 (SDK) o superior.

· Acrobat 5.0 no es requerido, pero es fuertemente recomendado.

· Si se desea conectar con una base de datos, se debe proporcionar el Driver JDBC correspondiente.

Instalación y configuración ((Windows 2000, NT, XP))

Si tiene instalado en su equipo un jdk (sdk) y no simplemente un j2re, está listo para iniciar la instalación.

1. Descomprima iReport-x.x.x.zip y copie el directorio extraído al lugar que desee (C:iReport-x.x.x por ejemplo)

2. Busque un archivo llamado tools.jar en su jdk y cópielo en el directorio lib de iReport. (C:iReport-x.x.xlib)

3. Ejecute iReport.bat o iReport.sh.

Después de ejecutarse por primera vez, iReport creará un directorio (.ireport) en su directorio principal (home). Aquí se almacenarán todos los archivos de configuración en formato XML.

Proceda a configurar iReport con los siguientes pasos:

1. Vaya a menu->tools->options.

2. Vaya a la pestaña de Programas externos (external programs).

3. Configure los programas visualizadores externos.

4. En la pestaña General puede configurar el idioma

Pruebe si la configuración fue correcta. Cree un nuevo reporte en blanco, haga clic en el botón ejecutar sin conexión (run without connection).

Después de unos segundos aparecerá el reporte con el programa que se haya seleccionado para visualizarse.

¿Qué necesito descargar?

Este es el resumen de las librerías que debe descargar:

· JasperReports

o jasperreports-1.0.1.jar

o commons-digester.jar

o commons-beanutils.jar

o commons-collections.jar

o commons-logging.jar

o itext-1.02b.jar

o poi-2.0-final-20040126.jar

· iReport

o iReport-0.5.1 (versión 0.5.1)

Recuerde que es necesario tener instalado el Jdk 1.4 o superior, no basta con tener instalado el J2RE.

Fuente: Jaspersoft

Pentaho

2009-04-28T14:27:00.002+02:00

El proyecto Pentaho BI es una iniciativa en curso de la comunidad open source que provee a las organizaciones de las mejores soluciones de su clase para sus necesidades de inteligencia de negocios. Al aprovechar la riqueza de las tecnologías de código abierto y las contribuciones de la comunidad de desarrollo de código abierto, Pentaho es capaz de innovar mucho más rápido que los proveedores comerciales. Como resultado, Pentaho ofrece una alternativa de código abierto que supera a las soluciones de Business Intelligence propietarias en muchas áreas como arquitectura, soporte de estándares, funcionalidad y simplicidad de implantación. En otras palabras, no se espera que la gente la adopte sólo porque es de código abierto, se espera que la gente la escogerá porque es superior.
La solución Business Intelligence OpenSource Pentaho pretende ser una alternativa a las soluciones propietarias tradicionales más completas: Business Objects, Cognos, Microstrategy, Microsoft, etc… por lo que incluye todos aquellos componentes que nos podemos encontrar en las soluciones BI propietarias más avanzadas:

ETL: Kettle: Pentaho Data Integration
Se trata de la más reciente adquisición.

Kettle es un proyecto belga que incluye un conjunto de herramientas para realizar ETL(Extraccion, transformación y carga de datos). Uno de sus objetivos es que el proyecto ETL sea fácil de generar, mantener y desplegar.
Con Kettle (pentaho data integration) podemos realizar diversas tareas, entre ellas cabe resaltar:
• Soporte para cambiar, enlazar dimensiones y otras operaciones en el data warehouse.
• Exportar de bases de datos a ficheros u otras bases de datos.
• Importar en bases de datos ficheros en formato Excel o texto.
• Migración de datos entre diferentes bases de datos.
• Explotación de los datos existentes en bases de datos (tablas, vistas, sinónimos,…)
• Enriquecer la información mediante búsqueda de datos en diferentes almacenes de información (bases de datos, ficheros de texto, hojas Excel,…)
• Limpieza de datos aplicando transformaciones de datos con condiciones complejas.
• Integración de aplicaciones.
Transformacion: (sirve para mover, copiar, transformar datos, filas entre una fuente y un destino)
Trabajo: Coordinacion de Transformaciones, secuencialidad y paralelismo (Control de flujo, ejecutar transformaciones, enviar correos en caso de error,…)

Se compone de 4 herramientas:
- SPOON: permite diseñar de forma gráfica la transformación ETL.
- PAN ejecuta la transformaciones diseñadas con SPOON.
- CHEF permite, mediante una interfaz gráfica, diseñar la carga de datos incluyendo un control de estado de los trabajos.
- KITCHEN permite ejecutar los trabajos batch diseñados con Chef.

Reporting

La mayoría de las organizaciones utilizan reportes para registrar y visualizar análisis y resultados. Como consecuencia, los reportes son considerados una necesidad principal en Inteligencia de Negocio (IN). La unidad de reportes de Pentaho (Pentaho Reporting) permite a las organizaciones acceder, dar formato y distribuir fácilmente la información a empleados, clientes y asociados. Pentaho provee acceso a fuentes de datos relacionales, OLAP o basadas en XML, además de ofrecer varios formatos de salida como PDF, HTML, Excel o hasta texto plano. También permite llevar esta información a los usuarios finales vía web, e-mail, portales corporativos o aplicaciones propias.
Pentaho Reporting permite ir incrementando la plataforma de reportes a medida que las necesidades crecen.

El Pentaho Report Designer es una herramienta independiente que forma parte de la unidad de reportes de Pentaho (Pentaho Reporting), que simplifica el proceso de generación de reportes, permitiendo a los diseñadores de reportes crear rápidamente informes sofisticados y ricos visualmente basados en el proyecto de reportes de Pentaho JFreeReport.
El diseñador de reportes ofrece un entorno gráfico familiar, con herramientas intuitivas y fáciles de utilizar, y una estructura de reporte bastante acertada y flexible para darle libertad al diseñador de generar reportes que se adapten totalmente a su gusto y necesidad.

PENTAHO REPORT DESIGN WIZARD
El asistente de reportes de Pentaho Report Designer es una herramienta muy útil, que agiliza enormemente la creación de reportes a los usuarios.
Nos va guiando paso a paso por todas las etapas. Selección de plantillas, fuentes de datos, agrupaciones, publicación,…

Web ad-hoc reporting:
Es el similar a la herramienta anterior pero via web. Extiende la capacidad de los usuarios finales para la creación de informes a partir de plantillas preconfiguradas y siguiendo un asistente de creación. Esta incluido dentro del BI Plattform, la ventaja que tiene es que puede publicar el informe directamente, aunque cuenta como desventaja que no accede directamente a las fuentes de datos, sino que se apoya en metadato que hay que crear previamente.

Las características generales son:
• Proporciona funcionalidad crítica para usuarios finales como:
o Acceso vía web
o Informes parametrizados
o Scheduling
o Suscripciones
o Distribucíon (bursting)
• Proporciona claras ventajas a especialistas en informes:
o Acceso a fuentes de datos heterogeneos: relacional (vía jdbc), OLAP, XML.
o Capacidad de integración en aplicaciones o portales: jsp, portlet, web service.
o Definición modular de informes (distinción entre presentación y consulta)
• Diseño de informes flexible
o Entorno de diseño gráfico
o Capacidad de uso de templates
o Acceso a datos relacionaes, OLAP y XML
• Desarrollado para:
o Ser embebible
o Ser fácil de extender
o No consumir muchos recursos
o 100% Java: portabilidad, escalabilidad e integración
• Multiplataforma (tanto a nivel de cliente como servidor): mac, linux/unix y Windows

Analisys – Mondrian

OLAP es el acrónimo en inglés de procesamiento analítico en línea (On-Line Analytical Processing). Es una solución utilizada en el campo de la llamada Inteligencia empresarial (o Business Intelligence) cuyo objetivo es agilizar la consulta de grandes cantidades de datos. Para ello utiliza estructuras multidimensionales (o Cubos OLAP) que contienen datos resumidos de grandes Bases de datos o Sistemas Transaccionales (OLTP). Se usa en informes de negocios de ventas, marketing, informes de dirección, minería de datos y áreas similares.
La razón de usar OLAP para las consultas es la velocidad de respuesta. Una base de datos relacional almacena entidades en tablas discretas si han sido normalizadas. Esta estructura es buena en un sistema OLTP pero para las complejas consultas multitabla es relativamente lenta. Un modelo mejor para búsquedas, aunque peor desde el punto de vista operativo, es una base de datos multidimensional.
Para obtener la funcionalidad de procesamiento analítico en línea (OLAP) se utilizan otras dos aplicaciones: el servidor OLAP Mondrian, que combinado con Jpivot, permiten realizar querys a Datamarts, que los resultados sean presentados mediante un browser y que el usuario pueda realizar drill down y el resto de las navegaciones típicas.
Mondrian, ahora rebautizado como Pentaho Analysis Services, es el motor OLAP integrado en la suite de Business Intelligence Open Source Pentaho.
Mondrian es un motor ROLAP con caché, lo cual lo sitúa cerca del concepto de Hybrid OLAP.
ROLAP significa que en mondrian no residen datos (salvo en la caché)
sino que estos residen en una Sistema de Gestion de Bases de Datos externo.
Es en esta base de datos en la que residen las tablas que conforman la
información multidimensional con la que mondrian trabaja (los modelos en
estrella de nuestros data marts por ejemplo). MOLAP es el nombre que
reciben los motores olap en los que los datos residen en una estructura
dimensonal.
Mondrian se encarga de recibir consultas dimensionales (lenguaje MDX)
y devolver los datos de un cubo, sólo que este cubo no es algo físico sino un
conjunto de metadatos que definen como se han de “mapear” estas consultas
que tratan conceptos dimensionales a sentencias SQL ya tratando con conceptos relacionales que obtengan de la base de datos la información necesario para satisfacer la consulta dimensional.
Algunas de las ventajas de este modelo son:
- El no tener que generar cubos estáticos ahorrando que cuesta generarlos y la memoria que ocupan
- La posibilidad de utilizar siempre los datos residentes en la base de datos, de forma que se trabaja con datos actualizados. Muy útil en entorno de BI operacional.
- Pese a que tradicionalmente los sistemas MOLAP tienen una cierta ventaja de rendimiento, la aproximación híbrida de Mondrian, el uso de caché y de tablas agregadas, hace que se puedan obtener muy buenos rendimientos con él, sin perder las ventajas del modelo ROLAP clásico. Es muy importante aprovechar bien las ventajas de la base de datos donde residen las tablas.

Pentaho Análisis suministra a los usuarios un sistema avanzado de análisis de información. Con uso de las tablas dinámicas (pivot tables, crosstabs), generadas por Mondrian y JPivot, el usuario puede navegar por los datos, ajustando la visión de los datos, los filtros de visualización, añadiendo o quitando los campos de agregación. Los datos pueden ser representados en una forma de SVG o Flash, los dashboards widgets, o también integrados con los sistemas de mineria de datos y los portales web (portlets). Además, con el Microsoft Excel Analysis Services, se puede analizar los datos dinámicos en Microsoft Excel (usando la conexión a OLAP server Mondrian).

Algunas cuestiones interesantes sobre Mondrian:
- Mondrian utiliza MDX como lenguaje de consulta, que no tendría nada de raro si no fuera porque fue un lenguaje propuesto por Microsoft.
- En noviembre de 2005 Mondrian se incorporó al proyecto Pentaho
- Mondrian funciona sobre las bases de datos estándar del mercado: Oracle, DB2, SQL-Server, MySQL... lo cual habilita y facilita el desarrollo de negocio basado en la plataforma Pentaho.
- JPivot está considerado con un “proyecto hermano” de Mondrian.
Al incorporarse Mondrian a Pentaho también lo ha hecho JPivot

Data Mining – Weka

La minería de datos (DM, Data Mining) consiste en la extracción no trivial de información que reside de manera implícita en los datos. Dicha información era previamente desconocida y podrá resultar útil para algún proceso. En otras palabras, la minería de datos prepara, sondea y explora los datos para sacar la información oculta en ellos.
Bajo el nombre de minería de datos se engloba todo un conjunto de técnicas encaminadas a la extracción de conocimiento procesable, implícito en las bases de datos. Está fuertemente ligado con la supervisión de procesos industriales ya que resulta muy útil para aprovechar los datos almacenados en las bases de datos.
Las bases de la minería de datos se encuentran en la inteligencia artificial y en el análisis estadístico. Mediante los modelos extraídos utilizando técnicas de minería de datos se aborda la solución a problemas de predicción, clasificación y segmentación.
Por supuesto, qué sería de una aplicación de BI sin Data Mining. Para tal fin, Pentaho incorporo la tecnología WeKa.
Weka es una herramienta extensible e integrable que incluye herramientas para realizar transformaciones sobre los datos, tareas de clasificación, regresión, clustering, asociación y visualización.
El paquete Weka contiene una colección de herramientas de visualización y algoritmos para análisis de datos y modelado predictivo, unidos a una interfaz gráfica de usuario para acceder fácilmente a sus funcionalidades. La versión original de Weka fue un front-end en TCL/TK para modelar algoritmos implementados en otros lenguajes de programación, más unas utilidades para preprocesamiento de datos desarrolladas en C para hacer experimentos de aprendizaje automático. Esta versión original se diseñó inicialmente como herramienta para analizar datos procedentes del dominio de la agricultura pero la versión más reciente basada en Java (WEKA 3), que empezó a desarrollarse en 1997, se utiliza en muchas y muy diferentes áreas, en particular con finalidades docentes y de investigación.

Razones a favor de Weka
Los puntos fuertes de Weka son:
• Está disponible libremente bajo la licencia pública general de GNU.
• Es muy portable porque está completamente implementado en Java y puede correr en casi cualquier plataforma.
• Contiene una extensa colección de técnicas para preprocesamiento de datos y modelado.
• Es fácil de utilizar por un principiante gracias a su interfaz gráfica de usuario.
Weka soporta varias tareas estándar de minería de datos, especialmente, preprocesamiento de datos, clustering, clasificación, regresión, visualización, y selección. Todas las técnicas de Weka se fundamentan en la asunción de que los datos están disponibles en un fichero plano (flat file) o una relación, en la que cada registro de datos está descrito por un número fijo de atributos (normalmente numéricos o nominales, aunque también se soportan otros tipos). Weka también proporciona acceso a bases de datos vía SQL gracias a la conexión JDBC (Java Database Connectivity) y puede procesar el resultado devuelto por una consulta hecha a la base de datos. No puede realizar minería de datos multi-relacional, pero existen aplicaciones que pueden convertir una colección de tablas relacionadas de una base de datos en una única tabla que ya puede ser procesada con Weka
Carencias de Weka
Un área importante que actualmente no cubren los algoritmos incluidos en Weka es el modelado de secuencias.

Cuadros de Mando

Estos paneles están formados por una serie de controles gráficos que permiten mostrar de forma rápida e intuitiva los marcadores principales del rendimiento del negocio de forma que en una pantalla podemos obtener medidas sobre el funcionamiento de la empresa. Actualmente no hay mucho soporte para la implementación de estos controles así que hay que hacer mucho trabajo a mano, pero en breve se esperan una serie de asistentes que permitan desarrollarlos de forma visual igual que el resto de las aplicaciones Pentaho
Los dashboards son un desarrollo propio de Pentaho. Recogen información de todos los componentes de la plataforma incluyendo aplicaciones externas, feeds RSS y páginas web. Incluyen gestión y filtrado del contenido, seguridad basada en roles y drill down. Pueden ser integrados en terceras aplicaciones, en portales o dentro de la plataforma Pentaho.
Para generar gráficos se apoyan en JFreeChart, una librería para generar los gráficos más comunes (2D, 3D, barras, líneas series temporales, Gantt...), interfaces para acceder a diferentes fuentes de datos, exportación a PNG, JPEG y PDF y soporte para servlets, JSPs, applets y aplicaciones clientes.

Todos los componentes del modulo Pentaho Reporting y Pentaho Análisis pueden formar parte de un Dashboard. En Pentaho Dashboards es muy fácil incorporar una gran variedad en tipos de gráficos, tablas y velocímetros (dashboard widgets) e integrarlos con los Portlets JSP, en donde podrá visualizar informes, gráficos y análisis OLAP.

Plataforma BI

La plataforma de Pentaho BI provee de servicion criticos incluyendo programación, seguridad, integración automatización y flujo de trabajo. Proporcionando habilidades a los usuarios finales de Pentaho y proveindo un lugar central para administrar y mantener el despliegue de la empresa BI.
• Integración con procesos de negocio
• Administra y programa reportes
• Administra seguridad de usuarios
PENTAHO BI OpenSource nos promete una gama de beneficios alentadores, haciendo mayor relieve en el costo, en la definición de estándares abiertos, en su flexibilidad, en sus funciones personalizadas y sobre todo en su arquitectura centrada en procesos, haciendo que las necesidades de la Inteligencia de Negocio sean atendidas con mayor facilidad.
Los WebServices son una característica fundamental de Pentaho. Las acciones, que son las tareas más sencillas y que constituyen una solución de Pentaho, pueden publicarse como WebServices. Pentaho utiliza como motor de WebServices Apache Axis, quedando los servicios descritos en el lenguaje de definición de servicios web WSDL.
Para entregar la información Pentaho se apoya en una infraestructura JMS para enviar correos electrónicos y Quartz, un scheduler opensource integrable en aplicaciones J2EE (de hecho necesita ser instanciado). También está anunciado un feed RSS propio, para posicionarse en el desktop.
El workflow de procesos de negocio
Pentaho es una herramienta de análisis integrado con un motor workflow de procesos de negocio capaz de generar informes en varios formatos.
Dos son los fundamentos del workflow de procesos de negocio: el motor de workflow Enhydra Shark y el estándar WPDL, auspiciado por la WorkFlow Management Coalition (WFMC), organismo que declara tener más de 300 empresas asociadas, incluyendo a las desconocidas IBM, Oracle, BEA, Adobe, SAP, TIBCO o SUN, por citar algunas de ellas. Dentro del proyecto Enhydra podemos encontrar también Enhydra JaWE, un editor de workflow XPDL, según las especificaciones de WfMC.
Componentes:
• Plataforma 100% J2EE, asegurando la escalabilidad, integración y portabilidad.
• Servidor: puede correr en servidores compatibles con J2EE como JBOSS AS, WebSphere, Tomcat, WebLogic y Oracle AS.
• Base de datos: vía JDBC, IBM DB2, Microsoft SQL Server, MySQL, Oracle, PostgreSQL, NCR Teradata, Firebird.
• Sistema operativo: no hay dependencia. Lenguaje interpretado.
• Lenguaje de programación: Java, Javascript, JSP, XSL (XSLT/XPath/XSL-FO).
• Interfaz de desarrollo: Java SWT, Eclipse, Web-based.
• Repositorio de datos basado en XML.
• Todos los componentes están expuestos vía Web Services para facilitar la integración con Arquitecturas Orientadas a Servicios (SOA).

Arquitectura

La personalización del despliegue de la plataforma Pentaho permite formar una arquitectura empotrada y solo manejable en componentes, motores, repositorios que se requiera de una configuración como:
• Motores de flujo de actividades, repositorios de flujos y repositorios de “runtime”
• Repositorios de Auditar
• Aplicaciones de integración
• Componentes de la interface del usuario
• Repositorio de soluciones y archivos de definición de soluciones

Pentaho está construído en torno al servidor de aplicaciones J2EE JBoss y Jboss Portal

Pentaho Data Integration, Pentaho Design Reporting, Weka, Mondrian Son herramientas que perfectamente pueden utilizarse por separado y de forma totalmente independiente de Pentaho, tanto esa asi que Pentaho data integration y Weka no están integradas en la BI platform

Los 9 errores fatales en implementaciones de Business Intelligence de acuerdo con Gartner

2009-03-10T11:54:00.003+01:00

Gartner, la mayoría de los errores vinculados con implementaciones de Business Intelligence giran alrededor de las personas y los procesos, más que en la tecnología.

A continuacion os trascribo el texto.

Gartner Reveals Nine Fatal Flaws in Business Intelligence Implementations

Problems Tend to be People and Processes, Not Technology

Egham, UK, October 10, 2008 —

Most failed business intelligence (BI) efforts suffer from one or more of nine fatal flaws, generally revolving around people and processes rather than technology, according to Gartner, Inc.

“Despite years of investing in BI, many IT organisations have difficulty connecting BI with the business, and to get business users fully involved and out of the ‘Excel culture’,” said Bill Hostmann, vice president and distinguished analyst at Gartner. “Just one common mistake can destroy a BI programme, and there is far more risk in nontechnology issues — sponsorship, politics, data quality and so on — than in deploying the infrastructure, tools and applications that support BI. Forewarned is forearmed, so organisations must understand the common flaws that undermine BI projects and prepare an approach to avoid or minimise them.”

Gartner said the failure to achieve strategic results usually stems from one or more of nine common mistakes:

Flaw No. 1: Believing that "If you build it, they will come"
Often the IT organisation sponsors, funds and leads its BI initiatives from a technical, data-centric perspective. The danger with this approach is that its value is not obvious to the business, and so all the hard work does not result in massive adoption by business users — with the worst case being that more staff are involved in building a data warehouse than use it regularly. Gartner recommends that the project team include significant representation from the business side. In addition, organisations should establish a BI competency centre (BICC) to drive adoption of BI in the business, as well as to gather the business, technology and communication skills required for successful BI initiatives.

Flaw No. 2: Managers "dancing with the numbers
Many companies are locked into an "Excel culture" in which users extract data from internal systems, load it to spreadsheets and perform their own calculations without sharing them companywide. The result of these multiple, competing frames of reference is confusion and even risk from unmanaged and unsecured data held locally by individuals on their PCs. BI project instigators should seek business sponsors who believe in a transparent, fact-based approach to management and have the strength to cut through political barriers and change culture.

Flaw No. 3: "Data quality problem? What data quality problem?"
Data quality issues are almost ubiquitous and the impact on BI is significant — people won’t use BI applications that are founded on irrelevant, incomplete or questionable data. To avoid this, firms should establish a process or set of automated controls to identify data quality issues in incoming data and block low-quality data from entering the data warehouse or BI platform.

Flaw No. 4: "Evaluate other BI platforms? Why bother?"
"One-stop shopping," or buying a BI platform from the standard corporate resource application vendor doesn't necessarily lower the total cost of ownership or deliver the best fit for an organisation’s needs. BI platforms are not commodities and all do not yet deliver all functions to the same level, so organisations should evaluate competitive offerings, rather than blindly taking the path of least resistance. Integration between the application vendor's ERP/data warehouse and BI offerings is not a compelling reason for ignoring alternatives, especially as many third-party BI platforms are as well integrated.

Flaw No. 5: "It's perfect as it is. Don't ever change ..."
Many organisations treat BI as a series of discrete (often departmental) projects, focused on delivering a fixed set of requirements. However, BI is a moving target — during the first year of any BI implementation, users typically request changes to suit their needs better or to improve underlying business processes. These changes can affect 35 per cent to 50 per cent of the application's functions. Organisations should therefore define a review process that manages obsolescence and replacement within the BI portfolio.

Flaw No. 6: "Let's just outsource the whole darn BI thing"
Managers often try to fix struggling BI efforts by hiring an outsourcer that they expect will do a better job at a lower cost. Focusing too much on costs and development time often results in inflexible, poorly architected systems. Organisations should outsource only what is not a core competency or business and rely on outsourcing only temporarily while they build skills within their own IT organisation.

Flaw No. 7: "Just give me a dashboard. Now!"
Many companies press their IT organisations to buy or build dashboards quickly and with a small budget. Managers don't want to fund expensive BI tools or information management initiatives that they perceive as lengthy and risky. Many of the dashboards delivered are of very little value because they are silo-specific and not founded on a connection to corporate objectives. Gartner recommends that IT organisations make reports as pictorial as possible — for example, by including charting and visualisation — to forestall demands for dashboards, while including dashboarding and more-complex visualisation tools in the BI adoption strategy.

Flaw No. 8: "X + Y = Z, doesn't it?"<> A BI initiative aims to create a "single version of the truth," but many organisations haven't even agreed on the definition of fundamentals, such as "revenue." Achieving one version of the truth requires cross-departmental agreement on how business entities (customers, products, key performance indicators, metrics and so on) are defined. Many organisations end up creating siloed BI implementations that perpetuate the disparate definitions of their current systems. IT organisations should start with their current master data definitions and performance metrics to ensure that BI initiatives have some consistency with existing vocabulary, and publicise these "standards."

Flaw No. 9: “BI strategy? No thanks, we’ll just follow our noses”
The final and biggest flaw is the lack of a documented BI strategy, or the use of a poorly developed or implemented one. Gartner recommends creating a team tasked with writing or revising a BI strategy document, with members drawn from the IT organisation and the business, under the auspices of a BICC or similar entity.

“Simple departmental BI projects that pay an immediate return on investment can mean narrow projects that don't adapt to changing requirements and that hinder the creation of companywide BI strategies,” said James Richardson, research director at Gartner. “Business users must take a leadership role in the BI initiative — only with their full engagement will investment in BI ever realise its potential.”

Additional analysis is available on Gartner’s Web site at Succeed With Business Intelligence by Avoiding Nine Fatal Flaws

Contacts:

Christy Pettey
Gartner
+1 408 468 8312
christy.pettey@gartner.com

Holly Stevens
Gartner
+44 0 1784 267412
holly.stevens@gartner.com

Fuente: Gartner

Qlikview

2009-03-06T10:00:00.002+01:00

Vamos a ver una de las herramientas mas interesantes del panorama BI, rapida implentacion, muy vistoso, facil de manejar y desarrollar, pero como todas las herramientas siempre hay algo en lo que fallan.

¿Qúe es QlikView?
QlikView es una herramienta de Business Intelligence que permite a su organización obtener los conocimientos y el poder analítico de los datos que genera su negocio. Además le permite crear fácilmente un cuadro de mando integral. Los datos se presentan en un agradable y sencillo interfaz gráfico mediante tablas dinámicas, gráficos interactivos, estadísticas e indicadores. También permite la creación de “escenarios virtuales” que ayudan a realizar proyecciones, comparativas y simulaciones. Todo ello en entorno C/S o entorno Web.

¿Cómo se accede a los datos de los Sistemas de Gestión?
En QlikView se importan y enlazan los datos de cualquier BBDD origen (Oracle, AS/400, Sybase, Db2, Informix, xml, mdb, xls, csv) directamente o a través de conexiones ODBC y OLEDB. Estos datos se almacena en una BBDD propietaria que se crea automáticamente y con tecnología AQL (Associative Query Language). QlikView construye un modelo analítico dinámico que no limita las posibilidades en la explotación de la información. Además cuenta con un conector SAP, para facilitar una estructura legible y la explotación de sus datos.

Opciones de Seguridad
Las Aplicaciones QlikView poseen varios niveles de seguridad configurables, tanto para las funcionalidades específicas de la herramienta como a nivel de la información.

Beneficios y Ventajas competitivas de QlikView:
* Rápido ROI
* Escalabilidad
* Implantación rápida
* Personalización
* Seguridad en la toma de decisiones
* Corta curva de aprendizaje
* Flexibilidad
* Fácil uso
* Reduce presión sobre el departamento IT

QlikView es la alternativa más flexible y económica frente a las herramientas convencionales de consultas, datamining, datawarehousing y reporting. Desarrollar en QlikView comprende una serie de ventajas únicas, entre las que destacan la sencillez de uso y la fácil programación.

Los 4 principios del datawarehouse

2009-02-25T09:34:00.002+01:00

La tarea de construir un datawarehouse es comparable a renovar una casa: es difícil estimar tiempos y costos porque surgen problemas inesperados y los requerimientos cambian.

A continuación cuatro puntos a considerar en un proyecto de este tipo o similar:

1. Lleva más tiempo y dinero renovar que construir
Renovar una casa es más costoso que construir desde cero. Detrás de las paredes y techos de una casa se esconden problemas invisibles que sabotean todas las proyecciones. Un datawarehouse significa reconstruir la infraestructura de información de una organización. Los sistemas contienen datos con diversa calidad y otros problemas que no son visibles de inmediato.

2. No confíe en la planeación original del proyecto
Es común que los dueños de la casa cambien los diseños a la mitad de la reparación o agreguen nuevas tareas al proyecto, lo que provoca que éste se alargue en tiempo y presupuesto. Los administradores inteligentes de proyectos de datawarehousing saben que los problemas y los cambios son inevitables, y planean tomando eso en cuenta. Se alejan de los proyectos complejos y riesgosos y escalan sus proyectos a través de incrementos manejables.

3. Obtiene lo que paga
Muchos dueños de casas toman la propuesta más económica. El adagio "Usted obtiene lo que paga" es cierto con proyectos de datawarehouse. Si no pone buenos cimientos de infraestructura, el datawarehouse fallará al encontrar nuevas y cambiantes necesidades de negocio. Pronto, no podrá escalar el sistema y no funcionará y no contendrá información consistente.

4. Asumir sin analizar mata los proyectos
La mayoría de los proyectos de renovación están muertos antes de iniciar. Lo que sucede es que ambas partes asumen diferentes cosas

cerca de las responsabilidades de este último. Los proyectos de datawarehousing son también sujetos a problemas causados por expectativas incorrectas y asunciones equivocadas. Debido al trabajo meticuloso para dar información integrada y de alta calidad, los incrementos iniciales de un datawarehouse siempre se quedan cortos de las expectativas de la gente de negocios. Para evitarlo se debe formalizar una estructura en que el negocio conduzca el proyecto.

Business intelligence
Business intelligence implica mejorar la velocidad y capacidad de las organizaciones para tomar decisiones, simplificando e integrando servicios en la misma plataforma, y proporcionando interfaces abiertas para acceder y compartir datos, dentro de la misma organización o con otras organizaciones externas.

Datawarehouse:

Los Sistemas de Información mantienen la información necesaria para la actividad diaria de la organización. La importancia de esta información de tipo transaccional reside no sólo en que permite la actividad diaria, sino también en que de ella se pueden deducir mediante análisis conclusiones de gran valor para la organización.

Cada directivo o analista puede "preguntar y analizar lo que quiera, cuando quiera y como quiera", sin la mediación del personal informático de la empresa, por lo que dedica su tiempo al análisis y extracción de valor añadido de la información.

Filosofía datawarehouse
"El DWH es una colección de datos
orientados al tema, integrados, no volátiles, organizados para el apoyo de un proceso de ayuda a la decisión"

Bill Inmon

El Data Warehouse surge como solución para atender las necesidades de análisis e información globales de la empresa, y consiste en un almacén de datos con toda la información tanto interna como externa necesaria para el negocio.
Enfocado a:

* Descubrimiento de oportunidades
* Control de gestión

Todos los datos del almacén reciben un tratamiento previo que garantiza la homogeneidad, la calidad y su orientación hacia el negocio, la información está especialmente organizada y se gestiona en el entorno idóneo para facilitar los procesos del tipo consulta.

La información se explota mediante herramientas flexibles que independizan en lo posible al usuario del desarrollo informático.
Cuadros de mando y sistemas de soporte a la decisión (EIS, DSS, etc...) son aplicaciones dirigidas a un perfil de usuario alto, no tecnológico.

Suele manejarse principalmente información agregada con un enfoque claramente de negocio.

La información se presenta en forma de indicadores de negocio y conceptos de información de las áreas usuarias en función de las dimensiones de negocio.

Estas aplicaciones se apoyan en técnicas OLAP que muestran la información almacenada en base de datos relacionales (ROLAP), multidimensionales (MOLAP), híbridas (HOLAP), dependiendo de la estrategia de almacenamiento.

Datawarehouse: informes

Utilizando herramientas de mercado que permitan a usuarios avanzados realizar sus propios informes, o se desarrollan informes predefinidos para usuarios menos avanzados. Existen dos tipos de herramientas a utilizar:

* Herramientas de Análisis Multidimensional.
* Herramientas de Query & Reporting.

Se puede definir como el proceso realizado sobre gran cantidad de datos para establecer o modelizar relaciones entre los mismos con un objetivo de negocio determinado. Es una de las formas de explotar el Data Warehouse.

El Datamining se basa en la aplicación de distintas técnicas analíticas y estadísticas sobre una población de datos obtenida del Data Warehouse, con el fin de obtener patrones de comportamiento entre determinados conceptos de información.

Las técnicas que se pueden utilizar en el proceso de Data Mining se clasifican en:

* Estadística clásica
* Exploración visual multidimensional
* Modelos basados en árboles de decisiones
* Redes neuronales

Metadata

2009-02-23T16:47:00.001+01:00

Un aspecto de la arquitectura de data warehouse es crear soporte a la metadata. Metadata es la información sobre los datos que se alimenta, se transforma y existe en el data warehouse. Metadata es un concepto genérico, pero cada implementación de la metadata usa técnicas y métodos específicos.

Estos métodos y técnicas son dependientes de los requerimientos de cada organización, de las capacidades existentes y de los requerimientos de interfaces de usuario. Hasta ahora, no hay normas para la metadata, por lo que la metadata debe definirse desde el punto de vista del software data warehousing, seleccionado para una implementación específica.

Típicamente, la metadata incluye los siguientes ítems:

* Las estructuras de datos que dan una visión de los datos al administrador de datos.
* Las definiciones del sistema de registro desde el cual se construye el data warehouse.
* Las especificaciones de transformaciones de datos que ocurren tal como la fuente de datos se replica al data warehouse.

El modelo de datos del data warehouse (es decir, los elementos de datos y sus relaciones).

Un registro de cuando los nuevos elementos de datos se agregan al data warehouse y cuando los elementos de datos antiguos se eliminan o se resumen.

Los niveles de sumarización, el método de sumarización y las tablas de registros de su data warehouse.

Algunas implementaciones de la metadata también incluyen definiciones de la(s) vista(s) presentada(s) a los usuarios del data warehouse. Típicamente, se definen vistas múltiples para favorecer las preferencias variadas de diversos grupos de usuarios. En otras implementaciones, estas descripciones se almacenan en un Catálogo de Información.

Los esquemas y subesquemas para bases de datos operacionales, forman una fuente óptima de entrada cuando se crea la metadata. Hacer uso de la documentación existente, especialmente cuando está disponible en forma electrónica, puede acelerar el proceso de definición de la metadata del ambiente data warehousing.

La metadata sirve, en un sentido, como el corazón del ambiente data warehousing. Crear definiciones de metadata completa y efectiva puede ser un proceso que consuma tiempo, pero lo mejor de las definiciones y si usted usa herramientas de gestión de software integrado, son los esfuerzos que darán como resultado el mantenimiento del data warehouse.

Gartner - Business Intelligence Tool - Perspective

2009-02-20T10:38:00.004+01:00

El siguiente Texto Pertenece al documento: Gartner - Business Intelligence Tool - Perspective

Datapro Summary
Business Intelligence (BI) is the product of analyzing quantitative business data, usually business transactions; but other sources of data can be used, for example, human resources data. It providesinsights that will enable business managers to make tactical decisions, as well as to establish, modify, or tune the business strategies and processes in order to gain competitive advantage, improve business operations and profitability, and generally achieve whatever goals management has set. Users of an enterprise's BI data have traditionally been inside the enterprise, but with the explosion of the Web for conducting business; i.e., e-business, an enterprise's BI users can be external to the enterprise, as well. BI tools are software programs and systems that businesses use to analyze business data and provide reports and other visualizations to users. Some BI tools are also used to develop, deploy, and manage BI applications. This Perspective report explains BI technology, analyzes the various types of BI tools, and identifies the major vendors and products in each category.

—By Alan H. Tiedrich

Technology Basics
BI is a Gartner concept and core topic of research, which addresses end-user access to, and analysis of, structured business data and information which is quantitative in nature (unstructured information contained in text documents could be considered part of BI, but this type of information can't be analyzed by what we have defined as BI tools). A term coined by Gartner in the late 1980s, BI is a user-centered process that includes accessing and exploring information, analyzing this information, and developing insights and understanding, which leads to improved and informed decision making. This involves an iterative process of accessing data (ideally stored in the data warehouse, data mart, or operational data store, but not necessarily) and analyzing it--thereby deriving insights, drawing conclusions, and communicating findings--to effect change positively within the enterprise. BI usage crosses the spectrum of users throughout the enterprise and includes rank-and-file workers, executives, analysts, and knowledge workers.
At one time, organizations depended on their Information Systems (IS) departments to provide them with both standard and customized reports. This goes back to the days of mainframes and minicomputers, when most end users did not have direct access to the computers. This began to change in the 1970s, when online host-based systems came into vogue. Even then, these systems were used primarily for entering business transactions, and reporting capabilities were primarily a limited number of predefined reports. IS typically was overburdened, and users had to wait for days or weeks to get their reports, if they needed reports other than the standard ones that were available. Eventually, Executive Information Systems (EISs), which were attuned to the decision support needs of executives and managers, were developed. With the advent of the PC, and particularly networked PCs, basic BI tools gave users the technology to create their own basic routine and custom reports.

Types of BI Products
Today's BI tools categories include enterprise BI Suites (EBIS), query and reporting tools, advanced BI tools--primarily On-Line Analytical Processing (OLAP)/advanced analytic tools, and BI platforms for developing BI applications. The BI tools are used by end users to access, analyze, and report against data, which most frequently resides in data warehouses, data marts, or operational data stores. BI applications are developed by using BI development platforms, but these applications are not considered to be BI tools. An example of BI application is an executive information system (EIS).
Most modern BI tools to fall into two categories: enterprise BI suites and BI. Basic query and reporting tools have largely been absorbed into and superceded by the EBISs. Multidimensional OLAP engines, as well as relational OLAP engines, can be used as BI tools and also are the underlying infrastructure for BI platforms.
Data mining refers to a process rather than a technology, with the goal of discovering new correlations, trends, patterns, relationships, and categories. This is accomplished by sifting through large amounts of data stored in repositories, using pattern recognition technologies as well as statistical and mathematical techniques. Data mining iteratively applies different operations or transformations (e.g., feature selection, stratification, subsampling, clustering, visualizations, and regressions) to raw data, with two objectives:

Finding representations that are particularly insightful to humans that result in a better understanding of the underlying business processes.

Finding models that can forecast the outcome of situations or the value of given situations using historical or subjective data.

Unlike using BI tools, data mining is far less user-directed and instead relies upon specialized algorithms that correlate information and assist in discerning important (and otherwise unknown) trends, unguided by user bias and assumptions.

Query and Reporting Tools
Query and reporting tools--typically desktop tools--enable users to access databases, usually networked relational databases, but also multidimensional databases and local databases; to then do some basic analysis and produce reports, which could be displayed and/or printed. While the querying can be ad hoc, it also can be of a scheduled nature. There are reporting systems, typically server-based, that support scheduled querying and reporting. Some of these systems are geared to support "production reporting," which is typically an environment that produces reports from major enterprise systems for widespread distribution. These are successors to the "greenbar" reporting capabilities of mainframe and minicomputer systems that preceded the PCs.
Desktop query and reporting tools have also been enhanced to provide some light OLAP.

EBISs
EBISs--a natural path for the disjointed query, reporting, and OLAP offerings--meet criteria including product scalability, usability, and manageability. They are integrated suites of the query, reporting, and OLAP tools. EBISs should have extensive scalability and extend not only to internal users but also to key customers, suppliers, and the general public. The products should also support a variety of users by providing extreme ease-of-use and requiring minimal training.
EBIS products should aid administrators in the deployment and management of BI functionality, without adding significant new management resources. Because of strong Web affinity associated with EBISs, some vendors have described their EBISs as BI or Web "portals." These portal offerings typically provide a subset of EBIS functionality via a Web browser.

OLAP/Advanced Analytic Tools
OLAP tools are server-based analysis tools that originally were based on multidimensional databases (MDDBs), but today can be based on relational data stores, most often overlaid by an indexing scheme that simulates an MDDB. MDDBs are databases constructed specifically to support analysis of quantitative data, along multiple dimensions. These databases hold this "multidimensional" data in a "pure" multidimensional form. OLAP technology enables users to organize the data in a hierarchical fashion in multiple hierarchies (for the same set of data). Most
applications involve a time dimension, so that data can be analyzed over time to see trends. Other dimensions might involve geography, organizational unit, customer, product, and others. Data is aggregated, sometimes in the database and sometimes on the fly, in order to produce the desired views and reports. So, for example, data could be aggregated to monthly fiscal periods, and then accumulated to a higher level, usually quarterly and/or annual. MDDBs are optimized for multidimensional analysis and come with analytic functionality, providing good performance, but typically require a lot of time to load and expand the size of the source database many fold.
Because MDDBs typically contain largely aggregated data, they come with a "reach-through" capability that enables access to the detailed data in the RDBMS that contains the cube's source data.
Several years back, some vendors began using RDBMSs to store multidimensional data in
relational tables and new object types that support multidimensional analysis. The ROLAP database has the advantage of scalability and flexibility, but (typically) lacks the performance of MOLAP, although there are performance-enhancing techniques, like a star schema design.
Although the MDDBs are still the most common ones for OLAP processing, more recently, this functionality is being built into or extended onto RDBMSs (not the same as storing the multidimensional data in relational tables). This has led to the terms MOLAP, ROLAP, and HOLAP (for hybrid products that can store native multidimensional data and also store data relationally). A "cube" is the conceptual model of measures that share dimensions and the hierarchies in these dimensions. MDDBs are accessed via APIs for multidimensional querying, while RDBMSs are accessed via SQL queries. SQL is limited as a multidimensional language, which ROLAP overcomes to some degree by the use of special engines that generate the SQL,
which is more sophisticated than that which could be manually coded.
OLAP tools allow the user to explore the data in all the various dimensions inherent and built into the database (some allow ad hoc dimensions to be calculated on the fly). Users can select which measures to analyze and which dimensions to display vertically and horizontally on a cross-tab chart. They can then "slice and dice" to focus on a particular combination of dimensions. By supporting a "drill down" capability, OLAP tools allow users to dig down a dimensional hierarchy and explore increasingly detailed levels of data. It also is possible to "drill across" through other dimensions. Another type of data manipulation in OLAP is "pivoting," or swapping rows and columns.
Desktop OLAP tools, now incorporated into EBISs, enable end users to view and manipulate multidimensional data, which might come from server-based ROLAP or MOLAP data stores.
These tools have the ability to download cubes, so that they can function standalone when disconnected from networks. As part of EBISs, these desktop tools have been equipped with server-based processing capabilities, which provide a number of capabilities beyond their desktop capabilities, but do not rival the MDDB-driven MOLAP tools. These have far greater performance and analytical robustness.

BI Platforms
BI platforms offer complete sets of tools for the creation, deployment, support, and maintenance of BI applications. These are data-rich applications, with custom end-user interfaces, organized around specific business problems, with targeted analyses and models. BI platforms, although not as rapidly growing or widely used as EBISs, are also an important segment due to expected growth in BI applications. (BI platforms provide the environments and tools upon which BI
application packages are built.) Due to RDBMS vendors building OLAP into their DBMSs, many platform vendors that offered multidimensional DBMSs for OLAP have been forced to migrate to a BI applications business, in order to survive. However, due to the RDBMSs providing BI functionality, these are actually encouraging the growth of the BI platforms market. Part of this is due to the greater ability to execute on the part of the DBMS vendors. If we consider the dimensions of value (ability to help an enterprise by creating unique applications that sets the enterprise apart from its competitors) vs. functional completeness (the higher the degree of
functional completeness, the more well-suited a tool is for end users) for the various BI tools, we see that EBISs are highly functional but do not have the higher value of BI platforms, or of readymade and custom BI applications. BI platforms are high value but typically not as functionally complete as EBISs.

BI Tools Trends
The BI market continues to evolve. The fastest growing category of BI tools is EBISs, reflecting heightened competition in the new economy, requiring better and faster decisions throughout an enterprise. The use of query, analysis, and reporting tools is declining as organizations replace or upgrade these with EBISs. Still, basic query and reporting tools remain the most ubiquitous BI tools, because they still satisfy most of the users' needs. These technologies are intended to
support the masses of users requiring ad hoc database query, reporting, and basic OLAP analysis.
The use of OLAP and other advanced BI tools, like data mining tools, is also growing. The vendors sometimes identify the EBIS products as BI portals, because the Web-enabled versions of these products provide a Web entry point into an enterprise's information. In fact, often, these BI portals also provide support for linkages to unstructured information too, although this typically requires some system integration to be done. Increasingly, EBIS products are more focused upon external constituents of an enterprise (e-business intelligence).

BI Architecture
An enterprise's BI architecture should be developed after the users' BI requirements have been determined and before BI tools have been selected. The BI architecture will have two major components, a BI information delivery architecture and a BI technology architecture. After determining BI information usage patterns, the information delivery architecture can be designed, based on these usage patterns and also on the type of deployment that is required. This can be any mix of desktop with network connectivity, desktop plus server-based, thin client Web-based, wireless devices, and mobile computing. The information delivery architecture will define the user interfaces, which more and more, are portals, which have personalization capabilities, so that they can be customized for each user or for user groups.
The BI technology architecture defines the infrastructure and components needed to support deployment, execution and management of the BI tools and applications, and the relationships of these components. A sound BI technology architecture will consist of two significant layers:
infrastructure and application services. The infrastructure layers include data storage and management, and network connectivity. Application services include all of the BI services, such as query, analysis, and reporting and visualization engines, as well as security and metadata.

BI Technology Architecture

BI Data Stores
An increasing number of organizations are using the SAP Business Information Warehouse (BW)
as the primary BI data store--SAP BW, a relatively new product is benefiting from the ubiquitous use of SAP's R/3. The use of ROLAP data stores (relational databases) as the primary BI data stores is also growing rapidly, stemming from RDBMS's superior suitability for certain applications involving very large databases of detailed transactions and also due to vendors including OLAP functionality in their RDBMSs. Multidimensional data stores' use remains constant and the most prevalent, probably because such data stores and their tightly linked OLAP tools provide superior performance and functionality for certain types of applications, particularly where the use of aggregates is a major characteristic of the data. OLAP tools also have complex analytic calculations, making these tools optimal for certain applications.

BI Data Access
The growth of the Web to access BI applications is occurring, not surprisingly, at the expense of client/server computing. Client/server client-based processing is decreasing more drastically than client/server server-based, two-tier processing, reflecting that connectivity to corporate BI data is an important element of BI access, and nonconnected PCs will not be functional enough. E-mail distribution of BI reports is growing but will remain a minor factor, and mobile computing
remains a miniscule BI platform because most stationary and mobile end users use the Web for BI access.

Metadata
Most BI tools that are marketed today use a metadata layer or metadata repository. Business metadata includes definitions of the data that is stored in the data sources, in business terms, so that users can use business terminology they are familiar with in creating queries and reports. It also contains business rules and calculations that have been defined for the business. There is also technical metadata, which enables the tools to actually access the physical data. RDBMSs also employ metadata. Metadata also is used by the data transformation tools that are used to build the data warehouses and data marts. When data warehouses and data marts are being constructed, automated metadata capture from the data sources is often possible, but sometimes it is forgone, leaving users to their own devices to capture the metadata into the transformation tool's repository. So, it can be a complicated situation, with several metadata repositories in existence in one organization. A lack of common metadata for tools--there are no standards for metadata-- presents a significant IS challenge.

Technology Analysis
Business Use
The proper use of information is vital to the effectiveness and ultimate success of the enterprise.
Reflecting a democratization of technology use and the emergence of information as a key business asset, the use of BI tools is growing most rapidly among administration and operations personnel. This trend indicates how pervasive technology has become in enterprises. No longer is such technology restricted to professionals or Information Technology (IT) experts; it has become an everyday standard tool. Instead of just being used for transaction processing, IT's use as a customer service and revenue-enhancing tool is making it indispensable for performing
"ordinary" previously clerical functions. This is elevating lower-level personnel into jobs that involve making decisions.
The majority of BI users need only basic information, and their jobs have a relatively small BI component (perhaps 10 percent). The most basic information is historical reporting, which is very generic; i.e., not specific to any user's needs, a common denominator type of information. It may consist largely of static published reports and could include OLAP views. Knowledge workers have a much higher BI content in their jobs, perhaps 30 percent, and business analysts, on the order of 80 percent. Such needs may be satisfied partly by parameter-driven reports, or at the highest level, by ad hoc queries and OLAP.

Business Forces Driving BI Tools Use
Perhaps it can be attributed to the explosion of personal computing and most recently to the Internet, but the pace of business has increased dramatically over the last several years. The term Internet speed" is used to denote the pace at which businesses must act to survive and prosper.
Executives, managers, and other high-level technology users have recognized that decisions must be made quickly and intelligently and must be based on accurate and timely data. Increasing revenue and improving customer service are also very important goals for enterprises, which are looking for ways to increase revenue not only from current lines of business but also by identifying new business opportunities and new business models. Although revenue growth is a fairly standard business goal, revenue growth and market share have become even more important since today's business strategy is to grow the business as large and as fast as possible, and to expand globally. The mergers of huge companies into mega-companies is accelerating this trend.
How to serve customers better is an important goal, because businesses have recognized that acquiring new customers is typically more expensive than retaining customers. Making businesses more efficient and decreasing business costs also are important, reflecting the importance of optimizing the bottom line.
Rapid growth of BI technology use by executives demonstrates how aware they have become of the impact of technology on business and how important BI tools are to executive decision making. Executives and managers in our restructured companies cannot rely on staff (which they may not even have in our streamlined modern organizations) to assist them in gathering and analyzing information, but must accomplish these tasks personally. In addition, the rapid pace of today's commerce requires faster decision-making; executives cannot afford to wait for
subordinates to "get back to them" with the required analysis. Lastly, decision making is an iterative process, which requires a "hands-on" approach. Fortunately, BI tools have been made friendlier so that personnel at all levels can use them with facility.
The most important driving force of business today, however, is the Internet, which is personified by e-business. Thus, we see business-to-business Web sites, business-to-consumer Web sites, marketplaces--all ways of doing business electronically. As integral components of these Web sites, analytic functionality (e-business intelligence) is vitally important to analyze the behavior of transactors on these Web sites, particularly their buying behavior. This BI information can be feedback into the systems powering the Web site in a closed-loop fashion, with the information being used automatically to modify the way the system handles situations or customers. A good example of such a system is a customer relationship management (CRM) system; such systems are being endowed with intrinsic BI functionality. The second major use for BI in e-business is to support the extended enterprise--customers, suppliers, and other business partners. In this case, members of the extended enterprise have access to BI information, including not only that coming from their own business transactions, but also information based on transactions done by other entities (on a summary and anonymous basis). Thus, there is a rapidly growing need for extraenterprise access to BI data, by the enterprise's customers, suppliers, and others.

Query, Reporting Tools, & EBISs
With the variety and number of BI users, enterprise-wide access to corporate BI data is a high priority. Today, in spite of the availability of advanced analytic tools and applications, basic query, analysis, and reporting tools are still the most sought after BI tools. With the democratization of information, the number of BI users is increasing dramatically at executive and operations personnel levels. A great deal of the need is for these users, who will be satisfied by basic query, analysis, and reporting. EBISs are the successors to the basic query and reporting tools and are supplanting or extending them, to provide support for varying levels of users, with a variety of query, reporting, and OLAP capabilities, with minimal training.

OLAP Tools
OLAP is used primarily for analyzing aggregated/derived multidimensional data. It supports sales analysis and forecasting, financial budgeting and forecasting, risk analysis, trend analysis and a variety of other applications. OLAP and other advanced analytic capabilities carry a high priority.
These BI tools, while used by a smaller user population than EBISs or basic query and reporting tools, have the possibility of returning higher value in that they can help organizations spot trends that alert them to problems or opportunities.

Data Mining
Data mining is used for many different types of applications, like fraud detection, churn management; forecasting customer behavior for targeted marketing or cross-selling, i.e., the likelihood of a future event (e.g., response to an offer, churn, failure); affinity modeling, i.e., what other products people bought and who bought a particular product; the detection of outliers; link analysis to define the relationships between events and other occurrences, e.g., for looking at all
kinds of fraudulent behavior (e.g., front-running, money laundering, insurance fraud, and eauctions)-- in industries as diverse as insurance and telecommunications, basically anywhere. The two most popular types of data mining are clustering and decision trees; other common ones include neural networks and regression. The latest opportunity for data mining is in mining clickstream data, initially focusing on operational issues (e.g., peak hours and the top 10 pages hit), but future applications will include profiling together with segmentation and more advanced trend analysis, perhaps followed by more advanced personalization and CRM integration (e.g., churn and complaints), and then CRM aspects will be tied back to operational aspects, inventory management, and dynamic pricing.

BI Platforms
The older high-end BI platforms dominated the market when end-to-end environments based upon 4GLs were the norm. These were targeted at IS organizations that internally developed user applications. Today, many IS (and end-user) organizations prefer packaged applications over internally developed solutions. Hence, BI platforms will be used increasingly by third-party application developers (e.g., VARs as a mechanism to deliver "best practice" BI applications) directly to end users.

Benefits and Risks
The benefits of using BI tools are explored in detail in the Business Uses section, so these will not be repeated here. Suffice to say that the appropriate use of BI tools will mean the difference between the life and death of many enterprises; between stagnation and growth; between lackluster results and outstanding financial performance; between excellent, personalized customer service and impersonal, shoddy service; and between optimizing the relationships with parties outside of the enterprise and losing the possible benefit of working with suppliers and others as business partners. BI is just that important!
As to risks, the risks are not so much in the technology, as they are in properly assessing the enterprise's true BI needs and then in selecting the most appropriate vendors and products. The major technological risk is that the technology is changing so rapidly. Vendors that created their products before the Web became avante garde now find themselves with legacy software that has to be rationalized with new Web-enabled versions of their products. Newer products built for the Web are from vendors that are newer, and there is a trade-off between getting the latest
technology and getting the most stable vendors. E-business has great implications for BI tools, and vendors are still building e-business intelligence capabilities into their products and integrating BI data and results back into the e-business applications. The latest technological shift to affect BI is the advent of wireless applications. BI tools vendors have adding capabilities to allow BI applications to be accessed via wireless technology. Naturally, these new technologies
bear some risk until they are well proven. Lastly, many of the BI tools vendors are small companies, or medium sized, apart from a few large companies and the RDBMS vendors.
Therefore, one of the most important risks is the vendor's ability to execute, so this is something to consider.
Some of the biggest risks related to the use of BI tools are based on data. One of the biggest risks of using BI tools is related to data quality; i.e., that the data being used has not been properly cleansed. Because business domains within an enterprise often choose their own BI tools, an enterprise may end up with multiple BI tools in use, as well as multiple data marts with data that may not be defined in a common way or with metadata that is not compatible. This can lead to different domains drawing different conclusions about the same data. If data warehouse
architecture for the enterprise is carefully planned, much of this can be alleviated.

Standards
OLE DB for OLAP
Microsoft OLE DB for OLAP is a set of objects and interfaces that extends the ability of OLE DB to provide access to multidimensional data stores and enables users to perform sophisticated data analysis through fast, consistent, interactive access to a variety of possible views of the underlying information. OLE DB for OLAP enables developing and accessing multidimensional data providers (MDPs), which present data in multidimensional views, and tabular data providers (TDPs), which present data in tabular views. It is possible for a single data source object to support both tabular and multidimensional presentations. OLE DB for OLAP Component Object Model (COM) interfaces to create client applications. OLE DB for OLAP allows independent software vendors and corporate application developers to depend on a single interface for accessing multidimensional data, regardless of the vendor or source. With this technology, OLAP applications can uniformly access both relational and nonrelational data stored in diverse information sources, regardless of location or type.

OLE DB for Data Mining
This specification addresses data mining-specific provisions of OLE DB support, which was enhanced with the OLE DB for Data Mining specification to provide integration of third-party data mining algorithms.

Selection Guidelines
The selection of BI tools should be done only after an analysis of the business and enterprise needs have been performed and a BI technology architecture has been designed. It is likely that a single BI tool will not support the needs of all users. Therefore, several tools may need to be selected to perform various BI functions. EBISs include a breadth of BI functions required by end users, so selection of an EBIS may satisfy some or all of the BI needs. If BI applications need to be developed, then a BI platform may need to be selected. It is possible that both an EBIS and a BI platform may be needed. Other needs might be satisfied by selecting an OLAP server or a data mining tool. Again, the types of tools needed will be determined only after an analysis of the users' BI needs. As a general statement, Gartner has found that clients are looking for several things when selecting BI tools, so these should be considered in addition to other specific criteria defined below for the two major BI tool categories (EBIS and BI Platforms): Internet accessibility, end-user ease of use, and long-term company viability.

EBISs
Gartner criteria for evaluating EBISs include scalability, usability, and manageability:
Scalability
An EBIS needs to extend beyond the enterprise, offering basic BI functionality. Its architecture must be designed to distribute processing flexibly without undue complexity or placing an unreasonable burden upon IS departments. Attributes should include distributed architecture; load balancing and failover support; and extranet, intranet, and Internet support.
Usability
An EBIS must support a wide range of users (i.e., with different needs, styles, and levels of sophistication). It must help keep user training to a minimum with straightforward and consistent interfaces. The main attributes are support for multiple user styles, common user objects, and interchangeable and interoperable components.
Manageability
An EBIS must support strong management/administration facilities that aid IS personnel in installation and ongoing support. Since resources will continue to be scarce, and EBIS implementations are likely to be large, these facilities must introduce a new level of automation and abstraction to reduce the cost of deployment. The facilities must include common infrastructure, security, scheduled processing, and rich administration.

BI Platforms
Gartner has defined the characteristics of a BI Platform to include a modular, distributed architecture, supporting relevant standards like XML, OLE DB for OLAP, and providing total Web deployment. It must be open and extensible, so that third parties are encouraged to and can easily add functionality. The vendor must provide a strong third-party support program. This will assist the vendor in building a business of sufficient size, which is essential to the success of BI Platform vendors. Of course, the product must have comprehensive BI functionality.
Modern Platform Architecture
The BI platform must provide support for modularity (e.g., components) and an accepted distributed computing model. Platforms should support de facto and de jure BI and other standards--e.g., LDAP, Extensible Markup Language (XML), OLE DB for online analytical processing (OLAP), Common Object Request Broker Architecture (CORBA), Common Object Model/Distributed Component Object Model (COM/DCOM)--and total Web deployment.
Third-Party Extensibility
The BI platform must provide the ability to add significant new functionality without
fundamentally altering the core BI platform with a useful and well-documented set of application programming interfaces (APIs) and support the dominant applications development paradigms (e.g., Java).
Vendor Support Programs
The BI platform vendor must support the creation, promotion and advocacy of third-party extensions and product offerings, when possible, as part of an overarching third-party support program.
Critical Market Expansiveness
The BI platform must be widely used to offer a "safe choice" for application developers--e.g., value-added resellers (VARs), independent software vendors (ISVs)--as an established and stable vendor/product.
BI Features
The BI platform must provide BI-specific functionality such as database access capabilities (e.g., SQL), multidimensional (OLAP) data manipulation, modeling functions (e.g., what-if analysis), statistical analysis (e.g., ANOVA), and graphical presentation of results (e.g., charting).

OLAP Servers
Of MOLAP- and ROLAP-based tools, the MOLAP-based tools offer the most analytic
functionality and the best query performance, provided aggregated data is suitable for the organization's requirements, as opposed to large volumes of detailed records. They offer good¡ scalability of numbers of users and somewhat less, but still good, data scalability. ROLAP tools typically provide the best data scalability, and they are a better solution than MOLAP when large volumes of detailed records must be accessed frequently. Scalability of numbers of users is only fair at best, and query performance and analytic functionality are fair. HOLAP tools provide the best of both worlds in a single solution, but these do not always offer the full-blown capabilities of both ROLAP and MOLAP. They also place on IS the requirement of administering both a relational database environment and a multidimensional database environment. A HOLAP environment, while offering flexibility, also requires decisions to be made about which data elements should be placed in the relational database and which should be placed in the
multidimensional construct. Help in the form of better administrative, monitoring, and tuning tools are likely to come from RDBMS vendors who have added or are adding MOLAP support.
Desktop tools can provide excellent scalability and query performance, but this comes at the expense of analytical functionality (which is lacking) and data scalability.

Technology Leaders
The two Gartner Magic Quadrants for EBISs and BI Platforms include a number of firms in the Leaders quadrants, as well as several challengers or visionaries close to the Leaders quadrants.
The EBIS technology leaders include Business Objects Inc., Cognos Corp., MicroStrategy Inc., and Information Builders. Although Oracle Corp.'s BI tools are the most widely installed BI tools (according to revenue figures obtained from Oracle by Gartner's Dataquest), it's doubtful that the Oracle BI tools are really used by all or most of the Oracle enterprise licensing agreement (ELA) shops, just because the tools are bundled into the ELA and are therefore "free." Other EBIS competitors which are at the periphery of the Leaders quadrant of Gartner's EBIS Magic Quadrant include Brio Technology Inc., Computer Associates, and Seagate Software.
According to the Gartner Magic Quadrant for BI Platforms, technology leaders include Hyperion Solutions, Microsoft, and Oracle Corp. IBM has added OLAP functionality, through an agreement with Hyperion, under which they have implemented Essbase functionality in DB2.
Other vendors which are at the periphery of the Leaders quadrant of Gartner's BI Platform Magic Quadrant include Information Builders Inc. and The SAS Institute. Some additional contenders include AlphaBlox Corp., Comshare Inc., MicroStrategy Inc., Sagent Technology Inc., and Seagate Software.

Business Objects, Inc. BusinessObjects 2000
Business Objects for a long time, and even now, has been one of the two major independent tool competitors in the EBIS market. BusinessObjects 2000 is a comprehensive EBIS, providing client/server and Web client functionality that are very similar to one another in two companion products--BusinessObjects and WebIntelligence. Business Objects' strategy is targeted towards e- Business Intelligence, or the marriage of the Internet with BI. Although BusinessObjects has been Business Objects' flagship product and the foundation of the company, WebIntelligence is where Business Objects charts the future of the company. BusinessObjects 2000 includes the key products BusinessObjects InfoView 5.1 (the BI portal to both BusinessObjects and WebIntelligence), WebIntelligence 2.6 (thin client Web-based with a distributed architecture), BusinessObjects 5.1 (full-client desktop and Web-enabled), BusinessObjects Broadcast Agent 5.1 (optional), and BusinessObjects Set Analyzer 1.2 (optional). WebIntelligence Wireless Edition
supports wireless access via WAP-enabled devices to mobile users. Business Objects has set up a subsidiary (Ithena) to focus on BI applications.

Cognos Corp. Platform for Enterprise Business Intelligence
Cognos for a long time, and even now, is one of the two major independent tool competitors in the EBIS market. Cognos is focusing on enterprise and Web deployment of BI services. The Cognos Platform for Enterprise Business Intelligence (Platform for EBI), which is a technology infrastructure, not a product, leverages Cognos' hallmark Impromptu and PowerPlay products, which have been market leaders for several years. The Platform for EBI multilayered infrastructure features a portal that provides a single point of access into all of an organization's business intelligence documents and reports as well as related authoring services. From this
portal, users can access querying, analysis, reporting, viewing (reports), and visualization (graphic) facilities. The EBI Services layer contains Cognos Servers: PowerPlay, Impromptu, Cognos Query, and Cognos Visualizer. The Cognos Platform for EBI's multiserver architecture provides scalability, incorporating both Unix and Windows NT. In bringing forth its Platform for EBI, Cognos is attempting to move up-market, but Gartner has not yet placed it in the Gartner BI Platforms category. BI-ready data marts, relational and multidimensional, can be created by using the BI Data Mart Creation Services layer. With DecisionStream, users can design, create, load, and deploy BI marts. Cognos has set up a BI applications business unit and offers several BI applications.

Hyperion Solutions Corp. Essbase OLAP Server
Hyperion Essbase, an OLAP engine that is the foundation for the Hyperion Essbase product family, has been the most successful OLAP Server and BI Platform product on the market in the last several years. Hyperion's goal for Hyperion Essbase is to provide a strategic platform for enterprise OLAP by delivering industry-leading technology in the areas of scalability, performance, distributed architecture, and OLAP application integration. Based upon a multitier architecture, Hyperion Essbase supports multiuser read and write access; large-scale data capacity; robust analytical calculations; flexible data navigation; and consistent, rapid response
times in network-centric environments. The Hyperion Essbase server's open architecture supports direct data access using standard spreadsheets; leading third-party query, reporting, and BI tools; and Web browsers. While Hyperion focused on creating OLAP server technology to satisfy the processing needs, it leveraged Excel and Lotus as the client interface instead of building its own.
Lacking a complete solution of its own, Hyperion partnered with other third-party tools vendors to provide a total BI solution. Such support includes more than fifty front-end tools, such as Seagate Software's Crystal Reports and Crystal Info; and desktop OLAP viewers, such as Business Objects' BusinessObjects, or Cognos PowerPlay. Hyperion Essbase supports crossplatform deployment to Unix, Windows NT, AS/400, and Windows 95/98 servers.
Hyperion Solutions offers a line of BI applications software too.

Information Builders, Inc. WebFOCUS Business Intelligence Suite
Information Builders has been a leading provider of query, analysis, and report writing technology for many years. The scope of the WebFOCUS product line places it in both the EBIS and BI Platform categories, giving it dual status. Information Builders' WebFOCUS Business Intelligence Suite is a scalable, integrated EBIS designed for enterprise-level query, analysis, and reporting over heterogeneous platform environments to clients in any location. The WebFOCUS BI Suite includes WebFOCUS Reporting Server for reporting and analysis; a WebFOCUS Maintain Server for building client/server and Web applications; the WebFOCUS Report Broker to manage reporting and distribution; ERP modules for J.D. Edwards, SAP, PeopleSoft, etc.; and
WebFOCUS InfoCube, a library of business intelligence templates for comprehensive analysis of sales, marketing, profitability, and more. WebFOCUS provides multidimensional analysis of data, with change of sorting criterion, multiple reporting, graphing, drill-down, user configurable reporting formats; on-demand paging, with hyperlinks to pages of other reports; and the capability to manage output effectively and be distributed via the intranet, e-mail, networked printers, or to wireless devices. The application set leverages data resources from repositories whether they are relational databases or ERP packages such as SAP or PeopleSoft, or whether they are stored in mainframe systems such as IMS or CICS. The system provides a development toolset that is full integrated with Microsoft Office 2000; BackOffice 2000; and Microsoft OLAP Services for dynamically generating information using cube data; Excel pivot tables; and many Office documents in a variety of formats, including XML, HTML, CGI, Excel, PDF, and Excel 2000 for display in Web browsers or for use with desktop applications. The WebFOCUS system is scalable from a wireless palm-top to desktop, to workstation, to mainframe and can run on NT, Linux, Unix, OpenVMS, OS/390, MVS, and CMS.

Microsoft Corp. SQL Server 2000 Analysis Services
Microsoft SQL Server 2000 Analysis Services is a robust BI Platform that runs on Microsoft Windows NT platforms only. It can access other relational databases through OLE DB support and allows front-end tools to access it through OLE DB for OLAP. While Analysis Services is part of the SQL Server 2000 product, Analysis Services is a middle-tier OLAP server that functions independently of the SQL Server RDBMS. In addition to providing analytic functionality, Analysis Services also has data mining capabilities, albeit simple ones, coming with two data mining models: a decision tree model and a clustering model. Microsoft Analysis Services was designed with a number of scalability- and performance-enhancing features, including cube data compression (Unlike competitors' cubes, which explode the source data into
much larger OLAP data sets, Analysis Services compresses the data into smaller OLAP cubes.), partial data aggregation with on-the-fly aggregation, and partitioning, to name a few of the most significant. In addition, it has extensive support for parallel processing and load distribution, through cube partitioning, parallel querying against partitioned cubes, as well as wizards to help determine how to trade off storage considerations for performance. Analysis Services supports
MOLAP, ROLAP, and HOLAP; write-back, which is essential for budgeting and forecasting
applications; and even has a realtime cube update option. Its extensive functionality can be further enhanced and automated by custom development. Although Microsoft just entered this market at the end of 1998, it has established a strong presence and position in this market.

MicroStrategy Inc. MicroStrategy 7
MicroStrategy has proven a tough competitor for data warehousing DW/BI scenarios, especially where leveraging traditional RDBMS strengths for scalability, flexibility, and administrative controls are important. MicroStrategy Inc.'s MicroStrategy 7 is the culmination of a rearchitecting of the product into a componentized multitier environment. It has a number of significant improvements in functionality, ease of use, deployability, performance, and application development. In addition to its long-time classification as an EBIS, Gartner recently has classed MicroStrategy in the BI Platforms category, giving it dual status. Using a three-tier architecture, it is a suite of integrated components, which distributes processing among multiple servers.
MicroStrategy Web is MicroStrategy's client interface that provides OLAP capabilities via a Web browser, while MicroStrategy Agent provides these capabilities in a Windows environment.
MicroStrategy 7 has an intrinsic relational database foundation, which leverages the functions and capabilities inherent in RDBMSs. In MicroStrategy 7, mathematical, statistical, and financial functions either can be performed in the RDBMS or in the MicroStrategy 7 analytical engine.
MicroStrategy 7 cannot access OLAP servers; e.g., Hyperion Essbase. MicroStrategy 7 is targeting the wireless BI applications market. MicroStrategy doesn't offer analytic applications, but relies on partnerships for this (MicroStrategy has an applications group, which right now focuses solely on eCRM applications. There is a product available now, eCRM6, which is built with the MSTR 6 platform. MicroStrategy is currently developing eCRM7 on top of the 7 platform.).

Oracle Corp. Express
Oracle Corp. offers Express' integration of relational and multidimensional data and support for both Unix and Windows NT platforms, combined with an Oracle Web strategy, data warehousing strategy, and its reputation as a leading RDBMS vendor. Oracle Corp.'s Express products constitute a BI Platform and support analytical business processes, such as modeling, forecasting, statistical analysis, sales and distribution analysis, and financial analysis. Express Server, an OLAP server, is a key component of Oracle's business intelligence (BI) tools, which also include Oracle Express Objects, an object-oriented graphical tool for developing custom BI applications; Oracle Discoverer for performing ad hoc queries; and Oracle Reports for reporting. Express Server operates on both client/server and Web platforms. Express Server is a HOLAP tool, able to support both RDBMSs and/or its own MDDB. Express client tools include Express Objects and Express Analyzer, an analytical tool that allows end users to run and extend Express Object applications. Express Server is also the underlying technology enabling Oracle's packaged BI applications: Oracle Financial Analyzer, Oracle Sales Analyzer, and Oracle Demand Planning.
Oracle has ambitious plans for integrating Express technology with the Oracle RDBMS in the forthcoming Oracle 9i and also for improving its application development support with BI Beans and Java OLAP API--Java object-oriented API.

The SAS Institute SAS System and Solutions
The SAS System is a comprehensive data collection and storage system, with extensive data analysis and application development capabilities. SAS Software Solutions, including over 50 software tools, support all the activities of data warehousing and business intelligence processes.
The SAS BI/OLAP solution, which constitutes a BI Platform, is based on The SAS System and the SAS Software Solutions. The foundation of SAS Software Solutions, The SAS System, is an integrated suite of information delivery tools, which enables companies to transform enterprisewide data into business intelligence. Base SAS, the foundation of the SAS System, provides an application development environment for data access, management, analysis, and presentation.
The SAS BI/OLAP solution creates a data warehouse of information. Access to this data, which can be stored as MOLAP or ROLAP, is controlled by the SAS Data Warehouse metadata. SAS Software Solutions offer a wide range of query, analysis, and reporting capabilities for the data warehouse, including EISs, data mining, neural networks, data visualization and discovery, statistical analysis, econometric time series forecasting, operational research, quality control, geographic information systems, and market research. The SAS data mining solution enables users to apply exploratory statistical and visualization techniques, select and transform the most
significant predictive variables, model the variables to predict outcomes, and confirm a model's accuracy. The SAS Solution for e-Intelligence is a comprehensive suite of data integration, analysis, and reporting applications that integrates data from all channels--including e-commerce systems. SAS e-Intelligence Solutions extract data from Web-based applications and organize it into the data warehouse, so the data can be analyzed along with traditional corporate data using SAS analytic tools.

Insight
For many years, IT was used primarily to process business transactions and to provide reports on historical information. While this information was helpful, it was too aged to help with making decisions that required more timeliness and better analysis tools. BI tools have come into their own in the last few years, and the rapid pace and complexity of business today, together with the availability of IT to support BI processes, has both enabled and forced enterprises into leveraging the business data that is captured through business transactions processing. The growth and availability of relational databases and data warehousing began to support a shift into converting data into business intelligence. The concurrent growth of multidimensional databases and OLAP technology also furthered the ability to create business intelligence information. BI tools have evolved from rudimentary query and reporting tools into enterprise BI suites and BI platforms.
Most recently, the growth of the Web for e-business and the business trends of customer relationship management and supply chain planning have extended the enterprise to include suppliers, customers, and other business partners. All of these parties need and are being provided with access--via the Web--to BI being assembled by the enterprise. Fortunately, great advances in BI technology now offer a selection of alternative BI tools that can handle many of the needs and are being constantly enhanced with additional capabilities. The biggest challenges for enterprises are to define their BI goals, their user requirements, a suitable BI technology architecture, and then to select the best tools or applications and implement them.

Fuente: Gartner - Business Intelligence Tool - Perspective

El Cuadrante BI de Gartner del 2009

2009-02-20T10:30:00.003+01:00

Este es el cuadrante BI de Gartner publicado hace unos dias.
Y este es el del año pasado

Evolucion ?

Oracle Business Intelligence

2009-02-17T10:37:00.002+01:00

Desde hace casi un año Oracle presenta una solucion de BI: OBIEE.

Si os quereis iniciar la documentacion del producto esta en http://www.oracle.com/technology/documentation/bi_doc.html

La descarga del producto:
http://www.oracle.com/technology/software/products/ias/htdocs/101320bi.html
o
http://www.oracle.com/technology/software/products/ias/htdocs/101321biseone.html

que lo disfruteis.!!!!

Data Warehouse en profundidad

2009-02-09T08:57:00.001+01:00

Empieza el primer tema hablando de los Data Warehouses, los almacenes de datos.
Los sistemas tradicionales empezaron a tener problemas para satisfacer las necesidades de los usuarios y de esta problematica, surgen los Data Warehouse como sistemas de apoyo a la toma de decisiones, en que los datos de una organización se transforman en información estratégica. Ayudan a su vez a disponer de un acceso sencillo e inmediato a determinada información de negocio estructurada y de calidad.

Acceder a los datos directamente en sistemas operacionales (del dia a dia, no DWH) suponía algunos problemas:

Conocer lenguajes como SQL
Rendimiento
Los datos no están preparados para las consultas necesarias.
No suelen tener un horizonte histórico como para detectar tendencias o realizar seguimientos.

Data Warehousing versus Data Warehouse
Data Warehousing es el proceso de crear y mantener un almacén central de datos, es decir un Data Warehouse.

Características de un DWH

Orientado a temas: en contra de la orientación a procesos de los sistemas operacionales, facilitando su acceso y entendimiento.
Integrado: Los datos de un DWH son íntegros en unidades de medida, nombres, codificación, etc...
Variante en el tiempo: Se guardan datos históricos (del orden de años) que facilitan la evaluación e identificación de tendencias.
No volátil: Los valores permanecen en el DWH sin modificación.

Diferencias entre un DWH y una BD Operacional
La principal diferencia entre un Data Warehouse y una BD operacional es su objetivo, el primero esta orientado a las operaciones del día a día y el segundo al análisis y la toma de decisiones. Por tanto podemos preveer que uno recibe multitud de transacciones repetitivas y conocidas y el DWH consultas masivas, puntuales y no conocidas. También como diferencia encontramos el rendimiento, la volatilidad, los usuarios (más expertos), estructura (relacional versus multidimensional), alcance histórico, detalle de los datos y por último el volumen, mucho mayor en un DWH.

Arquitectura de un DWH
Cuando hablamos de la arquitectura, nos referimos a la manera de representar la estructura global de los datos, los procesos y las interfaces de usuario. Las bases de esta arquitectura son:

Mezclar los datos de la BD operacional con otras fuentes de datos, incluidas las externas.
Información fácil y transparente
Proveer al usuario de un acceso universal a los datos (apoyado en lenguaje SQL)
Metadatos: De donde proviene un dato, que formato tenía, significado, como se ha calculado, etc...
Construir y mantener el directorio de datos.
Gestión de copia y de replicación: todos los procesos necesarios para asegurar la calidad de los datos.

Estructura del DWH
¿Qué nivel de detalle tienen los datos? Normalmente difiere de los sistemas de producción por contener agregaciones y por guardar al detalle los datos de otros años.
Dentro del DWH también encontramos los famosos Metadatos, que los podríamos definir como un directorio para ayudar a ubicar los contenidos, una guía de donde provienen los datos y una descripción de los algoritmos utilizados para calcular las agregaciones pertinentes.

Data Mart
Un Data Mart cumple los mismos principios que un Data Warehouse, pero difiere principalmente en el alcance del mismo, que seria de un departamento o grupo de personas y no de toda la organización. De Data Marts podemos encontrar de dos tipos: dependientes e independientes según si los datos son extraidos del DWH o directamente de los sistemas operacionales (a la larga un desastre).

Explotar un Data Warehouse
El reto es sacar datos y convertirlo en información, que se dice pronto... y encima querer crear una ventaja empresarial. Este reto va des de la edición de informes hasta una minería de datos avanzada, con análisis multidimensional. Por tanto, un DWH es un medio, no un fin en si mismo. Ningún proyecto debería tener como finalidad construir un DWH, sino obtener información... si bien, cabe decir que el construirlo debe suponer una gran meta.
Para la explotación encontramos tres técnicas principalmente: Query and reporting, OLAP (análisis multidimensional) y Minería de datos . La primera consiste en realizar informes y generar consultas flexibles, con una interfaz gráfica, permitiendo también escribir total o parcialmente la consula en SQL (o similar). La segunda (OLAP) consiste en realizar análisis desde un conjunto de perspectivas o dimensiones. Muy adecuada para grandes volúmenes de datos.
La tercera consiste en el descubrimiento de conocimiento no accesible de manera directa... si no que se encuentra oculto, por ejemplo, buscar patrones de información en los datos.

Fuente: http://estudiandobi.blogspot.com/2007/11/data-warehouse-en-profundidad.html

FASES DE IMPLANTACIÓN DE UN DATA WAREHOUSE

2009-01-22T00:17:00.001+01:00

Tal y como aparecía en un artículo en ComputerWorld: "Un Data Warehouse no se puede comprar, se tiene que construir". Como hemos mencionado con anterioridad, la construcción e implantación de un Data Warehouse es un proceso evolutivo.

Este proceso se tiene que apoyar en una metodología específica para este tipo de procesos, si bien es más importante que la elección de la mejor de las metodologías, el realizar un control para asegurar el seguimiento de la misma.

En las fases que se establezcan en el alcance del proyecto es fundamental el incluir una fase de formación en la herramienta utilizada para un máximo aprovechamiento de la aplicación. El seguir los pasos de la metodología y el comenzar el Data Warehouse por un área específica de la empresa, nos permitirá obtener resultados tangibles en un corto espacio de tiempo.

Planteamos aquí la metodología propuesta por SAS Institute: la "Rapid Warehousing Methodology". Dicha metodología es iterativa, y está basada en el desarrollo incremental del proyecto de Data Warehouse dividido en cinco fases:

Definición de los objetivos
Definición de los requerimientos de información
Diseño y modelización
Implementación
Revisión

Definición de los objetivos

Definición de los requerimientos de información

Tal como sucede en todo tipo de proyectos, sobre todo si involucran técnicas novedosas como son las relativas al Data Warehouse, es analizar las necesidades y hacer comprender las ventajas que este sistema puede reportar.

Es por ello por lo que nos remitimos al apartado de esta guía de Análisis de las necesidades del comprador. Será en este punto, en donde detallaremos los pasos a seguir en un proyecto de este tipo, en donde el usuario va a jugar un papel tan destacado.

Diseño y modelización

Los requerimientos de información identificados durante la anterior fase proporcionarán las bases para realizar el diseño y la modelización del Data Warehouse.

En esta fase se identificarán las fuentes de los datos (sistema operacional, fuentes externas,..) y las transformaciones necesarias para, a partir de dichas fuentes, obtener el modelo lógico de datos del Data Warehouse. Este modelo estará formado por entidades y relaciones que permitirán resolver las necesidades de negocio de la organización.

El modelo lógico se traducirá posteriormente en el modelo físico de datos que se almacenará en el Data Warehouse y que definirá la arquitectura de almacenamiento del Data Warehouse adaptándose al tipo de explotación que se realice del mismo.

La mayor parte estas definiciones de los datos del Data Warehouse estarán almacenadas en los metadatos y formarán parte del mismo.

Implementación

La implantación de un Data Warehouse lleva implícitos los siguientes pasos:

Extracción de los datos del sistema operacional y transformación de los mismos.
Carga de los datos validados en el Data Warehouse. Esta carga deberá ser planificada con una periodicidad que se adaptará a las necesidades de refresco detectadas durante las fases de diseño del nuevo sistema.
Explotación del Data Warehouse mediante diversas técnicas dependiendo del tipo de aplicación que se de a los datos:

Query & Reporting

On-line analytical processing (OLAP)

Executive Information System (EIS) ó Información de gestión

Decision Support Systems (DSS)

Visualización de la información

Data Mining ó Minería de Datos, etc.

La información necesaria para mantener el control sobre los datos se almacena en los metadatos técnicos (cuando describen las características físicas de los datos) y de negocio (cuando describen cómo se usan esos datos). Dichos metadatos deberán ser accesibles por los usuarios finales que permitirán en todo momento tanto al usuario, como al administrador que deberá además tener la facultad de modificarlos según varíen las necesidades de información.

Con la finalización de esta fase se obtendrá un Data Warehouse disponible para su uso por parte de los usuarios finales y el departamento de informática.

Revisión

La construcción del Data Warehouse no finaliza con la implantación del mismo, sino que es una tarea iterativa en la que se trata de incrementar su alcance aprendiendo de las experiencias anteriores.

Después de implantarse, debería realizarse una revisión del Data Warehouse planteando preguntas que permitan, después de los seis o nueve meses posteriores a su puesta en marcha, definir cuáles serían los aspectos a mejorar o potenciar en función de la utilización que se haga del nuevo sistema.

Diseño de la estructura de cursos de formación

Con la información obtenida de reuniones con los distintos usuarios se diseñarán una serie de cursos a medida, que tendrán como objetivo el proporcionar la formación estadística necesaria para el mejor aprovechamiento de la funcionalidad incluida en la aplicación. Se realizarán prácticas sobre el desarrollo realizado, las cuales permitirán fijar los conceptos adquiridos y servirán como formación a los usuarios.

Fuente: Dataprix

Componentes a tener en cuenta a la hora de construir un Data Warehouse

2009-01-22T00:15:00.002+01:00

Un componente fundamental a la hora de poder contar con un Data Warehouse que responda a las necesidades analíticas avanzadas de los usuarios, es el poder contar con una infraestructura hardware que la soporte.

En este sentido son críticas, a la hora de evaluar uno u otro hardware, dos características principales:

Por un lado, a este tipo de sistemas suelen acceder pocos usuarios con unas necesidades muy grandes de información, a diferencia de los sistemas operacionales, con muchos usuarios y necesidades puntuales de información. Debido a la flexibilidad requerida a la hora de hacer consultas complejas e imprevistas, y al gran tamaño de información manejada, son necesarias unas altas prestaciones de la máquina.

Por otro lado, debido a que estos sistemas suelen comenzar con una funcionalidad limitada, que se va expandiendo con el tiempo (situación por cierto aconsejada), es necesario que los sistemas sean escalables para dar soporte a las necesidades crecientes de equipamiento. En este sentido, será conveniente el optar por una arquitectura abierta, que nos permita aprovechar lo mejor de cada fabricante.

En el mercado se han desarrollado tecnologías basadas en tecnología de procesamiento paralelo, dan el soporte necesario a las necesidades de altas prestaciones y escalabilidad de los Data Warehouse. Estas tecnologías son de dos tipos:

SMP (Symmetric multiprocessing, o Multiprocesadores Simétricos): Los sistemas tienen múltiples procesadores que comparten un único bus y una gran memoria, repartiéndose los procesos que genera el sistema, siendo el sistema operativo el que gestiona esta distribución de tareas. Estos sistemas se conocen como arquitecturas de "casi todo compartido". El aspecto más crítico de este tipo de sistemas es el grado de rendimiento relativo respecto al número de procesadores presentes, debido a su creciente no lineal.
MPP (Massively parallel processing, o Multiprocesadores Masivamente Paralelos): Es una tecnología que compite contra la SMP, en la que los sistemas suelen ser casi independientes comunicados por intercambiadores de alta velocidad que permiten gestionarlos como un único sistema. Se conocen por ello como arquitecturas de "nada compartido". Su escalabilidad es mayor que la de los SMP.

Según Meta Group, las tendencias de mercado indican que las arquitecturas SMP aportan normalmente suficientes características de escalabilidad, con una mayor oferta y un menor riesgo tecnológico. Sin embargo, cuando las condiciones de escalabilidad sean extremas, se puede plantear la opción MPP.

No obstante, se están produciendo avances significativos en arquitecturas SMP, que han logrado máquinas con un crecimiento lineal de rendimiento hasta un número de 64 procesadores.

Recomendamos desde estas páginas, la visita a la dirección Internet:

http://www.tpc.org/bench.results.html

en donde la Transaction Processing Council (de la que son miembros ALR, Amdahl, Bull, Compaq, Data General, Dell, Digital, Fujitsu, HP, IBM, Intergraph, NCR , Siemens-Nixdorf, Sun o Unisys), realiza una comparativa entre las máquinas de sus miembros, proporcionando para diferentes modelos y diferentes configuraciones de Sistemas Operativos y Software de Base de Datos, un análisis de rendimiento (throughput), y un resumen de características (precio, número de procesadores, arquitectura y futuras versiones y fecha de disponibilidad).

Software de almacenamiento (SGBD)

Como hemos comentado, el sistema que gestione el almacenamiento de la información (Sistema de Gestión de Base de Datos o SGBD), es otro elemento clave en un Data Warehouse. Independientemente de que la información almacenada en el Data Warehouse se pueda analizar mediante visualización multidimensional, el SGBD puede estar realizado utilizando tecnología de Bases de Datos Relacionales o Multidimensionales.

Las bases de datos relacionales, se han popularizado en los sistemas operacionales, pero se han visto incapaces de enfrentarse a las necesidades de información de los entornos Data Warehouse. Por ello, y puesto que, como hemos comentado, las necesidades de información suelen atender a consultas multidimensionales, parece que unas Bases de Datos multidimensionales, parten con ventaja. En este sentido son de aplicación los comentarios que realizamos en el apartado de hardware, por requerimientos de prestaciones, escalabilidad y consolidación tecnológica.

Al igual que en el hardware, nuevos diseños de las bases de datos relacionales, las bases de datos post-relacionales, abren un mayor abanico de elección. Estas bases de datos post-relacionales, parten de una tecnología consolidada y dan respuesta al agotamiento de las posibilidades de los sistemas de gestión de bases de datos relacionales, ofreciendo las mismas prestaciones aunque implantadas en una arquitectura diseñada de forma más eficiente.

Esta mayor eficiencia se consigue instaurando relaciones lógicas en vez de físicas, lo que hace que ya no sea necesario destinar más hardware a una solución para conseguir la ejecución de las funciones requeridas. El resultado es que la misma aplicación implantada en una BD post-relacional requiere menos hardware, puede dar servicio a un mayor número de usuarios y utilizar mecanismos intensivos de acceso a los datos más complejos. Asimismo, esta tecnología permite combinar las ventajas de las bases de datos jerárquicas y las relacionales con un coste más reducido. Ambos sistemas aportan como ventaja que no resulta necesario disponer de servidores omnipotentes, sin que puede partirse de un nivel de hardware modesto y ampliarlo a medida que crecen las necesidades de información de la compañía y el uso efectivo del sistema.

Dejamos fuera del ámbito de esta guía el detallar cómo los proveedores de bases de datos han optimizado los accesos a los índices, o las nuevas posibilidades que ofrece la compresión de datos (menos espacio para la misma información lo que implica, entre otras ventajas, que más información se puede tener en caché), para lo que remitimos a la prensa especializada o a las publicaciones de los fabricantes.

Software de extracción y manipulación de datos

En este apartado analizaremos un componente esencial a la hora de implantar un Data Warehouse, la extracción y manipulación. Para esta labor, que entra dentro del ámbito de los profesionales de tecnologías de la información, es crítico el poder contar con herramientas que permitan controlar y automatizar los continuos "mimos" y necesidades de actualización del Data Warehouse.

Estas herramientas deberán proporcionar las siguientes funcionalidades:

Control de la extracción de los datos y su automatización, disminuyendo el tiempo empleado en el descubrimiento de procesos no documentados, minimizando el margen de error y permitiendo mayor flexibilidad.
Acceso a diferentes tecnologías, haciendo un uso efectivo del hardware, software, datos y recursos humanos existentes.
Proporcionar la gestión integrada del Data Warehouse y los Data Marts existentes, integrando la extracción, transformación y carga para la construcción del Data Warehouse corporativo y de los Data Marts.
Uso de la arquitectura de metadatos, facilitando la definición de los objetos de negocio y las reglas de consolidación.
Acceso a una gran variedad de fuentes de datos diferentes.
Manejo de excepciones.
Planificación, logs, interfaces a schedulers de terceros.
Interfaz independiente de hardware.
Soporte en la explotación del Data Warehouse.

A veces, no se suele prestar la suficiente atención a esta fase de la gestión del Data Warehouse, aun cuando supone una gran parte del esfuerzo en la construcción de un Data Warehouse. Existen multitud de herramientas disponibles en el mercado que automatizan parte del trabajo, para lo cual recomendamos la visita a la página Internet:

http://pwp.starnetinc.com/larryg/clean.html

en la que se proporciona una lista de mas de 100 herramientas de extracción y manipulación de datos, con links a sus páginas Internet, y una somera descripción de la funcionalidad cubierta por cada herramienta.

Herramientas Middleware

Como herramientas de soporte a la fase de gestión de un Data Warehouse, analizaremos a continuación dos tipos de herramientas:

Por un lado herramientas Middleware, que provean conectividad entre entornos diferentes, para ayudar en la gestión del Data Warehouse.
Por otro, analizadores y aceleradores de consultas, que permitan optimizar tiempos de respuestas en las necesidades analíticas, o de carga de los diferentes datos desde los sistemas operacionales hasta el Data Warehouse.

Las herramientas Middleware deben ser escalables siendo capaces de crecer conforme crece el Data Warehouse, sin problemas de volúmenes. Tambien deben ser flexibles y robustas, sin olvidarse de proporcionar un rendimiento adecuado. Estarán abiertas a todo tipos de entornos de almacenamiento de datos, tanto mediante estándares de facto (OLE, ODBC, etc.), como a los tipos de mercado más populares (DB2, Access, etc.). La conectividad, al menos en estándares de transporte (SNA LU6.2, DECnet, etc.) debe estar tambien asegurada.

Con el uso de estas herramientas de Middleware lograremos:

Maximizar los recursos ejecutando las aplicaciones en la plataforma más adecuada.
Integrar los datos y aplicaciones existentes en una plataforma distribuida.
Automatizar la distribución de datos y aplicaciones desde un sistema centralizado.
Reducir tráfico en la red, balanceando los niveles de cliente servidor (mas o menos datos en local, mas o menos proceso en local).
Explotar las capacidades de sistemas remotos sin tener que aprender multiples entornos operativos.
Asegurar la escalabilidad del sistema.
Desarrollar aplicaciones en local y explotarlas en el servidor.

Los analizadores y aceleradores de querys trabajan volcando sobre un fichero de log las consultas ejecutadas y datos asociados a las mismas (tiempo de respuesta, tablas accedidas, método de acceso, etc). Este log se analiza, bien automáticamente o mediante la supervisión del administrador de datos, para mejorar los tiempos de accesos.

Estos sistemas de monitorización se pueden implementar en un entorno separado de pruebas, o en el entorno real. Si se ejecutan sobre un entorno de pruebas, el rendimiento del entorno real no se vé afectado. Sin embargo, no es posible optimizar los esfuerzos, puesto que los análisis efectuados pueden realizarse sobre consultas no críticas o no frecuentemente realizadas por los usuarios.

El implantar un sistema analizador de consultas, en el entorno real tiene además una serie de ventajas tales como:

Se pueden monitorizar los tiempos de respuesta del entorno real.
Se pueden implantar mecanismos de optimización de las consultas, reduciendo la carga del sistema.
Se puede imputar costes a los usuarios por el coste del Data Warehouse.
Se pueden implantar mecanismos de bloqueo para las consultas que vayan a implicar un tiempo de respuesta excesivo.

Fuente : DataPrix

15 Motivos para el BI Open Source:

2009-01-15T13:28:00.001+01:00

1) Si usted es un Director de Informática, CIO, o cómo quiera que se llame en su empresa, si no se ha planteado YA, usar Open Source o soluciones SaaS en su empresa, probablemente le esperan unos años muy, muy complicados con presupuestos de IT cada vez más escasos, sin capacidad de optar a las nuevas mejoras tecnológicas y con un equipo humano que se irá quedando obsoleto.

2) El BI Open Source cada vez es más seguro, fiable, escalable y, sobre todo, no tiene barreras de entrada limitantes en coste... ni barreras de expansión (me fusiono con otra compañía, abro el análisis a toda la empresa, le doy acceso a mis clientes, lo abro al público....) que supondrían cientos de costosisimas licencias.

3) En épocas de crisis, ya no solo será importante analizar ventas, visitas, margenes, etc.. si no también costes, rentabilidad del canal, productivad, etc... y mejor tener herramientas flexibles y customizables que tener que 'comprar' paquetes nuevos.

4) NO tiene sentido, pagar por 2.000 licencias, cuando sólo unos 100 realmente lo usan.

5) Si eres Director de Informática y te gusta innovar, BI Open Source te proporciona ahorro de costes para dirigirlos a I+D y nuevos técnicos, y una tecnología abierta y puntera con la que crecer.

6) Ya hay muchas (y muy grandes compañías), que son 100% Open Source... y no se han colapsado!! es más, están entre las más valoradas.

7) Paradojicamente, en estos tiempos de crisis, grandes fabricantes propietarios están subiendo sus tarifas de licencias, en lugar de bajarlas, para cubrir sus márgenes.

8) Eso si, no hay que pensar que por ser Open Source, todo es gratis. No, lo que ocurre es que realmente pagarás por lo que usas y necesitas: soporte rápido, eficiente y profesional, servicios de consultoría que 'saben del negocio' y 'resuelven problemas', customizaciones que te dan la ventaja competitiva, etc...

9) A nivel histórico, esta es la primera crisis económica en la que existen alternativas viables y reales Open Source a los fabricantes tradicionales. Antes hubo crisis, pero IBM, Oracle, Microsoft y demás, no tenían verdaderas alternativas en presupuesto.

10) Muchos de los productos llamados propietarios, tienen un % muy elevedo de componentes 'open source' en su desarrollo, tanto por la calidad de estos componentes como por su ahorro de costes. Es decir, includo 'pagando licencias', gran parte de lo que pagas en Open Source.

11) En otros muchos casos, se están produciendo acuerdos entre software propietario software Open Source: HP, Ingres...

12) Cada vez es más evidente que hay que hacer el foco en las 'soluciones', más que en las herramientas o la tecnología.... es decir más en 'materia gris' conocedora del negocia y que aporte soluciones. Por tanto, destinar parte del dinero 'de software a materia gris'.

13) Que tal si aplicamos las matemáticas? (cero en el pago de licencias, bajo TCO, alto ROI)

14) Se trata de alternativas de menor riesgo por la cantidad invertida. Se pueden hacer 'pruebas con gaseosa'.

15) Las versiones salen mucho antes (puedes descargártelas cada noche), los bugs se corrigen antes, la comunidad detecta y corrige bugs. TU puedes corregirlos e incorporarlos al código.

Fuente: todobi.blogspot.com

Mil Disculpas

2009-01-14T08:16:00.002+01:00

Hola a tod@s,

La intencion de este Blog no era copiar sino recopilar en un unico sitio toda la informacion de interes que iba encontrando relacionada con el Business Intelligence.

Al principio, me imagino, que como casi todo el mundo tenia mis favoritos, donde guardaba las paginas con la informacion que me interesaba y mis documentos con toda la documentacion que iba recopilando.

Al final esto resultaba un incordio, ya que las paginas desaparecian, perdias la nocion de la informacion de los documentos, en fin un poco desastre, por eso se me ocurrio la idea del blog, un sitio de facil acceso, donde este la informacion accesible, que puedas consultarla desde cualquier lugar, en fin todo ventajas.

Este blog nacio a modo personal, para usarlo yo unicamente, que era como estaba en un principio, pero al final lo abri al mundo, para que todo el mundo que quisiese se aprovechase de la informacion recopilada.

Estos son los argumentos para explicar el porque hasta ahora no habia incluido las fuentes de la informacion. Descuido, Despite, simplemente que no habia caido en ello.
Ayer uno de vosotros me lo comento, y como tenia razon, aqui estoy yo rectificando e incluyendo las fuentes de la informacion (Gracias Josep y disculpame).

He añadido las fuentes en las ultimas entradas, que son de las que recuerdo las fuentes. A partir de este momento todas las entradas llevara su fuente para que todos sepamos de donde ha salido la información.

Saludos a tod@s

Reporting Empresarial

2009-01-13T09:01:00.006+01:00

El fundamento de la buena toma de decisiones.

Cada día millones de personas de todos los niveles en las empresas, desde la dirección, a los ejecutivos y trabajadores de las áreas de marketing, comercial, finanzas o recursos humanos, toman decisiones que afectan de forma positiva o negativa a las organizaciones para las que trabajan. La capacidad de tomar buenas decisiones es vital para el éxito de cualquier empresa hoy en día e igualmente importante es la rapidez con la que se toman.

Es indudable que en la actual economía global, de rápida progresión, las organizaciones y sus empleados deben tomar buenas decisiones de forma rápida para tener éxito. Del mismo modo,
nadie cuestiona el hecho de que la falta de información dificulta e incluso impide la toma de decisiones. Si los empleados tienen problemas debido a la calidad, el acceso y el uso de la
información, entonces la organización no rinde como debería hacerlo.

Un estudio que hemos llevado a cabo recientemente revela el alto coste que supone la falta de sistemas de toma de decisiones en las organizaciones europeas, hablamos de millones de euros al año en pérdidas de productividad y competitividad. De hecho, según datos de esta investigación,
el empleado europeo medio pierde una media de 67 minutos diariamente buscando información de la compañía, lo que equivale a un 15,9% de su jornada laboral. Para una organización
de 1.000 empleados que gane unos 50.000 euros al día esto equivale a 7,95 millones de euros al
año de salario perdido, todo ello por la búsqueda de información para tomar una decisión.

La toma de decisiones actual
Los empleados, sea cual sea el nivel que ocupan dentro de la organización,están cada vez más expuestos a todo tipo de datos, que abarcan desde listas simples con información detallada
sobre su actividad laboral, hasta avanzados motores de búsqueda que les ayudan a encontrar la mejor oferta de compra de un vehículo nuevo. La exposición a volúmenes de información cada vez mayores es un hecho.
Tomemos como muestra el dato que aporta IDC en este sentido: la cantidad de información creada y copiada se multiplicará por más de seis en 2010, hasta llegar a los 988 exabytes,
un índice de crecimiento compuesto del 57%. La cifra pone de manifiesto la dependencia de disponer de información precisa para llevar a cabo una toma de decisiones adecuada.
Sin embargo, proporcionar demasiados datos a una persona no significa que cuente con información apropiada, el contexto es vital para dar sentido a dicha información. Esto hace la
situación si cabe más compleja. Las circunstancias que rodean a una persona y las decisiones que ésta pueda tomar determinan el tipo de información y su conveniencia. Dado que este proceso
puede ser desestructurado, resulta difícil presentar los datos de un modo que tenga sentido para los usuarios.
Las organizaciones han adoptado distintos enfoques a la hora de proporcionar información a sus empleados, desarrollando sistemas ERP, CRM y SCM para finanzas, ventas, marketing y logística respectivamente. Sin bien muchos de estos sistemas proporcionan información relevante a las personas pertinentes, los altos ejecutivos y estrategas solían precisar una visión más holística y esto fue lo que originó la demanda inicial del software de Business Intelligence y las tecnologías
de análisis y reporting empresarial.
Sin embargo, con el aumento de la complejidad y dinamismo de las empresas, cada vez más empleados precisan una perspectiva más amplia de la empresa y la capacidad de acceder a varias fuentes de datos para poder tomar decisiones. Esto ha impulsado una segunda oleada: el business
Intelligence Operacional, por medio del cual las organizaciones están extendiendo las soluciones de reporting y análisis a todo el organigrama de la empresa, para permitir a cualquier empleado, así como a socios externos y proveedores, tomar decisiones mejores, más rápidas y fundadas,
basadas en los datos disponibles.
El reto del Business Intelligence Para llegar a este nuevo horizonte del Business Intelligence Operacional donde todos los empleados, socios y proveedores de la compañía puedan acceder a los datos e implicarse en la toma de decisiones de la empresa es necesario proporcionar un entorno de reporting empresarial que resulte sencillo de utilizar, que facilite el acceso a la información y que tenga la capacidad para presentar dicha información a través de herramientas familiares y bien arraigadas en la empresa.
Durante décadas, el Business Intelligence ha proporcionado una manera rápida y efectiva de recopilar, abstraer, presentar, formatear y distribuir la información de sus fuentes de datos corporativos, permitiendo a los profesionales de la empresa, tanto dentro como fuera de la organización, visualizar y analizar datos precisos sobre las actividades fundamentales del negocio y utilizarlos para mejorar la toma de decisiones y la planificación estratégica.
Sin embargo, la complejidad de las herramientas tradicionales suponía una carga de trabajo enorme para los departamentos de Tecnologías de la Información (TI) de las empresas. Los
desarrolladores normalmente construían los informes usando complejos lenguajes de programación o más recientemente con herramientas de diseño WYSIWYG. Los informes resultantes eran puestos a disposición de los usuarios finales a través del correo electrónico, navegadores Web o mediante copias impresas.
Los constantes cambios en las necesidades del negocio, típicos del entorno económico actual, han derivado en nuevos requerimientos en cuanto a la generación de informes por parte de los usuarios finales. Esta situación hace que los desarrolladores tengan que sacar adelante un volumen importante de proyectos relacionados con el reporting, desviando su atención
de otras iniciativas tecnológicas más cruciales para la empresa.
Con el paso de los años, las soluciones de BI han evolucionado para proporcionar herramientas más intuitivas y fáciles de usar. Las herramientas desktop de reporting ponían a disposición del
usuario final los datos corporativos al poder generar desde sus ordenadores de sobremesa los informes, pero éstos únicamente proporcionaban información estática y superficial con poco valor
estratégico. Otro tipo de herramientas surgidas, como las OLAP ofrecían el nivel de detalle analítico requerido, pero su instalación no se llevaba a cabo en toda la organización debido al tiempo y coste asociados a su despliegue, mantenimiento, soporte y formación de los usuarios.
Esto dejaba a los usuarios sin perfil técnico en la misma situación con la necesidad de acceder e interactuar con la información de misión crítica, pero sin el tiempo o el conocimiento necesario para generar sus propios informes.
Esta problemática ha hecho que muchas organizaciones no aprovechen todo el potencial que brinda el Business Intelligence dentro de la empresa, ya que utilizan una fracción de sus datos, en concreto menos del veinte por ciento. Y, según GIGA Group las compañías complican aún más el problema poniendo los datos a disposición de tan sólo el cinco por ciento de los usuarios.
El mal aprovechamiento del activo más vital de la empresa "la información" redunda en una menor productividad y pone en peligro la capacidad de la compañía para optimizar verdaderamente su rendimiento.
Para invertir esta tendencia y proporcionar información significativa a un gran número de usuarios de cualquier nivel minimizando a su vez la dependencia del personal del departamento
de TI y sin necesidad de forzar al usuario a aprender a utilizar complejas herramientas de Business Intelligence es necesario crear entornos de reporting intuitivos y que no resulten
costosos ni difíciles de instalar.

El poder del reporting en manos de los usuarios
Como hemos mencionado anteriormente, el reto para las organizaciones de hoy en día es encontrar la manera más rentable y segura de instalar aplicaciones de Business Intelligence que,
a su vez, ofrezcan a los usuarios un método rápido y sencillo para acceder a la información que necesitan para realizar una toma de decisiones inteligente.
Una solución sería la instalación de herramientas de reporting ad hoc. Esto resulta sencillo para usuarios avezados que sepan manejarse entre la complejidad de los datos, sin embargo exponer
de este modo la información corporativa a cualquier tipo de usuario puede que no sea la manera más segura o el mecanismo más eficiente; sin mencionar los significativos costes de formación que conlleva cualquier herramienta ad hoc. Por ello es recomendable una aproximación tipo Guided Ad Hoc, que consiste en combinar la sencillez y simplicidad que aportan las plantillas de informes con la disponibilidad y accesibilidad de Internet, para poner fácilmente a disposición de
los usuarios finales informes interactivos.
El resultado es que el usuario es capaz de generar sus propios informes en un entorno cómodo y familiar, tan rápida y fácilmente como si estuviera realizando una compra online.
Con este modelo se acelera el proceso de toma de decisiones y se reduce, en último lugar el tiempo dedicado a la búsqueda de información. Este método resulta tan eficiente y efectivo
que los expertos coinciden en que los usuarios finales lo utilizarán mucho más frecuentemente para resolver sus necesidades de información crítica. De hecho, se ha comprobado que las
empresas que están haciendo uso de este tipo de tecnologías han sobrepasado el nivel de utilización de sus soluciones de Business Intelligence, del cinco por ciento al cuarenta por ciento entre todo tipo de usuarios. Son estas empresas las que están haciendo realidad el Business Intelligence Operacional, aprovechando todo el potencial que brindan este tipo de sistemas, que se perfilan como herramientas clave para optimizar el rendimiento de los procesos clave de negocio.

Fuente: Articulo escrito por Paloma Zumel en la revista "Gestion del Rendimiento"

CIF vs MD : Dos enfoques clásicos en el diseño de la arquitectura de un Data Warehouse

2009-01-12T08:58:00.006+01:00

Bill Inmon y Ralph Kimball son dos de las personalidades referentes y más influyentes en el área de data warehousing, y responsables de los dos enfoques a los que hacemos referencia.
Bill Inmon es el creador del término Data Warehouse así como del CIF, conjuntamente con Claudia Imhoff. Es considerado por todos el padre de la disciplina. Por su parte, Ralph Kimball es un gurú del diseño de data warehouse y creador del enfoque MD.

En múltiples disciplinas existen diferentes enfoques para abordar un mismo concepto o problema. La existencia de dichos enfoques enriquece sobremanera la propia disciplina. Siendo más generalista, eso mismo sucede entre diferentes áreas del conocimiento y produce que el avance de la ciencia no se enquiste.

A modo de ejemplo, pensemos en el papel que juega la geometría diferencial no euclidiana1 (un enfoque completamente abstracto) en el modelo de partículas elementales de la física (un enfoque
que tiene el objetivo de describir la realidad a nivel subatómico).

El diseño de un Data Warehouse, como disciplina que ha alcanzado ya un grado de madurez considerable a lo largo de estos años, también presenta diferentes enfoques. En el presente
artículo hablaremos sobre dos de ellos y sus ventajas e inconvenientes.

Introducimos a continuación MD (Multidimensional Architecture) y CIF (Corporate Information Factory). Dos enfoques clásicos que conviene revisar antes de considerar enfoques mucho más modernos o concretos.

MD
La arquitectura MD fue desarrollada por el Dr. Ralph Kimball; está basada en la premisa que todos los análisis Business Intelligence tiene su origen en una estructura multidimensional. Quizá
sea conveniente referirnos a la definición que tiene Kimball de un data warehouse: una copia de las transacciones de datos específicamente estructurada para la consulta y el análisis.
Vayamos un poco más allá. Partamos del hecho que Kimball acuñó la siguiente frase: “El Data Warehouse es la unión de todos los Data Marts de una entidad”.
Podemos, entonces, entender de forma natural que la presente metodología:

Es ascendente (bottom-up).
Está basado principalmente en uso de Data Marts independientes.

La arquitectura MD está separada en dos capas de procesos y servicios:

Back Room: a groso modo la cocina de nuestro sistema. Se realizan todos los procesos ETL para conseguir los datos de las fuentes de origen (involucrando procesos de data quality, data staging u otros), pero además también se consideran aquellos procesos ETL que alimenta cada uno de los data marts independientes existentes en la organización. Kimball distingue además dos tipos de data marts:

Atomic Data Marts: contienen la información al nivel de detalle máximo.
Aggregated Data Marts: contienen la información departamento, por áreas o funcional que puede estar alimentado por los anteriores o directamente de la Staging Area.

Front Room: consistente por las herramientas de análisis que usan la información consolidada en los data martsde la back room. Es por lo tanto claro, que para cada unidad de negocio se creará un data mart (o varios) sin tener en cuenta las necesidades de otra unidad. No prima la visión única del dato.

CIF
CIF, enfoque creado por Bill Inmon, es una metodología descendente (topdown).
Se basa en la creación de un repositorio de datos corporativo como fuente de información consolidada, persistente, histórica y de calidad. Consiste como el anterior enfoque en dos
fases:

Getting Data In: incluye los procesos ETL de las fuentes de origen (que incluyen Data Quality, Data Staging u otros procesos), creación del Data Warehouse Corporativo y, en caso de ser necesario, ODS y Staging Area.
Getting Information Out: procesos ETL que distribuyen la información a los diferentes data marts que responden necesidades diferentes (lo que llamamos Data Delivery). Las herramientas de explotación de datos atacan los Data Marts y en casos excepcionales al mismo Data Warehouse Corporativo.

Como es fácil comprender la búsqueda de un enfoque único para cada¡ uno de los conceptos de la organización prima en este enfoque. Por ejemplo, hay veces que el concepto de cliente se entiende de forma sutilmente diferente por los diversos departamentos existentes. Bajo esta metodología se buscaría un entendimiento común.

CIF vs MD
Al final, necesitamos categorizar los conceptos para poder contextualizarlos.
La breve comparativa permite lo anterior.
Queda fuera del alcance de esta breve introducción, cómo se abordan en cada uno de los enfoques estos puntos: mantenimiento, volatilidad, costes de implementación, funcionalidad,
flexibilidad o complejidad.

Conclusiones
Existen situaciones en las que una delas arquitecturas clásicas proporciona ventajas competitivas sobre la otra.
Hecho que hará escoger dicha arquitectura.
Normalmente la realidad es que ambas arquitecturas se combinan para proporcionar la mejor respuesta a las necesidades del cliente o incluso es factible encontrarse otros enfoques más o menos afortunados. Lo importante, en definitiva, es conocer todos los enfoques posibles para no tener de reinventarse la rueda en el momento de hacer un diseño de un Data Warehouse.
Es decir, sólo a partir del conocimiento profundo podemos ir más allá de las propias fronteras.

Fuente: Articulo escrito por Josep Curto en la revista "Gestion del Rendimiento"

Las novedades de IBM Cognos Go! ofrecen a los usuarios de empresa una visión personalizada de la información estratégica

2009-01-12T08:51:00.003+01:00

Los nuevos cuadros de mando, la inteligencia de ubicación para trabajadores móviles y las capacidades de búsqueda BI de Cognos 8 Go! ofrecen a los usuarios de empresa, en la oficina o en la calle, información relevante bajo demanda.

Cognos ha desvelado las grandes mejoras introducidas en su gama de software IBM Cognos 8 Go! Estas nuevas capacidades amplían el alcance de IBM Cognos 8 BI v4, por lo que los usuarios de empresa pueden crear, acceder e interactuar con vistas personalizadas de la información sobre el rendimiento, para tomar con rapidez las decisiones informadas que permitirán impulsar el rendimiento del negocio.

Un reciente estudio de TDWI concluyó que el porcentaje de usuarios BI activos que utilizan una herramienta BI por lo menos una vez a la semana en sus organizaciones ha aumentado del 18% en 2005 al 24% en 2008. Los entrevistados citaron numerosos factores que aceleran la utilización del BI, incluyendo el suministro de los datos a través de un cuadro de mando (46%) y la interactividad de los informes y el auto-servicio (44%), entre otros1. Para continuar resolviendo estas necesidades, Cognos está ofreciendo nuevos métodos más flexibles y orientados al cliente para que los usuarios permanezcan conectados al negocio con un acceso personalizado a la información fiable, a través de cuadros de mando familiares, dispositivos móviles, navegadores web, hojas de cálculo, procesadores de texto o interfaces de software de presentación.

Así, Cognos presenta una nueva capacidad de cuadro de mando denominada IBM Cognos 8 Go! Dashboard, nuevas capacidades de localización para IBM Cognos 8 Go! Mobile y nuevas capacidades de búsqueda avanzadas para los datos estructurados y no estructurados, dentro de IBM Cognos 8 Go! Search. Estas capacidades dan a los departamentos de tecnología de la información (TI), la oportunidad de extender de forma segura su estructura de gestión del rendimiento, para ayudar a más usuarios de empresa a hallar rápidamente la información que necesitan para tomar las mejores decisiones, contribuir a la información de la que otros dependen y emprender las acciones necesarias para gestionar mejor el rendimiento.

IBM Cognos 8 Go! Dashboard suministra de forma dinámica gráficos basados en Flash para que los usuarios de empresa y los directivos puedan crear rápidamente cuadros de mando personalizados que reflejan la información sobre rendimiento, fiable y consistente, proporcionada por IBM Cognos 8 BI u otras fuentes de la empresa.

Las aplicaciones externas, como los feeds RSS o los elementos relevantes de los informes preconfigurados, cuadros de mando o métricas, también pueden incorporarse directamente en el cuadro de mando, lo que permite a los usuarios de empresa obtener una visión completa de la información que más les preocupa.

Los nuevos avances en IBM Cognos 8 Go! Mobile permiten a los usuarios de empresa y directivos móviles ver e interactuar con mayor facilidad, a través de sus dispositivos móviles, con los mismos informes que podrían encontrar en sus escritorios, para una eficaz toma de decisiones independientemente de su ubicación. Frente a las soluciones de la competencia, el producto suministra nuevas capacidades de inteligencia de negocio basadas en la ubicación, que utilizan información GPS sobre los dispositivos Blackberry, Symbian o Windows Mobile del usuario, para crear informes que se ajustan automáticamente basándose en la ubicación del usuario.

Recientes estudios sobre los avances en convergencia del BI y los sistemas de Búsqueda han revelado que la información corporativa no estructurada, como los archivos de usuarios, comentarios de clientes, imágenes médicas o el contenido web y audiovisual, está creciendo a un ritmo del 63%. El crecimiento explosivo de este tipo de información empresarial ha contribuido a la convergencia de las categorías BI y Búsqueda. Ha creado una demanda de nuevas capacidades de búsqueda BI para proporcionar un rápido y fácil acceso tanto al contenido BI clasificado y relevante como a la información no estructurada.

La versión recién actualizada IBM Cognos 8 Go! Search v4 permite a cualquier usuario de negocio extender las capacidades para la toma de decisiones de IBM Cognos 8 BI mediante el acceso seguro y la creación dinámica de contenido BI, utilizando criterios de búsqueda sencillos con palabras clave. El software trabaja con las aplicaciones de búsqueda empresarial más populares, como IBM OmniFind Enterprise Edition, Google, Yahoo y Autonomy, por lo que los usuarios pueden ver contenido BI estructurado y de confianza, y datos no estructurados como los documentos Word y los PDFs, del mismo modo que lo verían en su interfaz familiar.

Los usuarios pueden buscar todos los metadatos completamente indexados así como los títulos y descripciones dentro de un informe. La autoría y exploración asistida por la búsqueda ofrece opciones para ajustar las peticiones o analizar los cubos de datos basándose en los términos de búsqueda. Estas capacidades aceleran el acceso a la información de negocio más relevante independientemente de las similitudes de nombres entre informes, lo que ayuda a los usuarios de empresa a ajustar rápidamente las queries según lo necesiten, y libera a los departamentos de TI de repetir continuamente la creación de los informes más utilizados, pudiendo dedicar más tiempo a las iniciativas de negocio estratégicas.

El software está completamente integrado con la administración basada en web y los parámetros de seguridad fijados por los administradores de TI para IBM Cognos 8 BI. Esta integración proporciona un enfoque centralizado y eficaz para la administración y la seguridad, y atiende eficazmente dos áreas de preocupación comunes para los departamentos de TI que han de lidiar con recursos limitados, por lo que desean ofrecer más autonomía a los usuarios de empresa pero necesitan un punto de administración único y la seguridad de que las políticas corporativas de autenticación se van a mantener.

“Estas nuevas mejoras para nuestra gama Go! suministran información de rendimiento del negocio para ayudar a cada área de la organización a gestionar estratégicamente la información que sea más pertinente para ellos”, señala Javier Izquierdo, director de marketing en Cognos España. “Negocio y TI ganan una mayor autonomía, tanto si los empleados están en la oficina buscando, monitorizando y analizando los resultados del negocio como si están en la calle buscando nuevas actualizaciones o información relevante de carácter geográfico”.

La gama de software IBM Cognos 8 Go! es un componente clave de la estrategia Information Agenda de IBM, un nuevo enfoque que incluye software y servicios de consultoría específicos para cada sector, diseñados para ayudar a los clientes a utilizar la información bajo demanda como un activo estratégico en sus negocios.

Fuente: Articulo escrito sacado de la revista "Gestion del Rendimiento"

MicroStrategy anuncia el soporte de la Plataforma Adobe Flash para la creación de aplicaciones ricas de internet con Business Intelligence Integrado

2009-01-12T08:46:00.003+01:00

MicroStrategy, uno de los proveedores líderes de software de business intelligence (BI), ha anunciado que la última versión de su software, MicroStrategy 8, ofrece soporte integrado para componentes clave de la Plataforma Adobe Flash.

El nivel de integración mejorado de MicroStrategy Adobe Flex Builder 3, un componente fundamental de la Plataforma Flash, proporciona un nuevo rango de oportunidades de entrega y consumo de BI a las más recientes aplicaciones y mash-ups. Ahora los desarrolladores de Flex no necesitan convertirse en expertos en BI para poder aprovechar las posibilidades del BI en sus aplicaciones ricas para internet (rich Internet applications o RIAs). Las nuevas extensiones
de MicroStrategy para el framework open source de Flex, incluyendo las controles de visualización y selección, son ofrecidos como componentes de Flex, haciendo que añadir potentes capacidades de Bi a sus aplicaciones sea muy rápido y sencillo para los desarrolladores de Flex.
Al combinar las avanzadas capacidades analíticas y la escalabilidad hasta miles de usuarios y terabytes de datos de MicroStrategy con la funcionalidad y características Adobe Flex Builder 3, los desarrolladores contarán con un amplio arsenal para crear potentes RIAs con BI integrado.

Gracias a este nuevo tipo de RIAs, los usuarios podrán combinar información histórica, predictiva y operacional para obtener una perspectiva más completa de sus áreas de negocio. Estos interfaces muy interactivos y fáciles de utilizar pueden ser desplegados en un navegador Web utilizando el ampliamente extendido Adobe Flash Player, o fuera de un navegador a través de Adobe AIR.

“MicroStrategy está encantado de trabajar con Adobe para proporcionar esta profunda integración entre business intelligence y la tecnología de aplicaciones ricas para Internet”, ha comentado Sanju Bansal, Director de Operaciones de MicroStrategy. “Hay una creciente
comunidad de muy activos y creativos desarrolladores de Flex que están siendo pioneros en la creación de las más novedosas aplicaciones Web. MicroStrategy esta muy satisfecha de poder asistir directamente a estos desarrolladores con una tecnología de BI que ha sido diseñada expresamente para ellos”.
Fuente: Articulo escrito sacado de la revista "Gestion del Rendimiento"

Information Builders presenta WebFOCUS Performance Manager Framework

2009-01-12T08:40:00.003+01:00

Entre sus nuevas funcionalidades destaca la capacidad para generar cuadros de mando personalizables, publicar métricas en blogs, alertas móviles y mayores capacidades de análisis, strategy authoring, así como asistentes de fácil manejo.

Information Builders, compañía independiente líder en sistemas de Business Intelligence (BI), ha anunciado la disponibilidad en castellano de WebFOCUS Performance Manager Framework 4 (PMF). Esta solución de gestión del rendimiento operacional ofrece a las empresas las herramientas de comunicación, colaboración, análisis y estrategia necesarias para obtener una completa visibilidad de su negocio, aumentar su competitividad en el mercado y mejorar su rendimiento.
WebFOCUS PMF está basada en la experiencia de Information Builders en implementación de soluciones de gestión del rendimiento. Una de sus nuevas funcionalidades es la capacidad para organizar de manera sencilla métricas con el fin de lograr una comunicación más fluida en la empresa y facilitar el alineamiento racional con los objetivos financieros, operacionales, de riesgo, cumplimiento y gobierno. PMF puede ser adquirida por módulos que las empresas pueden ir incorporando a medida que crece su negocio.
Basada en las últimas tendencias de la industria, las peticiones de los clientes y la cultura de innovación de Information Builders, PMF 4 proporciona a las empresas el medio adecuado para la gestión del rendimiento operacional.
Construido sobre las probadas plataformas de BI —WebFOCUS— e integración empresarial —iWay Software— de Information Builders, PMF es una solución abierta y paquetizada que se integra directamente con los sistemas operacionales y se puede adaptar según varíen las necesidades de la empresa.

“PMF es una solución fácil de gestionar que permite a las empresas implantar rápidamente la gestión del rendimiento sin tener que afrontar largos proyectos de TI de forma que todos los usuarios contribuyen a la gestión del sistema”, señala Manuel del Pino, director preventa de Information Builders Ibérica. La ampliación y personalización de PMF puede llevarse a cabo utilizando los mismos componentes de WebFOCUS sobre los que está construida.

La solución ha sido diseñada para gestionar, medir y analizar el rendimiento tanto de procesos horizontales —del departamento financiero, recursos humanos, TI, call center, etc— como de mercados verticales (servicios financieros, cadena de suministro, sanitario o retail).

Mejor comunicación en la empresa
PMF 4 mejora la comunicación ya que proporciona los medios para sintetizar métricas, comunicar tendencias de rendimiento, distribuir información a los partícipes, así como mostrar y realizar un seguimiento de los proyectos y procesos relacionados.

El nuevo cuadro de mando actualizado de PMF incluye gadgets de información, grids pre-construidos, gráficos y herramientas que permiten a los usuarios evaluar de un solo vistazo el
estado de los indicadores de rendimiento clave (KPIs) y estrategias. Los gadgets simplifican la creación de páginas con cuadros de mando complejos que muestran múltiples métricas a la vez. La atención del usuario se guía de manera sencilla a través de iconos que muestran cuando un proyecto está alineado, cuando una métrica fundamental está por debajo del rendimiento o bien cuando alguien introduce un comentario. Un clic sobre cualquier gadget actúa como un switchboard de respuestas o acciones a llevar a cabo.

La funcionalidad Web 2.0 permite la colaboración dinámica
Al incluir capacidades de colaboración Web 2.0, PMF 4 permite a los usuarios integrar su trabajo con el de sus colegas para poder descubrir tendencias, realizar análisis, generar informes, documentarlos y actuar.
Por ejemplo, cualquier KPI puede ser publicado en un blog para que los usuarios a lo largo de la cadena de toma de decisiones puedan entender qué se está haciendo, por qué y cómo lograr el resultado deseado. PMF también ofrece la capacidad para publicar artículos sobre un tema en Internet y enviar alertas de manera que los usuarios pueden tomar medidas y comprometer a otros para cambiar los resultados operacionales. Las alertas pueden programarse para que se ejecuten automáticamente, y una vez recibidas, pueden ser comentadas y reenviadas para actuar en consecuencia.

Herramientas predictivas para el análisis
Las nuevas herramientas de análisis y localización de información permiten a los usuarios analizar tendencias, realizar un seguimiento y descubrir las causas subyacentes al rendimiento de la organización. Diseñada para los usuarios del área operacional, PMF incluye la capacidad para realizar análisis personalizados de tendencias, análisis condicionales, así como análisis OLAP y predictivos tradicionales que ofrezcan una visión fiable del futuro. Además de la incorporación de más de 100 cuadros de mando preconstruidos, PMF ofrece Analysis Designer, una herramienta para crear consultas, informes y gráficos personalizados.

Fuente: Articulo escrito sacado de la revista "Gestion del Rendimiento"

IBM Cognos lanza un nuevo software de gestión de dimensiones para usuarios de empresa

2009-01-12T08:35:00.003+01:00

IBM Cognos 8 Business Viewpoint proporciona a los usuarios de empresa un lugar único para crear, mantener, gobernar y compartir las dimensiones del negocio, logrando así una visión consistente del rendimiento de la empresa

Cognos, una compañía IBM, líder en soluciones de Business Intelligence y para la gestión del rendimiento, presenta un nuevo software de modelado colaborativo para que los usuarios de empresa puedan crear, mantener, gobernar y compartir sus perspectivas de negocio y organizar con rapidez la información estratégica para mejorar la toma de decisiones y la gestión del rendimiento.

IBM Cognos 8 Business Viewpoint es una nueva solución para la gestión del rendimiento que atiende los crecientes desafíos ligados a la globalización, la concentración sectorial y el gobierno de datos a los que se enfrentan hoy las empresas.

Estas organizaciones modernas necesitan un proceso de negocio intuitivo, orientado a los flujos de trabajo, que permita a los analistas financieros, responsables de línea y de marca y modeladores de datos estructurar sus propias visiones de la información clave, y soporta los múltiples niveles de autorización requeridos para gestionar el rendimiento del negocio a lo largo de la organización. Estas capacidades son esenciales tanto si la organización está determinando una forma eficaz de estandarizar las relaciones entre compañías operativas como si está gestionando las dimensiones de productos y clientes y sus estructuras de presentación asociadas.

IBM Cognos 8 Business Viewpoint proporciona al usuario de negocio capacidades para la gestión global de dimensiones, que le ayudan a mantener conjuntos de jerarquías y dimensiones del negocio para producir nuevos conocimientos, llegar fácilmente a todos los datos y alinear rápidamente tanto los sistemas como las personas con la última visión del negocio en las áreas de operaciones y finanzas. Por ejemplo, los responsables de operaciones pueden querer que sus
jerarquías de ventas reflejen la última reorganización, mientras que los analistas financieros pueden desear realinear sus centros de costes para tener visibilidad sobre las visiones planeadas y actuales.

El producto es complementario a las soluciones de gestión de datos maestros, como IBM InfoSphere MDM Server, que sincroniza los dominios de datos maestros -como clientes y productos- en todos los sistemas operacionales y transaccionales de la empresa.

Específicamente diseñado para la gestión del rendimiento, IBM Cognos 8 Business Viewpoint permite a los usuarios de negocio gestionar aquellas dimensiones en constante transformación que son más importantes para su cargo en el negocio, con el objetivo de obtener un punto de vista consistente y compartido sobre los resultados, operaciones y estrategia. Estas dimensiones pueden estar asociadas a las visiones de la organización, actuales o futuras, de informes, planes o previsiones para áreas del negocio como los centros de costes, canales o activos financieros.

“Con IBM Cognos 8 Business Viewpoint, es fácil visualizar la manera en que los responsables de producto podrían modificar las dimensiones del negocio alterando su visión de las líneas de producto y revisando cómo sus cambios afectan a otras áreas de la empresa”, señala Francisco Pino, director de servicios en Cognos España. “Sin afectar a los datos subyacentes ni dar problemas a TI, los usuarios de negocio pueden por ejemplo establecer la forma en que se recombinan las líneas de producto a través del simple acto de arrastrar y soltar, y después crear un flujo de trabajo para garantizar que el responsable de negocio adecuado ha sido alertado sobre los cambios propuestos y tiene la posibilidad de aprobar las recomendaciones”.

IBM Cognos 8 Business Viewpoint está construido sobre la plataforma empresarial IBM Cognos 8. Su moderna arquitectura SOA suministra un método abierto para el acceso a los datos, por lo que los arquitectos pueden aprovechar los estándares existentes y las soluciones de gestión de procesos de negocio. Los cambios efectuados en el pasado en las dimensiones pueden localizarse a través de IBM Cognos 8 Planning e IBM Cognos 8 Business Intelligence, de tal modo que los analistas de negocio y los administradores de sistemas puedan validar los cambios propuestos y hacer que las dimensiones master estén disponibles para el reporting, análisis, planificación empresarial y cuadros de mando a lo largo de todo el sistema de gestión del rendimiento.

Para atender las demandas de gobierno e integridad de los datos, IBM Cognos 8 Business Viewpoint almacena de forma centralizada las dimensiones para permitir una visión común para toda la organización. Reemplaza además cualquier esfuerzo manual con procesos revisables, automatizados y auditables. Esto permite a los administradores de datos o analistas de negocio garantizar la conformidad con los estándares de la organización o las regulaciones externas.

Una pista de auditoría documentada proporciona un acceso, con tan solo un click, al linaje de los datos, mientras las funciones de seguridad garantizan el control de versiones correctas y el conocimiento de la dirección sobre los cambios y las aprobaciones para mantener la integridad del sistema. El flujo de trabajo soporta también la colaboración y las aprobaciones a lo largo de múltiples grupos de usuarios.

Fuente: Articulo escrito sacado de la revista "Gestion del Rendimiento"

Pentaho ofrece una mayor simplicidad y escalabilidad en la nueva versión de su Suite de Business Intelligence

2009-01-12T08:32:00.003+01:00

Potentes características, servicios de valor añadido y un menor coste hacen de Pentaho BI Suite Enterprise Edition Version 2 la elección inteligente para compañías de todos los tamaños.

Pentaho, la alternativa comercial open source de business intelligence (BI), ha lanzado Pentaho BI Suite Enterprise Edition Version 2, la última versión de la solución de BI que abandera la compañía, proporcionando así una completa solución que permite a las empresas de cualquier tamaño un despliegue de Business intelligence a un coste muy asequible. Al proporcionar al usuario final una simplicidad y una escalabilidad mejoradas, Pentaho BI Suite Enterprise Edition Version 2 cumple la promesa del software comercial open source de ofrecer una solución empresarial con soporte completa a un coste de propiedad realmente bajo.
“Compañías de todos los tamaños están cada vez más interesadas en soluciones de BI que les ayuden a mejorar su toma de decisiones e incrementar la eficiencia de negocio en estos tiempo de incertidumbre económica”, comentó Richard Daley, CEO de Pentaho. “Desafortunadamente, los costes iniciales y recurrentes asociados con las soluciones propietarias de BI se convierten en un inaceptablemente alto coste total de propiedad. Pentaho rompe estas barreras de coste con un modelo de precios basado en suscripción para si probada y escalable suite de BI. Pentaho BI Suite Enterprise Edition Version 2 es fácil de probar, fácil de comprar, y fácil de tener”.
Pentaho BI Suite Enterprise Edition Version 2 ofrece completas características de BI, incluyendo reporting, análisis, dashboards, minería e integración de datos. Esta última versión se enfoca en hacer más simple para los usuarios el acceso a las ricas características de BI de la suite, y para los administradores facilitar el despliegue y escalabilidad de la solución.

Fuente: Articulo escrito sacado de la revista "Gestion del Rendimiento"

Características de los KPI

2008-11-21T13:14:00.001+01:00

Los KPI constituyen un conjunto de métricas enfocadas en medir aquellos aspectos de performance organizacional que impactan en mayor forma en el éxito actual y futuro de la empresa. En cualquier organización sólo podemos hallar pocos KPI (generalmente no más de 10) que cumplan con ciertas características; ellas son:

• Métricas no financieras (que no puedan expresarse en cifras monetarias)
• Alta frecuencia, generalmente 24/7 (KPI no se miden mensualmente)
• Bajo supervisión directa del GG o directivos del alto staff
• Empleados conscientes de la importancia de la métrica y de las acciones correctivas que requiere
• Responsabilidad ligada directamente a los responsables individuales o a equipos.
• Efecto crítico sobre la mayorías de las restantes métricas que puedan incluirse en el BSC
• Originadotes de acciones positivas sobre la totalidad de la empresa

Las métricas monetarias no son las mejores a la hora de buscar lo que realmente puede impulsar el cambio. Esto es así porque las métricas monetarias expresan resultados. Pero los inductores de dichos resultados son otras acciones relacionadas con marketing, operaciones, productos, servicios, etc. que son las que terminan en resultados.

Los KPI más importantes deben ser monitoreados en forma constante, casi diríamos 24/7. Si Ud. selecciona un KPI de frecuencia mensual probablemente sea un indicador de resultados en lugar de un inductor de acciones. KPI son generalmente métricas de acción hacia el futuro, en contraposición de métricas que expresan el resultado ya pasado, histórico. Un error muy común al diseñar un BSC es seleccionar indicadores que expresan datos históricos. Esos indicadores no son KPI ni lo serán nunca. Por ejemplo el indicador Satisfacción de Cliente, que toma datos sobre encuestas tomadas a los clientes durante los últimos 6 meses no es un KPI.

Cuando una métrica es un verdadero KPI cuenta con la dedicación y atención constante del GG para su seguimiento. Tener que defender un error ante el GG es algo que a ningún empleado le gusta hacer ni repetir pues compromete su carrera en la empresa. Las soluciones a los problemas se hallan mucho más rápido cuando el GG está atento al problema.

Un buen KPI dice de inmediato qué acciones deben ejecutarse de inmediato. Por ejemplo, los KPI de impuntualidad en los vuelos de BA eran una manera de decir a todo individuo involucrado en el proceso que había que hacer algo rápido para solucionar el problema. Desde operarios de limpieza, caterers, aeromozas, tripulantes hasta pilotos y oficiales de tráfico trabajan en equipo y producían soluciones mágicas para ahorrar un minuto aquí y otro allá sin menoscabar la calidad del servicio o incluso aumentarlo.

Un KPI debe ser lo suficientemente claro como para identificar perfectamente al responsable del mismo. En otras palabras el GG debe poder tomar el teléfono y preguntar ¿Por qué? Directamente a quien puede solucionar el problema. En ese sentido las métricas financieras no son buenos KPI pues no se las puede vincular directamente con un responsable sino que son el resultado del trabajo de muchos responsables. ¿Podemos imaginar al GG de una gran corporación llamar a su gerente financiero y decirle: Juan, quiero que aumentes la tasa de retorno de capital usado en el día de hoy??

Un correcto KPI tendrá impacto sobre todas las Perspectivas e influirá en casi todo otro tipo de métrica que esté en el Balanced Scorecard. Por ejemplo reducir la demora en la salida de vuelos mejorará las métricas sobre mejoras en los servicios de tierra, ya que el personal de esa área perderá menos tiempo en “apagar incendios” que los distraen de tareas básicas de atención a los pasajeros.

Cuatro tipos de métricas

De mi trabajo de investigación, capacitación e implementación llego a la conclusión que hay cuatro tipos definidos de métricas relacionadas con la performance:

Tipos de métricas de performance

IRC: reflejan los resultados históricos críticos. Son ideales para comunicar los resultados alcanzados.

IP: Indicadores de performance, indican al personal qué hacer

IR: Indicadores de resultados, indican al personal qué se ha hecho.

KPI: Indican al personal y directivos qué debe hacer para aumentar la perfomance drásticamente.

El gráfico anterior es como “pelar una cebolla” y describe la relación entre los cuatro tipos de métricas. La corteza exterior nos muestra el estado general de la cebolla: cuánto ha recibido de sol, agua y nutriientes; y cómo se la ha tratado desde la cosecha hasta la góndola del supermercado. Por ello la corteza exterior es un IRC, indicador de resultado crítico. Las hojas internas representan a varios indicadores de performance y resultado mientras que el núcleo central es el corazón de la cebolla y es donde se encuentran los KPI en nuestra analogía.

La regla 10/80/10

Kaplan y Norton recomiendan no más de 20 KPI, y Jeremy Hope no más de 10. Para ayudar a todos los involucrados en la definición de la cantidad de KPI hemos creado la regla 10/80/10. Esto implica que una empresa debe trabajar con alrededor de 10 ICR, con 80 indicadores IP e IR y con no más de 10 KPI. Pocas veces se necesitan más métricas que éstas, en incluso menos en muchas ocasiones.

ICR, Indicadores Clave de Resultados

La característica más común entre los ICR es que ellos son el resultado de muchas acciones. Nos dan una clara idea de si la empresa está tomando el camino adecuado y de si se alcanzan los objetivos estratégicos buscados. Sin embargo ellos nos comunican al personal y directivos sobre qué hacer para lograr los efectos deseados. Esto sólo lo pueden hacer los IP y los KPI.

Algunos ejemplos de ICR tomados equivocadamente como KPI son:

• Satisfacción del cliente
• Ganancias netas antes de impuestos
• Rentabilidad por cliente
• Satisfacción del personal
• Tasa de retorno del capital

El hecho de separar los KPI del resto de las métricas tiene un profundo impacto en la forma en que se monitorea la performance. Los KPI están relacionados con la estrategia básica de la empresa mientras que el resto de las métricas están más relacionadas con aspectos de management.

La velocidad de un auto nos permite realizar la siguiente analogía: Los directivos sólo quieren conocer la velocidad a la que el auto (empresa) está yendo. Los gerentes ejecutivos necesitan más información pues la velocidad del auto depende de aspectos claves como las RPM del motor o el nivel de marcha elegido. De hecho hay veces que los gerentes ejecutivos pueden estar concentrándose en algo completamente distinto como cuán económico es la marcha (ej. Un reloj que muestra la eficiencia en el uso de combustible o cómo está funcionando el motor. Estos son indicadores de performance completamente distintos.

Indicadores de Performance y de Resultados (IP & IR)

La porción de 80 métricas que están entre los KPI y los ICR son los llamados Indicadores de Performance (IP) y los Indicadores de Resultados (IR). Los IP si bien son importantes no son clave para el negocio. Estas métricas ayudan a los distintos departamentos y responsables a alinearse con la estrategia de la empresa. Los IP complementan a los KPI y se muestran en los distintos tableros que componen un Balanced Scorecard empresarial.

Algunos ejemplos de IP son:

• Porcentaje de aumento en ventas en el segmento del 10% de los clientes top
• Numero de recomendaciones de staff adoptadas en los últimos 30 días
• Quejas recibidas de clientes selectos
• Cantidad de visitas a clientes planeadas para los próximos 15 días
• Entregas demoradas a clientes selectos

Algunos ejemplos de IR son:

• Resultados netos de principales productos
• Ventas diaries
• Ventas semanales a clientes selectos
• Cobranzas realizadas en la semana
• Cantidad de visitas a clientes potenciales

El Datawarehouse y el Business Intelligence en Gobierno

2008-11-17T10:21:00.000+01:00

Introducción

El Datawarehouse es un deposito donde se almacenan los datos que la organización utiliza para saber como esta funcionando. El almacenamiento de datos concentra mucha información proveniente de los procesos, de los sistemas operativos y financieros de los GRP’s y CRM’s entre otros.

El Datawarehouse es un componente del modelo de Bussines Intelligence, en cuya base se encuentra el almacén, la infraestructura conformada por la base de datos donde se integra toda la información; sobre él están las herramientas para presentar informes y hacer consultas; mas arriba esta la estrategia de inteligencia de negocios formada metodologías que se ciñen a las mejores practicas, la cultura organizacional y las habilidades de desarrollo con las que se cuenta para sacar mayor provecho de la infraestructura y de las aplicaciones.

La Inteligencia de Negocios consiste en convertir datos en información útil, en utilizar datos para conocer el desempeño de una organización. Él vinculo entre la inteligencia de Negocios y la tecnología es fundamental, porque es la zona donde se traducen los datos en información útil para la organización. Es un puente que transforma, depura e integra datos.

Los Fracasos

La mayoría de los fracasos se debieron a que las organizaciones adoptaron una perspectiva equivocada: lo vieron como un asunto tecnológico y no como un asunto institucional. Las personas que estaban a cargo de las tecnologías de la información propusieron hacer un Datawarehouse "Lo Construimos y se lo entregamos a la Empresa"

En segundo lugar, muchos buscan solucionar demasiados problemas de un solo golpe, en lugar de alcanzar la madurez con las aplicaciones, las herramientas y la metodología.

Un tercer problema esta relacionado con la persona que autoriza el financiamiento, Puede irse de la organización y entonces alguien puede decir: "¿Por qué estamos gastando esta cantidad de dinero?" No entiendo, el presupuesto se está acabando y tengo otras prioridades.

El cuarto problema surge con el cambio de requisitos

Finalmente esta el tema de la falta de capacitación de los usuarios. Aunque en teoría haya un buen DataWarehouse y se hayan implementado exitosas herramientas en sus aplicaciones, si no se capacita a los usuarios para que utilicen los datos para tomar decisiones, jamás lo usaran y todo mundo acabara diciendo que no sirve porque no añade valor le dará la espalda y dirá que fue un fracaso.

La interoperabilidad

El Datawarehouse puede ser utilizado para incorporar y reunir la información de todas las dependencias y conformar así una visión integral de la operación de la institución.

Los datos se encuentran en múltiples sistemas; hay que traducirlos a un idioma común, es decir; hay datos que generan el procesador central, el GRP, el CRM y todos están en un lenguaje distinto.

La calidad de los datos

El mejor indicador de que los datos cuentan con suficiente calidad es que sean susceptibles de ser utilizados por la organización, pero las tecnologías de la información no pueden decidir cual es el nivel de calidad necesario que deben tener los datos.

Es la parte directiva de la institución la que debe indicar cuáles son las metas de calidad que deben tener los datos, y por lo tanto deben especificarlos y luego dar la instrucción para que se desarrollen en esa dirección, si estos desarrollos se dan desde la perspectiva de toda la organización, si hay alguien que realmente dirija el proyecto desde un punto de vista integral, la eficacia del Datawarehouse se multiplicara y encontrara éxito.

Los gobiernos deben aprender a administrar información y crear conocimiento

El volumen de información que se produce ha crecido tanto, que la eficiencia en el manejo de los factores de la producción depende cada vez más de la manera en que se administra y planifica el ciclo de creación y utilización de la información. La información es una activo, pero su utilización no esta ligada a los procesos que la generan: se produce en un tiempo y lugar distinto al de su utilización y aplicación, por lo que su valor esta determinado por quien la usa, y no por quien la produce. Los gobiernos no están exentos de esta situación.

En el Reporte Mundial del Sector Publico de 2003, la Organización de las Naciones Unidas (ONU) indica que uno de los factores clave para el éxito de los e-gobiernos es que los gobiernos aprendan a administrar información para crear conocimiento. Dicho de otro modo: para que los gobiernos generen valor público deben utilizar eficientemente la información, esto es, información que genere conocimiento.

Los gobiernos son el mayor, retenedor y proveedor de información, y agrega que en un mundo globalizado donde los mercados enfrentan una creciente competencia, la innovación es más importante que la

Productividad o la eficiencia en costos, y que tanto los individuos como los gobiernos no solo tienen que resolver nuevas ecuaciones para alcanzar sus objetivos, sino que estas ecuaciones contienen un porcentaje cada vez mayor de variables desconocidas. Este entorno exige que los gobiernos eleven su capacidad para administrar información y crear conocimiento; de lo contrario enfrentaran una situación de abundancia información y déficit de conocimiento.

La Inteligencia de Negocios

Para enfrentar este reto los gobiernos, implantan complejos sistemas de información gracias a las tecnologías de la información y la comunicación (TIC). Él desafió es que las instituciones implementen estrategias de administración de información y creación de conocimiento que combinen herramientas tecnológicas, procesos aplicaciones y mejores practicas. Una estrategia de esta índole pondrá a prueba, típicamente, a la organización en su conjunto: su gente, su cultura organizacional, sus procesos y aplicaciones que generen información, y su infraestructura tecnológica.

Las estrategias encaminadas a resolver los problemas de administración de información y creación de conocimiento se encuadran bajo el concepto de inteligencia de negocios o BI por sus siglas en ingles (Bussiness Intelligence).

En México los gobiernos hacen esfuerzos para que cualquier persona y en cualquier momento disponga de información publica, pero se hace cada vez más evidente que nuestra sociedad requiere, mas bien, no solo el acceso a la abundante información publica, sino que sea confiable y precisa, lo que significa confiar en la fuente que provee esa información.

El gobierno esta obligado a realizar una serie e esfuerzos que tendrán una alta probabilidad de fracaso si no se reconoce que la incumbencia en el tema no es solo de las áreas informáticas y/o tecnológicas, sino de toda la organización.

El reto no es resolver el problema tecnológico de múltiples bases de datos, sino de resolver el problema estructural que consiste en la abundancia de información y de la falta de conocimiento al interior de las instituciones.

El riesgo de no hacer nada

La compleja política y la escasez presupuestaria que enfrentan los gobiernos en México exigen que los proyectos de BI. Sean evaluados tanto por los beneficios que representan como por el riesgo de no llevarlos a cabo. Por esto, lo más recomendable es que las estrategias BI se aborden bajo el enfoque mixto de maximización de beneficios y minimización de riesgos. Las estrategias deben maximizar la eficiencia en el manejo de la información y la eficacia de los procesos y aplicaciones; pero al mismo tiempo deben minimizar el riesgo de la rigidez institucional motivada por la inexistencia de información accesible para generar los conocimientos necesarios, así como el riesgo de tener procesos y sistemas redundantes.

La Inteligencia Institucional

No es lo mismo Inteligencia de Negocios que la Inteligencia Institucional porque los indicadores para medir el desempeño de las organizaciones en cada caso no son iguales

"La información es el capital más valioso de toda organización"

La Información sobre el desempeño de una organización es la única fuente para evaluar su funcionamiento, y la herramienta primaria para planificar su futuro. Sirve para medir la eficiencia de las inversiones y su retorno en beneficios para corregir oportunamente los posibles errores y desviaciones, y permite generar un ciclo virtuoso de ejecución y evaluación permanente, siempre ligado a la operación diaria de los programas de trabajo.

Esta actividad no quedó restringida al mundo empresarial. Para la administración pública se creo el concepto Inteligencia Institucional, que gana en precisión y pertinencia al advertí en su desarrollo las complejidades y rasgos característicos de la tarea gubernamental.

La diferencia más importante entre la Inteligencia de Negocios y la Inteligencia Institucional es la medición del Retorno de Inversión (ROI por sus siglas en ingles). Para las instituciones gubernamentales, el ROI no es únicamente un balance de resultados financieros. Su medición tiene indicadores tales como: más y mejor educación, más y mejores empleos, o reducción de la pobreza, por citar algunos ejemplos. De ahí que los datos que sirven para medir el desempeño de los gobiernos no se encuentran en las oficinas públicas, sino en la calle, en las ciudades y pueblos, o de dicho de otro modo, en la satisfacción ciudadana y en una mejor calidad de vida para todos.

Una segunda gran diferencia entre la implementación de una estrategia de Inteligencia de Negocios y una Inteligencia Institucional, es la heterogeneidad de las fuentes de información. Para una empresa, cruzar diferentes datos sobre su operación puede resultar complejo, pero cuando se trata de organismos gubernamentales las fuentes son mucho más diversas. El gobierno es la suma de una gran variedad de dependencias, organismos, empresas paraestatales, organizaciones sociales y ciudadanas, entre otras, que trabajan en distinto ámbitos territoriales.

Homologar la diversidad

¿Es posible entonces, homologar peras con manzanas? ¿Existe la herramienta tecnológica que haga posible cruzar datos tan diversos de Instituciones tan disímiles?

Conclusiones

El interés del gobierno en aplicaciones de Inteligencia Institucional se debe a que estas herramientas son capaces de integrar información proveniente de distintos sistemas. Las dependencias pueden tener datos dispersos tanto en sistemas tecnológicos avanzados como en programas elementales tipo Excel. Pero gracias a esta herramienta podrán extraer automáticamente la información relevante que requieren aquellos que tomen decisiones.

Construir herramientas de análisis

La información seleccionada y extraída de las bases de datos se presenta al usuario en su escritorio a través de pantallas dinámicas, con amplias capacidades para analizar y proyectarla de manera multidimensional, o bien, combinarla con distintos parámetros que arrojen mejores interpretaciones.

Medir el desempeño y los resultados.

Al provenir la información de las bases de datos operativas de la dependencia, el funcionario se asegura que esta conociendo información de la fuente original, sin "maquillajes" ni sorpresas en cuanto a sí veracidad, por su parte, el responsable de los datos sabe que únicamente podrá mejorar los resultados de su información si el conjunto de la institución mejora su desempeño.

Definiciones, descripciones y ... Datawarehouse

2008-11-16T22:43:00.002+01:00

Descripción de un Data Warehouse

En el contexto de la informática, un almacén de datos (del ingles data warehouse) es una colección de datos orientada a un determinado ámbito (empresa, organización, etc.), integrado, no volátil y variable en el tiempo, que ayuda a la toma de decisiones en la entidad en la que se utiliza. Se trata, sobre todo, de un expediente completo de una organización, más allá de la información transaccional y operacional, almacenado en una base de datos diseñada para favorecer el análisis y la divulgación eficiente de datos (especialmente OLAP, procesamiento analítico en línea). El almacenamiento de los datos no debe usarse con datos de uso actual. Los almacenes de datos contienen a menudo grandes cantidades de información que se subdividen a veces en unidades lógicas más pequeñas dependiendo del subsistema de la entidad del que procedan o para el que sean necesario.

Definiciones de almacén de datos
Definición de Bill Inmon
Bill Inmon fue uno de los primeros autores en escribir sobre el tema de los almacenes de datos, define un data warehouse (almacén de datos) en términos de las características del repositorio de datos:

• 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í.

• 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.

• 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.

• Integrado.- La base de datos contiene los datos de todos los sistemas operacionales de la organización, y dichos datos deben ser consistentes.
Inmon defiende una metodología descendente (top-down) a la hora de diseñar un almacén de datos, ya que de esta forma se considerarán mejor todos los datos corporativos. En esta metodología los Data marts se crearán después de haber terminado el data warehouse completo de la organización.

Definición de Ralph Kimball
Este es otro conocido autor en el tema de los data warehouse, define un almacén de datos como: "una copia de las transacciones de datos específicamente estructurada para la consulta y el análisis". También fue Kimball quien determinó que un data warehouse no era más que: "la unión de todos los Data marts de una entidad". Defiende por tanto una metodología ascendente (bottom-up) a la hora de diseñar un almacén de datos.

Una definición más amplia de almacén de datos
Las definiciones anteriores se centran en los datos en sí mismos. Sin embargo, los medios para obtener y analizar esos datos, para extraerlos, transformarlos y cargarlos, así como las diferentes formas para realizar la gestión de datos son componentes esenciales de un almacén de datos. Muchas referencias a un almacén de datos utilizan esta definición más amplia. Por lo tanto, en esta definición se incluyen herramientas para la inteligencia empresarial, herramientas para extraer, transformar y cargar datos en el almacén de datos, y herramientas para gestionar y recuperar los metadatos.

Función de un almacén de datos
En un almacén de datos lo que se quiere es contener datos que son necesarios o útiles para una organización, es decir, que se utiliza como un repositorio de datos para posteriormente transformarlos en información útil para el usuario. Un almacén de datos debe entregar la información correcta a la gente indicada en el momento óptimo y en el formato adecuado. El almacén de datos da respuesta a las necesidades de usuarios expertos, utilizando Sistemas de Soporte a Decisiones (DSS), Sistemas de información ejecutiva (EIS) o herramientas para hacer consultas o informes. Los usuarios finales pueden hacer fácilmente consultas sobre sus almacenes de datos sin tocar o afectar la operación del sistema.

En el funcionamiento de un almacén de los datos son muy importantes las siguientes ideas:
• Integración de los datos provenientes de bases de datos distribuidas por las diferentes unidades de la organización y que con frecuencia tendrán diferentes estructuras (fuentes heterogéneas). Se debe facilitar una descripción global y un análisis comprensivo de toda la organización en el almacén de datos.

• Separación de los datos usados en operaciones diarias de los datos usados en el almacén de datos para los propósitos de divulgación, de ayuda en la toma de decisiones, para el análisis y para operaciones de control. Ambos tipos de datos no deben coincidir en la misma base de datos, ya que obedecen a objetivos muy distintos y podrían entorpecerse entre sí.

Periódicamente, se importan datos al almacén de datos de los distintos sistemas de planeamiento de recursos de la entidad (ERP) y de otros sistemas de software relacionados con el negocio para la transformación posterior. Es práctica común normalizar los datos antes de combinarlos en el almacén de datos mediante herramientas de extracción, transformación y carga (ETL). Estas herramientas leen los datos primarios (a menudo bases de datos OLTP de un negocio), realizan el proceso de transformación al almacén de datos (filtración, adaptación, cambios de formato, ...) y escriben en el almacén.

Data marts
Los Data marts son subconjuntos de datos de un data warehouse para áreas especificas.
Entre las características de un data mart destacan:
• Usuarios limitados.
• Área especifica.
• Tiene un propósito especifico.
• Tiene una función de apoyo.

Cubos de información
Los cubos de información o cubos OLAP funcionan como los cubos de rompecabezas en los juegos, en el juego se trata de armar los colores y en el data warehouse se trata de organizar los datos por tablas o relaciones; los primeros (el juego) tienen 3 dimensiones, los cubos OLAP tienen un número indefinido de dimensiones, razón por la cual también reciben el nombre de hipercubos. Un cubo OLAP contendrá datos de una determinada variable que se desea analizar, proporcionando una vista lógica de los datos provistos por el sistema de información hacia el data warehouse, esta vista estará dispuesta según unas dimensiones y podrá contener información calculada. El análisis de los datos está basado en las dimensiones del hipercubo, por lo tanto, se trata de un análisis multidimensional.

A la información de un cubo puede acceder el ejecutivo mediante "tablas dinámicas" en una hoja de cálculo o a través de programas personalizados. Las tablas dinámicas le permiten manipular las vistas (cruces, filtrados, organización, totales) de la información con mucha facilidad. Las diferentes operaciones que se pueden realizar con cubos de información se producen con mucha rapidez. Llevando estos conceptos a un data warehouse, éste es una colección de datos que está formada por «dimensiones» y «variables», entendiendo como dimensiones a aquellos elementos que participan en el análisis y variables a los valores que se desean analizar.

Dimensiones
Las dimensiones de un cubo son atributos relativos a las variables, son las perspectivas de análisis de las variables (forman parte de la tabla de dimensiones). Son catálogos de información complementaria necesaria para la presentación de los datos a los usuarios, como por ejemplo: descripciones, nombres, zonas, rangos de tiempo, etc. Es decir, la información general complementaria a cada uno de los registros de la tabla de hechos.

Variables
También llamadas indicadores de gestión?, son los datos que están siendo analizados. Forman parte de la tabla de hechos. Más formalmente, las variables representan algún aspecto cuantificable o medible de los objetos o eventos a analizar. Normalmente, las variables son representadas por valores detallados y numéricos para cada instancia del objeto o evento medido. En forma contraria, las dimensiones son atributos relativos a la variables, y son utilizadas para indexar, ordenar, agrupar o abreviar los valores de las mismas. Las dimensiones poseen una granularidad menor, tomando como valores un conjunto de elementos menor que el de las variables; ejemplos de dimensiones podrían ser: productos?, localidades? (o zonas), el tiempo? (medido en días, horas, semanas, etc.), ...
Ejemplos

Ejemplos de variables podrían ser:
• Beneficios
• Gastos
• Ventas
• etc.

Ejemplos de dimensiones podrían ser:
• producto (diferentes tipos o denominaciones de productos)
• localidades (o provincia, o regiones, o zonas geográficas)
• tiempo (medido de diferentes maneras, por horas, por días, por meses, por años, ...)
• tipo de cliente (casado/soltero, joven/adulto/anciano, ...)
• etc.

Según lo anterior, podríamos construir un cubo de información sobre el indice de ventas (variable a estudiar) en función del producto vendido, la provincia, el mes del año y si el cliente está casado o soltero (dimensiones). Tendríamos un cubo de 4 dimensiones.

Elementos que integran un almacén de datos
Metadatos
Uno de los componentes más importantes de la arquitectura de un almacén de datos son los metadatos. Se define comúnmente como "datos acerca de los datos", en el sentido de que se trata de datos que describen cuál es la estructura de los datos que se van a almacenar y cómo se relacionan.

El metadato documenta, entre otras cosas, qué tablas existen en una base de datos, qué columnas posee cada una de las tablas y qué tipo de datos se pueden almacenar. Los datos son de interés para el usuario final, el metadato es de interés para los programas que tienen que manejar estos datos. Sin embargo, el rol que cumple el metadato en un entorno de almacén de datos es muy diferente al rol que cumple en los ambientes operacionales. En el ámbito de los data warehouse el metadato juega un papel fundamental, su función consiste en recoger todas las definiciones de la organización y el concepto de los datos en el almacén de datos, debe contener toda la información concerniente a:
• Tablas
• Columnas de tablas
• Relaciones entre tablas
• Jerarquías y Dimensiones de datos
• Entidades y Relaciones

Funciones ETL (extracción, transformación y carga)
Los procesos de extracción, transformación y carga (ETL) son importantes ya que son la forma en que los datos se guardan en un data warehouse (o en cualquier base de datos). Implican las siguientes operaciones:
• Extracción.- Acción de obtener la información deseada a partir de los datos almacenados en fuentes externas.
• Transformación.- Cualquier operación realizada sobre los datos para que puedan ser cargados en el data warehouse o se puedan migrar de éste a otra base de datos.
• Carga.- Consiste en almacenar los datos en la base de datos final, por ejemplo el data warehouse objetivo.

Middleware
Middleware es un término genérico que se utiliza para referirse a todo tipo de software de conectividad que ofrece servicios u operaciones que hacen posible el funcionamiento de aplicaciones distribuidas sobre plataformas heterogéneas. Estos servicios funcionan como una capa de abstracción de software distribuida, que se sitúa entre las capas de aplicaciones y las capas inferiores (sistema operativo y red). El middleware puede verse como una capa API, que sirve como base a los programadores para que puedan desarrollar aplicaciones que trabajen en diferentes entornos sin preocuparse de los protocolos de red y comunicaciones en que se ejecutarán. De esta manera se ofrece una mejor relación costo/rendimiento que pasa por el desarrollo de aplicaciones más complejas, en menos tiempo.
La función del middleware en el contexto de los data warehouse es la de asegurar la conectividad entre todos los componentes de la arquitectura de un almacén de datos.

Diseño de un almacén de datos
Para construir un Data Warehouse se necesitan herramientas para ayudar a la migración y a la transformación de los datos hacia el almacén. Una vez construido, se requieren medios para manejar grandes volúmenes de información. Se diseña su arquitectura dependiendo de la estructura interna de los datos del almacén y especialmente del tipo de consultas a realizar. Con este criterio los datos deben ser repartidos entre numerosos data marts. Para abordar un proyecto de data warehouse es necesario hacer un estudio de algunos temas generales de la organización o empresa, los cuales se describen a continuación:

• Situación actual de partida.- Cualquier solución propuesta de data warehouse debe estar muy orientada por las necesidades del negocio y debe ser compatible con la arquitectura técnica existente y planeada de la compañía.

• Tipo y características del negocio.- Es indispensable tener el conocimiento exacto sobre el tipo de negocios de la organización y el soporte que representa la información dentro de todo su proceso de toma de decisiones.

• Entorno técnico.- Se debe incluir tanto el aspecto del hardware (mainframes, servidores, redes,...) así como aplicaciones y herramientas. Se dará énfasis a los Sistemas de soporte a decisiones (DSS), si existen en la actualidad, cómo operan, etc.

• Expectativas de los usuarios.- Un proyecto de data warehouse no es únicamente un proyecto tecnológico, es una forma de vida de las organizaciones y como tal, tiene que contar con el apoyo de todos los usuarios y su convencimiento sobre su bondad.

• Etapas de desarrollo.- Con el conocimiento previo, ya se entra en el desarrollo de un modelo conceptual para la construcción del data warehouse.

• Prototipo.- Un prototipo es un esfuerzo designado a simular tanto como sea posible el producto final que será entregado a los usuarios.

• Piloto.- El piloto de un data warehouse es el primero (o cada uno de los primeros) resultados generados de forma iterativa que se harán para llegar a la construcción del producto final deseado.

• Prueba del concepto tecnológico.- Es un paso opcional que se puede necesitar para determinar si la arquitectura especificada del data warehouse funcionará finalmente como se espera.

Almacén de datos espacial
Almacén de datos espacial es una colección de datos orientados al tema, integrados, no volátiles, variantes en el tiempo y que añaden la geografía de los datos, para la toma de decisiones. Sin embargo la componente geográfica no es un dato agregado, sino que una dimensión o variable en la tecnología de la información, de tal manera que permita modelar todo el negocio como un ente holístico, y que a través de herramientas de procesamiento analítico en línea (OLAP), no solamente se posea un alto desempeño en consultas multidimensionales sino que adicionalmente se puedan visualizar espacialmente los resultados.

El almacén de datos espacial forma el corazón de un extensivo Sistema de Información Geográfica para la toma de decisiones, éste al igual que los SIG, permiten que un gran número de usuarios accedan a información integrada, a diferencia de un simple almacén de datos que está orientado al tema, el Data warehouse espacial adicionalmente es Geo-Relacional, es decir que en estructuras relacionales combina e integra los datos espaciales con los datos descriptivos. Actualmente es geo-objetos, esto es que los elementos geográficos se manifiestan como objetos con todas sus propiedades y comportamientos, y que adicionalmente están almacenados en una única base de datos Objeto-Relacional. Los Data Warehouse Espaciales son aplicaciones basadas en un alto desempeño de las bases de datos, que utilizan arquitecturas Cliente-Servidor para integrar diversos datos en tiempo real. Mientras los almacenes de datos trabajan con muchos tipos y dimensiones de datos, muchos de los cuales no referencian ubicación espacial, a pesar de poseerla intrínsecamente, y sabiendo que un 80% de los datos poseen representación y ubicación en el espacio, en los Data warehouse espaciales, la variable geográfica desempeña un papel importante en la base de información para la construcción del análisis, y de igual manera que para un Data warehouse, la variable tiempo es imprescindible en los análisis, para los Data warehouse espaciales la variable geográfica debe ser almacenada directamente en ella.

Ventajas e inconvenientes de los almacenes de datos
Ventajas
Hay muchas ventajas por las que es recomendable usar un almacén de datos. Algunas de ellas son:
• Los almacenes de datos hacen más fácil el acceso a una gran variedad de datos a los usuarios finales

• Facilitan el funcionamiento de las aplicaciones de los sistemas de apoyo a la decisión tales como informes de tendencia', por ejemplo: obtener los ítems con la mayoría de las ventas en un área en particular dentro de los últimos dos años; informes de excepción, informes que muestran los resultados reales frente a los objetivos planteados a priori.

• Los almacenes de datos pueden trabajar en conjunto y, por lo tanto, aumentar el valor operacional de las aplicaciones empresariales, en especial la gestión de relaciones con clientes.

Inconvenientes
Utilizar almacenes de datos también plantea algunos inconvenientes, algunos de ellos son:
• A lo largo de su vida los almacenes de datos pueden suponer altos costos. El almacén de datos no suele ser estático. Los costos de mantenimiento son elevados.

• Los almacenes de datos se pueden quedar obsoletos relativamente pronto.

• A veces, ante una petición de información estos devuelven una información subóptima, que también supone una perdida para la organización.

• A menudo existe una delgada línea entre los almacenes de datos y sistemas operativos. Hay que determinar qué funcionalidades de estos se pueden aprovechar y cuáles se deben implementar en el data warehouse, resultaría costoso implementar operaciones no necesarias o dejar de implementar alguna que sí vaya a necesitarse.

Manual para la adquisición de un sistema de Data Warehouse

2008-11-16T22:25:00.002+01:00

Manual para la adquisición de un sistema de Data Warehouse

1.- INTRODUCCIÓN

1.1. Justificación histórica
En la actualidad, las tecnologías de la información han automatizado los procesos de carácter típicamente repetitivo o administrativo, haciendo uso de lo que llamaremos sistemas de información operacionales. Entendemos por aplicaciones operacionales, aquellas que resuelven las necesidades de funcionamiento de la empresa. En este tipo de sistemas, los conceptos más importantes son la actualización y el tiempo de respuesta.
Una vez satisfechas las necesidades operacionales más acuciantes, surge un nuevo grupo de necesidades sobre los sistemas de la empresa, a las cuales vamos a calificar como necesidades informacionales. Por necesidades informacionales, entendemos aquellas que tienen por objeto obtener la información necesaria, que sirva de base para la toma de decisiones tanto a escala estratégica como táctica. Estas necesidades informacionales se basan en gran medida en el análisis de un número ingente de datos, en el que es tan importante el obtener un valor muy detallado de negocio como el valor totalizado para el mismo. Es fundamental también la visión histórica de todas las variables analizadas, y el análisis de los datos del entorno. Estos requerimientos no son, a priori, difíciles de resolver dado que la información está efectivamente en los sistemas operacionales. Cualquier actividad que realiza la empresa está reflejada de forma minuciosa en sus bases de datos.
La realidad, sin embargo, es distinta, puesto que al atender las necesidades de tipo informacional, los responsables de sistemas se tropiezan con múltiples problemas. En primer lugar, al realizar consultas masivas de información (con el fin de conseguir el ratio, valor agrupado o grupo de valores solicitados), se puede ver perjudicado el nivel de servicio del resto de sistemas, dado que las consultas de las que estamos hablando, suelen ser bastante costosas en recursos. Además, las necesidades se ven insatisfechas por la limitada flexibilidad a la hora de navegar por la información y a su inconsistencia debido a la falta de una visión global (cada visión particular del dato está almacenada en el sistema operacional que lo gestiona).
En esta situación, el siguiente paso evolutivo ha venido siendo la generación de un entorno gemelo del operativo, que se ha denominado comúnmente Centro de Información, en el cual la información se refresca con menor periodicidad que en los entornos operacionales y los requerimientos en el nivel de servicio al usuario son más flexibles.
Con esta estrategia se resuelve el problema de la planificación de recursos ya que las aplicaciones que precisan un nivel de servicio alto usan el entorno operacional y las que precisan consultas masivas de información trabajan en el Centro de Información. Otro beneficio de este nuevo entorno, es la no inferencia con las aplicaciones operacionales.
Pero no terminan aquí los problemas. La información mantiene la misma estructura que en las aplicaciones operacionales por lo que este tipo de consultas debe acceder a multitud de lugares para obtener el conjunto de datos deseado. El tiempo de respuesta a las solicitudes de información es excesivamente elevado. Adicionalmente, al proceder la información de distintos sistemas, con visiones distintas y distintos objetivos, en muchas ocasiones no es posible obtener la información deseada de una forma fácil y además carece de la necesaria fiabilidad.
De cara al usuario estos problemas se traducen en que no dispone a tiempo de la información solicitada y que debe dedicarse con más intensidad a la obtención de la información que al análisis de la misma, que es donde aporta su mayor valor añadido.
1.2. Sumario
En los capítulos siguientes expondremos, por un lado qué es un Data Warehouse, un Data Mart y el porqué de estos conceptos. Por otro lado, veremos sus componentes de base (hardware y software) y el "estado del arte" de las distintas tecnologías disponibles. Analizaremos las distintas partes de las que se compone un sistema Data Warehouse y presentaremos una metodología de construcción del mismo. Examinaremos el uso que se le puede dar (Explotación del Data Warehouse), con especial hincapié en el Data Mining y las posibilidades de acceso a esta información. También presentaremos cómo algunas áreas se han beneficiado de las tecnologías de Data Warehouse: Marketing, Departamento Financiero, Área de Riesgo de Crédito, etc. Y por último, expondremos algunas recomendaciones generales a considerar para un buen uso de los sistemas de este tipo.

2.- ANÁLISIS DEL ENTORNO DATA WAREHOUSE

2.1. - ¿QUÉ ES UN DATA WAREHOUSE?
Tras las dificultades de los sistemas tradicionales en satisfacer las necesidades informacionales, surge el concepto de Data Warehouse, como solución a las necesidades informacionales globales de la empresa. Este término acuñado por Bill Inmon, se traduce literalmente como Almacén de Datos. No obstante si el Data Warehouse fuese exclusivamente un almacén de datos, los problemas seguirían siendo los mismos que en los Centros de Información.
La ventaja principal de este tipo de sistemas se basa en su concepto fundamental, la estructura de la información. Este concepto significa el almacenamiento de información homogénea y fiable, en una estructura basada en la consulta y el tratamiento jerarquizado de la misma, y en un entorno diferenciado de los sistemas operacionales. Según definió Bill Inmon, el Data Warehouse se caracteriza por ser:

Integrado: los datos almacenados en el Data Warehouse deben integrarse en una estructura consistente, por lo que las inconsistencias existentes entre los diversos sistemas operacionales deben ser eliminadas. La información suele estructurarse también en distintos niveles de detalle para adecuarse a las distintas necesidades de los usuarios.

Temático: sólo los datos necesarios para el proceso de generación del conocimiento del negocio se integran desde el entorno operacional. Los datos se organizan por temas para facilitar su acceso y entendimiento por parte de los usuarios finales. Por ejemplo, todos los datos sobre clientes pueden ser consolidados en una única tabla del Data Warehouse. De esta forma, las peticiones de información sobre clientes serán más fáciles de responder dado que toda la información reside en el mismo lugar.

Histórico: el tiempo es parte implícita de la información contenida en un Data Warehouse. En los sistemas operacionales, los datos siempre reflejan el estado de la actividad del negocio en el momento presente. Por el contrario, la información almacenada en el Data Warehouse sirve, entre otras cosas, para realizar análisis de tendencias. Por lo tanto, el Data Warehouse se carga con los distintos valores que toma una variable en el tiempo para permitir comparaciones.

No volátil: el almacén de información de un Data Warehouse existe para ser leído, y no modificado. La información es por tanto permanente, significando la actualización del Data Warehouse la incorporación de los últimos valores que tomaron las distintas variables contenidas en él sin ningún tipo de acción sobre lo que ya existía.
E.F. Codd, considerado como el padre de las bases de datos relacionales, ha venido insistiendo desde principio de los noventa, que disponer de un sistema de bases de datos relacionales, no significa disponer de un soporte directo para la toma de decisiones. Muchas de estas decisiones se basan en un análisis de naturaleza multidimensional, que se intentan resolver con la tecnología no orientada para esta naturaleza. Este análisis multidimensional, parte de una visión de la información como dimensiones de negocio.

Estas dimensiones de negocio se comprenden mejor fijando un ejemplo, para lo que vamos a mostrar, para un sistema de gestión de expedientes, las jerarquías que se podrían manejar para el número de los mismo para las dimensiones: zona geográfica, tipo de expediente y tiempo de resolución. La visión general de la información de ventas para estas dimensiones definidas, la representaremos, gráficamente como el cubo de la derecha:
Un gerente de una zona estaría interesado en visualizar la información para su zona en el tiempo para todos los productos que distribuye, lo podría tener una representación gráfica como el cubo de la derecha:
Un director de producto, sin embargo querría examinar la distribución geográfica de sus productos, para toda la información histórica almacenada en el Data Warehouse.
Esto se podría representar como la siguiente figura:
O se podría también examinar los datos en un determinado momento o una visión particularizada.

A su vez estas dimensiones tienen una jerarquía, interpretándose en el cubo como que cada cubo elemental es un dato elemental, del que se puede extraer información agregada. En el ejemplo anterior podría ser:

Y así por ejemplo se podría querer analizar la evolución de las ventas en Galicia de libros de Física por meses desde Febrero del 1996 hasta Marzo del 1997.
Ello es fácil de obtener (incluso a "golpe de ratón") si la información de ventas se ha almacenado en un Data Warehouse, definiendo estas jerarquías y estas dimensiones de negocio.
En este sentido citamos las palabras de D. Wayne Calloway Director Ejecutivo de Operaciones de Pepsico en una asamblea general de accionistas:

"Hace diez años les pude decir cuántos Doritos vendimos al Oeste del Mississipi. Hoy no sólo les puedo decir eso mismo, sino cuántos vendimos en California, en el Condado de Orange, en la ciudad de Irvine, en el Supermercado local Von’s, en una promoción especial, al final del pasillo 4, los jueves".
Otra característica del Data Warehouse es que contiene datos relativos a los datos, concepto que se ha venido asociando al término de metadatos. Los metadatos permiten mantener información de la procedencia de la información, la periodicidad de refresco, su fiabilidad, forma de cálculo, etc., relativa a los datos de nuestro almacén.
Estos metadatos serán los que permitan simplificar y automatizar la obtención de la información desde los sistemas operacionales a los sistemas informacionales.
Los objetivos que deben cumplir los metadatos, según el colectivo al que va dirigido, serían:
• Soportar al usuario final, ayudándole a acceder al Data Warehouse con su propio lenguaje de negocio, indicando qué información hay y qué significado tiene. Ayudar a construir consultas, informes y análisis, mediante herramientas de navegación.
• Soportar a los responsables técnicos del Data Warehouse en aspectos de auditoría, gestión de la información histórica, administración del Data Warehouse, elaboración de programas de extracción de la información, especificación de las interfaces para la realimentación a los sistemas operacionales de los resultados obtenidos, etc.
Para comprender el concepto de Data Warehouse, es importante considerar los procesos que lo conforman. A continuación se describen dichos procesos clave en la gestión de un Data Warehouse:

Extracción: obtención de información de las distintas fuentes tanto internas como externas.

Elaboración: filtrado, limpieza, depuración, homogeneización y agrupación de la información.

Carga: organización y actualización de los datos y los metadatos en la base de datos.

Explotación: extracción y análisis de la información en los distintos niveles de agrupación.
Desde el punto de vista del usuario, el único proceso visible es la explotación del almacén de datos, aunque el éxito del Data Warehouse radica en los tres procesos iniciales que alimentan la información del mismo y suponen el mayor porcentaje de esfuerzo (en torno a un 80%) a la hora de desarrollar el almacén.

Una de las claves del éxito en la construcción de un Data Warehouse es el desarrollo de forma gradual, seleccionando a un departamento usuario como piloto y expandiendo progresivamente el almacén de datos a los demás usuarios. Por ello es importante elegir este usuario inicial o piloto, siendo importante que sea un departamento con pocos usuarios, en el que la necesidad de este tipo de sistemas es muy alta y se puedan obtener y medir resultados a corto plazo.
Terminamos este apartado, resumiendo los beneficios que un Data Warehouse puede aportar:
• Proporciona una herramienta para la toma de decisiones en cualquier área funcional, basándose en información integrada y global del negocio.
• Facilita la aplicación de técnicas estadísticas de análisis y modelización para encontrar relaciones ocultas entre los datos del almacén; obteniendo un valor añadido para el negocio de dicha información.
• Proporciona la capacidad de aprender de los datos del pasado y de predecir situaciones futuras en diversos escenarios.
• Simplifica dentro de la empresa la implantación de sistemas de gestión integral de la relación con el cliente.
• Supone una optimización tecnológica y económica en entornos de Centro de Información, estadística o de generación de informes con retornos de la inversión espectaculares.

2.2.- CONCEPTOS Y FUNCIONALIDADES BÁSICAS

2.2.1.- DATA WAREHOUSE VS. DATA MART
La duplicación en otro entorno de datos es un término que suele ser mal interpretado e incomprendido. Así es usado por los fabricantes de SGBD en el sentido de simple réplica de los datos de un sistema operacional centralizado en sistemas distribuidos. En un contexto de Data Warehouse, el término duplicación se refiere a la creación de Data Marts locales o departamentales basados en subconjuntos de la información contenida en el Data Warehouse central o maestro.
Según define Meta Group, "un Data Mart es una aplicación de Data Warehouse, construida rápidamente para soportar una línea de negocio simple". Los Data Marts, tienen las mismas características de integración, no volatilidad, orientación temática y no volatilidad que el Data Warehouse. Representan una estrategia de "divide y vencerás" para ámbitos muy genéricos de un Data Warehouse.
Esta estrategia es particularmente apropiada cuando el Data Warehouse central crece muy rápidamente y los distintos departamentos requieren sólo una pequeña porción de los datos contenidos en él. La creación de estos Data Marts requiere algo más que una simple réplica de los datos: se necesitarán tanto la segmentación como algunos métodos adicionales de consolidación.
La primera aproximación a una arquitectura descentralizada de Data Mart, podría ser venir originada de una situación como la descrita a continuación.

El departamento de Marketing, emprende el primer proyecto de Data Warehouse como una solución departamental, creando el primer Data Mart de la empresa.
Visto el éxito del proyecto, otros departamentos, como el de Riesgos, o el Financiero se lanzan a crear sus Data Marts. Marketing, comienza a usar otros datos que también usan los Data Marts de Riesgos y Financiero, y estos hacen lo propio.
Esto parece ser una decisión normal, puesto que las necesidades de información de todos los Data Marts crecen conforme el tiempo avanza. Cuando esta situación evoluciona, el esquema general de integración entre los Data Marts pasa a ser, la del gráfico de la derecha.
En esta situación, es fácil observar cómo este esquema de integración de información de los Data Marts, pasa a convertirse en un rompecabezas en el que la gestión se ha complicado hasta convertir esta ansia de información en un auténtico quebradero de cabeza. No obstante, lo que ha fallado no es la integración de Data Marts, sino su forma de integración.

En efecto, un enfoque más adecuado sería la coordinación de la gestión de información de todos los Data Marts en un Data Warehouse centralizado.
En esta situación los Data Marts obtendrían la información necesaria, ya previamente cargada y depurada en el Data Warehouse corporativo, simplificando el crecimiento de una base de conocimientos a nivel de toda la empresa.
Esta simplificación provendría de la centralización de las labores de gestión de los Data Marts, en el Data Warehouse corporativo, generando economías de escala en la gestión de los Data Marts implicados.
Según un estudio de IDC (International Data Corporation) tras analizar 541 empresas, la distribución de las implantaciones de Data Warehouse y Data Marts en la actualidad, y sus opiniones respecto a esta distribución en el futuro, nos muestra los siguientes datos:
En la gráfica, observamos, cómo en la actualidad, de las empresas consultadas, un 80% de ellas cuentan con implantaciones de Data Warehouse o Data Marts.

La proporción actual de implantaciones de Data Warehouse es casi el doble que el de Data Mart.
No obstante, seguramente tras la andadura inicial de alguno de estos proyectos de Data Mart, se ve como más adecuado para el futuro este enfoque "divide y vencerás", previéndose una inversión de estos papeles y duplicando la implantación de Data Marts a los Data Warehouse.
Probablemente, el 5% de usuarios que disponen de tecnología de Data Warehouse y piensan renunciar a ella en el futuro, no han realizado previamente un estudio de factores implicados en un Data Warehouse, o han pasado por la situación inicial de partida, y no se han planteado una reorganización del mismo.

2.2.2.- COMPONENTES A TENER EN CUENTA A LA HORA DE CONSTRUIR UN DW
2.2.2.1.-Hardware
Un componente fundamental a la hora de poder contar con un Data Warehouse que responda a las necesidades analíticas avanzadas de los usuarios, es el poder contar con una infraestructura hardware que la soporte.
En este sentido son críticas, a la hora de evaluar uno u otro hardware, dos características principales:
Por un lado, a este tipo de sistemas suelen acceder pocos usuarios con unas necesidades muy grandes de información, a diferencia de los sistemas operacionales, con muchos usuarios y necesidades puntuales de información. Debido a la flexibilidad requerida a la hora de hacer consultas complejas e imprevistas, y al gran tamaño de información manejada, son necesarias unas altas prestaciones de la máquina.
Por otro lado, debido a que estos sistemas suelen comenzar con una funcionalidad limitada, que se va expandiendo con el tiempo (situación por cierto aconsejada), es necesario que los sistemas sean escalables para dar soporte a las necesidades crecientes de equipamiento. En este sentido, será conveniente el optar por una arquitectura abierta, que nos permita aprovechar lo mejor de cada fabricante.
En el mercado se han desarrollado tecnologías basadas en tecnología de procesamiento paralelo, dan el soporte necesario a las necesidades de altas prestaciones y escalabilidad de los Data Warehouse. Estas tecnologías son de dos tipos:
• SMP (Symmetric multiprocessing, o Multiprocesadores Simétricos): Los sistemas tienen múltiples procesadores que comparten un único bus y una gran memoria, repartiéndose los procesos que genera el sistema, siendo el sistema operativo el que gestiona esta distribución de tareas. Estos sistemas se conocen como arquitecturas de "casi todo compartido". El aspecto más crítico de este tipo de sistemas es el grado de rendimiento relativo respecto al número de procesadores presentes, debido a su creciente no lineal.
• MPP (Massively parallel processing, o Multiprocesadores Masivamente Paralelos): Es una tecnología que compite contra la SMP, en la que los sistemas suelen ser casi independientes comunicados por intercambiadores de alta velocidad que permiten gestionarlos como un único sistema. Se conocen por ello como arquitecturas de "nada compartido". Su escalabilidad es mayor que la de los SMP.
Según Meta Group, las tendencias de mercado indican que las arquitecturas SMP aportan normalmente suficientes características de escalabilidad, con una mayor oferta y un menor riesgo tecnológico. Sin embargo, cuando las condiciones de escalabilidad sean extremas, se puede plantear la opción MPP.
No obstante, se están produciendo avances significativos en arquitecturas SMP, que han logrado máquinas con un crecimiento lineal de rendimiento hasta un número de 64 procesadores.
Recomendamos desde estas páginas, la visita a la dirección Internet:
http://www.tpc.org/bench.results.html
en donde la Transaction Processing Council (de la que son miembros ALR, Amdahl, Bull, Compaq, Data General, Dell, Digital, Fujitsu, HP, IBM, Intergraph, NCR , Siemens-Nixdorf, Sun o Unisys), realiza una comparativa entre las máquinas de sus miembros, proporcionando para diferentes modelos y diferentes configuraciones de Sistemas Operativos y Software de Base de Datos, un análisis de rendimiento (throughput), y un resumen de características (precio, número de procesadores, arquitectura y futuras versiones y fecha de disponibilidad).

2.2.2.2.-Software de almacenamiento (SGBD)
Como hemos comentado, el sistema que gestione el almacenamiento de la información (Sistema de Gestión de Base de Datos o SGBD), es otro elemento clave en un Data Warehouse. Independientemente de que la información almacenada en el Data Warehouse se pueda analizar mediante visualización multidimensional, el SGBD puede estar realizado utilizando tecnología de Bases de Datos Relacionales o Multidimensionales.
Las bases de datos relacionales, se han popularizado en los sistemas operacionales, pero se han visto incapaces de enfrentarse a las necesidades de información de los entornos Data Warehouse. Por ello, y puesto que, como hemos comentado, las necesidades de información suelen atender a consultas multidimensionales, parece que unas Bases de Datos multidimensionales, parten con ventaja. En este sentido son de aplicación los comentarios que realizamos en el apartado de hardware, por requerimientos de prestaciones, escalabilidad y consolidación tecnológica.
Al igual que en el hardware, nuevos diseños de las bases de datos relacionales, las bases de datos post-relacionales, abren un mayor abanico de elección. Estas bases de datos post-relacionales, parten de una tecnología consolidada y dan respuesta al agotamiento de las posibilidades de los sistemas de gestión de bases de datos relacionales, ofreciendo las mismas prestaciones aunque implantadas en una arquitectura diseñada de forma más eficiente.
Esta mayor eficiencia se consigue instaurando relaciones lógicas en vez de físicas, lo que hace que ya no sea necesario destinar más hardware a una solución para conseguir la ejecución de las funciones requeridas. El resultado es que la misma aplicación implantada en una BD post-relacional requiere menos hardware, puede dar servicio a un mayor número de usuarios y utilizar mecanismos intensivos de acceso a los datos más complejos. Asimismo, esta tecnología permite combinar las ventajas de las bases de datos jerárquicas y las relacionales con un coste más reducido. Ambos sistemas aportan como ventaja que no resulta necesario disponer de servidores omnipotentes, sin que puede partirse de un nivel de hardware modesto y ampliarlo a medida que crecen las necesidades de información de la compañía y el uso efectivo del sistema.
Dejamos fuera del ámbito de esta guía el detallar cómo los proveedores de bases de datos han optimizado los accesos a los índices, o las nuevas posibilidades que ofrece la compresión de datos (menos espacio para la misma información lo que implica, entre otras ventajas, que más información se puede tener en caché), para lo que remitimos a la prensa especializada o a las publicaciones de los fabricantes.

2.2.2.3.- Software de extracción y manipulación de datos
En este apartado analizaremos un componente esencial a la hora de implantar un Data Warehouse, la extracción y manipulación. Para esta labor, que entra dentro del ámbito de los profesionales de tecnologías de la información, es crítico el poder contar con herramientas que permitan controlar y automatizar los continuos "mimos" y necesidades de actualización del Data Warehouse.
Estas herramientas deberán proporcionar las siguientes funcionalidades:
• Control de la extracción de los datos y su automatización, disminuyendo el tiempo empleado en el descubrimiento de procesos no documentados, minimizando el margen de error y permitiendo mayor flexibilidad.
• Acceso a diferentes tecnologías, haciendo un uso efectivo del hardware, software, datos y recursos humanos existentes.
• Proporcionar la gestión integrada del Data Warehouse y los Data Marts existentes, integrando la extracción, transformación y carga para la construcción del Data Warehouse corporativo y de los Data Marts.
• Uso de la arquitectura de metadatos, facilitando la definición de los objetos de negocio y las reglas de consolidación.
• Acceso a una gran variedad de fuentes de datos diferentes.
• Manejo de excepciones.
• Planificación, logs, interfaces a schedulers de terceros.
• Interfaz independiente de hardware.
• Soporte en la explotación del Data Warehouse.
A veces, no se suele prestar la suficiente atención a esta fase de la gestión del Data Warehouse, aun cuando supone una gran parte del esfuerzo en la construcción de un Data Warehouse. Existen multitud de herramientas disponibles en el mercado que automatizan parte del trabajo, para lo cual recomendamos la visita a la página Internet:
http://pwp.starnetinc.com/larryg/clean.html
en la que se proporciona una lista de mas de 100 herramientas de extracción y manipulación de datos, con links a sus páginas Internet, y una somera descripción de la funcionalidad cubierta por cada herramienta.

2.2.2.4.- Herramientas Middleware
Como herramientas de soporte a la fase de gestión de un Data Warehouse, analizaremos a continuación dos tipos de herramientas:
• Por un lado herramientas Middleware, que provean conectividad entre entornos diferentes, para ayudar en la gestión del Data Warehouse.
• Por otro, analizadores y aceleradores de consultas, que permitan optimizar tiempos de respuestas en las necesidades analíticas, o de carga de los diferentes datos desde los sistemas operacionales hasta el Data Warehouse.
Las herramientas Middleware deben ser escalables siendo capaces de crecer conforme crece el Data Warehouse, sin problemas de volúmenes. Tambien deben ser flexibles y robustas, sin olvidarse de proporcionar un rendimiento adecuado. Estarán abiertas a todo tipos de entornos de almacenamiento de datos, tanto mediante estándares de facto (OLE, ODBC, etc.), como a los tipos de mercado más populares (DB2, Access, etc.). La conectividad, al menos en estándares de transporte (SNA LU6.2, DECnet, etc.) debe estar tambien asegurada.
Con el uso de estas herramientas de Middleware lograremos:
• Maximizar los recursos ejecutando las aplicaciones en la plataforma más adecuada.
• Integrar los datos y aplicaciones existentes en una plataforma distribuida.
• Automatizar la distribución de datos y aplicaciones desde un sistema centralizado.
• Reducir tráfico en la red, balanceando los niveles de cliente servidor (mas o menos datos en local, mas o menos proceso en local).
• Explotar las capacidades de sistemas remotos sin tener que aprender multiples entornos operativos.
• Asegurar la escalabilidad del sistema.
• Desarrollar aplicaciones en local y explotarlas en el servidor.
Los analizadores y aceleradores de querys trabajan volcando sobre un fichero de log las consultas ejecutadas y datos asociados a las mismas (tiempo de respuesta, tablas accedidas, método de acceso, etc). Este log se analiza, bien automáticamente o mediante la supervisión del administrador de datos, para mejorar los tiempos de accesos.
Estos sistemas de monitorización se pueden implementar en un entorno separado de pruebas, o en el entorno real. Si se ejecutan sobre un entorno de pruebas, el rendimiento del entorno real no se vé afectado. Sin embargo, no es posible optimizar los esfuerzos, puesto que los análisis efectuados pueden realizarse sobre consultas no críticas o no frecuentemente realizadas por los usuarios.
El implantar un sistema analizador de consultas, en el entorno real tiene además una serie de ventajas tales como:
• Se pueden monitorizar los tiempos de respuesta del entorno real.
• Se pueden implantar mecanismos de optimización de las consultas, reduciendo la carga del sistema.
• Se puede imputar costes a los usuarios por el coste del Data Warehouse.
• Se pueden implantar mecanismos de bloqueo para las consultas que vayan a implicar un tiempo de respuesta excesivo.

2.2.3.- FASES DE IMPLANTACIÓN DE UN DATA WAREHOUSE
Tal y como aparecía en un artículo en ComputerWorld: "Un Data Warehouse no se puede comprar, se tiene que construir". Como hemos mencionado con anterioridad, la construcción e implantación de un Data Warehouse es un proceso evolutivo.
Este proceso se tiene que apoyar en una metodología específica para este tipo de procesos, si bien es más importante que la elección de la mejor de las metodologías, el realizar un control para asegurar el seguimiento de la misma.
En las fases que se establezcan en el alcance del proyecto es fundamental el incluir una fase de formación en la herramienta utilizada para un máximo aprovechamiento de la aplicación. El seguir los pasos de la metodología y el comenzar el Data Warehouse por un área específica de la empresa, nos permitirá obtener resultados tangibles en un corto espacio de tiempo.
Planteamos aquí la metodología propuesta por SAS Institute: la "Rapid Warehousing Methodology". Dicha metodología es iterativa, y está basada en el desarrollo incremental del proyecto de Data Warehouse dividido en cinco fases:

• Definición de los objetivos
• Definición de los requerimientos de información
• Diseño y modelización
• Implementación
• Revisión
2.2.3.1-Definición de los objetivos

2.2.3.2.-Definición de los requerimientos de información
Tal como sucede en todo tipo de proyectos, sobre todo si involucran técnicas novedosas como son las relativas al Data Warehouse, es analizar las necesidades y hacer comprender las ventajas que este sistema puede reportar.
Es por ello por lo que nos remitimos al apartado de esta guía de Análisis de las necesidades del comprador. Será en este punto, en donde detallaremos los pasos a seguir en un proyecto de este tipo, en donde el usuario va a jugar un papel tan destacado.

2.2.3.3.-Diseño y modelización
Los requerimientos de información identificados durante la anterior fase proporcionarán las bases para realizar el diseño y la modelización del Data Warehouse.
En esta fase se identificarán las fuentes de los datos (sistema operacional, fuentes externas,..) y las transformaciones necesarias para, a partir de dichas fuentes, obtener el modelo lógico de datos del Data Warehouse. Este modelo estará formado por entidades y relaciones que permitirán resolver las necesidades de negocio de la organización.
El modelo lógico se traducirá posteriormente en el modelo físico de datos que se almacenará en el Data Warehouse y que definirá la arquitectura de almacenamiento del Data Warehouse adaptándose al tipo de explotación que se realice del mismo.
La mayor parte estas definiciones de los datos del Data Warehouse estarán almacenadas en los metadatos y formarán parte del mismo.

2.2.3.4.-Implementación
La implantación de un Data Warehouse lleva implícitos los siguientes pasos:
• Extracción de los datos del sistema operacional y transformación de los mismos.
• Carga de los datos validados en el Data Warehouse. Esta carga deberá ser planificada con una periodicidad que se adaptará a las necesidades de refresco detectadas durante las fases de diseño del nuevo sistema.
• Explotación del Data Warehouse mediante diversas técnicas dependiendo del tipo de aplicación que se de a los datos:
Query & Reporting
On-line analytical processing (OLAP)
Executive Information System (EIS) ó Información de gestión
Decision Support Systems (DSS)
Visualización de la información
Data Mining ó Minería de Datos, etc.
La información necesaria para mantener el control sobre los datos se almacena en los metadatos técnicos (cuando describen las características físicas de los datos) y de negocio (cuando describen cómo se usan esos datos). Dichos metadatos deberán ser accesibles por los usuarios finales que permitirán en todo momento tanto al usuario, como al administrador que deberá además tener la facultad de modificarlos según varíen las necesidades de información.
Con la finalización de esta fase se obtendrá un Data Warehouse disponible para su uso por parte de los usuarios finales y el departamento de informática.

2.2.3.5.-Revisión
La construcción del Data Warehouse no finaliza con la implantación del mismo, sino que es una tarea iterativa en la que se trata de incrementar su alcance aprendiendo de las experiencias anteriores.
Después de implantarse, debería realizarse una revisión del Data Warehouse planteando preguntas que permitan, después de los seis o nueve meses posteriores a su puesta en marcha, definir cuáles serían los aspectos a mejorar o potenciar en función de la utilización que se haga del nuevo sistema.

2.2.3.6.-Diseño de la estructura de cursos de formación
Con la información obtenida de reuniones con los distintos usuarios se diseñarán una serie de cursos a medida, que tendrán como objetivo el proporcionar la formación estadística necesaria para el mejor aprovechamiento de la funcionalidad incluida en la aplicación. Se realizarán prácticas sobre el desarrollo realizado, las cuales permitirán fijar los conceptos adquiridos y servirán como formación a los usuarios.

2.2.4.- ESTRATEGIAS DE IMPLANTACIÓN
Resaltamos en esta guía algunas consideraciones que recomendamos deben seguirse a la hora de abordar un proyecto de este tipo:
"La Base de Datos de Riesgos debe estar separada de las Bases de Datos Operacionales" con objeto de no interferir en la actividad del día a día, disponiendo de la información necesaria para Riesgos (interna y externa) y en un entorno orientado hacia la consulta y el análisis (Data Warehouse).
"Concepción del sistema como un conjunto de herramientas de análisis", debido a que las actividades de Análisis de Riesgos no se pueden automatizar completamente, puesto que requieren análisis y decisiones del usuario.
"Diseño del sistema no orientado a procesos"; se debe disponer de un conjunto abierto de herramientas que se utilizan con propósitos determinados no relacionados con las necesidades operativas.
"Abordar el sistema con un enfoque de desarrollo gradual", se debe comenzar con un esqueleto básico de funcionalidad y datos que produzcan resultados a corto plazo y permita aprender en la práctica, y a continuación ir configurando progresivamente nuevas funcionalidades conforme la experiencia lo vaya requiriendo.
Son de aplicación en este apartado las consideraciones que realizamos en los apartados Data Warehouse vs. Data Marts y Fases de Implantación de un Data Warehouse.

2.2.5.-TÉCNICAS DE EXPLOTACIÓN DE LA IMPLANTACIÓN
Dentro del esquema de Gestión y Explotación del Data Warehouse que se muestra en el gráfico, pasamos a detallar las posibilidades que nos ofrece esta última fase.

En ella, examinaremos
1. el uso que se puede realizar de las utilidades OLAP del Data Warehouse para análisis multidimensionales,
2. las facilidades de obtención de información mediante consultas e informes libre, y el uso de técnicas de Data Mining que nos permitan descubrir "información oculta" en los datos mediante el uso de técnicas estadísticas.

2.2.5.1.- OLAP, ROLAP, MOLAP
La explotación del Data Warehouse mediante información de gestión, se fundamenta básicamente en los niveles agrupados o calculados de información.
La información de gestión se compone de conceptos de información y coeficientes de gestión, que los cuadros directivos de la empresa pueden consultar según las dimensiones de negocio que se definan.
Dichas dimensiones de negocio se estructuran a su vez en distintos niveles de detalle (por ejemplo, la dimensión geográfica puede constar de los niveles nacional, provincial, ayuntamientos y sección censal).
Este tipo de sistemas ha existido desde hace tiempo, en el mundo de la informática bajo distintas denominaciones: cuadros de mando, MIS, EIS, etc.
Su realización fuera del entorno del Data Warehouse, puede repercutir sobre estos sistemas en una mayor rigidez, dificultad de actualización y mantenimiento, malos tiempos de respuesta, incoherencias de la información, falta del dato agregado, etc.
Los sistemas de soporte a la decisión usando tecnologías de Data Warehouse, se llaman sistemas OLAP (siglas de On Line Analytical Processing (OLAP). En general, estos sistemas OLAP deben:
• Soportar requerimientos complejos de análisis
• Analizar datos desde diferentes perspectivas
• Soportar análisis complejos contra un volumen ingente de datos
La funcionalidad de los sistemas OLAP se caracteriza por ser un análisis multidimensional de datos corporativos, que soportan los análisis del usuario y unas posibilidades de navegación, seleccionando la información a obtener.
Normalmente este tipo de selecciones se ve reflejada en la visualización de la estructura multidimensional, en unos campos de selección que nos permitan elegir el nivel de agregación (jerarquía) de la dimensión, y/o la elección de un dato en concreto, la visualización de los atributos del sujeto, frente a una(s) dimensiones en modo tabla, pudiendo con ello realizar, entre otras las siguientes acciones:
Rotar (Swap): alterar las filas por columnas (permutar dos dimensiones de análisis)
Bajar (Down): bajar el nivel de visualización en las filas a una jerarquía inferior
Detallar (Drilldown): informar para una fila en concreto, de datos a un nivel inferior
Expandir (Expand): id. anterior sin perder la información a nivel superior para éste y el resto de los valores
Colapsar (Collapse): operación inversa de la anterior.
Para ampliar el glosario sobre exploraciones en análisis OLAP, recomendamos la visita a la página Internet:
http://www.kenan.com/acumate/olaptrms.htm
en donde se describen en torno a 50 términos relacionados con las posibilidades de navegación que permiten este tipo de análisis.
Existen dos arquitecturas diferentes para los sistemas OLAP: OLAP multidimensional (MOLAP) y OLAP relacionales (ROLAP).

2.2.5.1.1.-Sistemas MOLAP
La arquitectura MOLAP usa unas bases de datos multidimensionales para proporcionar el análisis, su principal premisa es que el OLAP está mejor implantado almacenando los datos multidimensionalmente. Por el contrario, la arquitectura ROLAP cree que las capacidades OLAP están perfectamente implantadas sobre bases de datos relacionales
Un sistema MOLAP usa una base de datos propietaria multidimensional, en la que la información se almacena multidimensionalmente, para ser visualizada multidimensionalmente.
El sistema MOLAP utiliza una arquitectura de dos niveles: La bases de datos multidimensionales y el motor analítico.
• La base de datos multidimensional es la encargada del manejo, acceso y obtención del dato.
• El nivel de aplicación es el responsable de la ejecución de los requerimientos OLAP. El nivel
de presentación se integra con el de aplicación y proporciona un interfaz a través del cual
los usuarios finales visualizan los análisis OLAP. Una arquitectura cliente/servidor permite a varios usuarios
acceder a la misma base de datos multidimensional.

La información procedente de los sistemas operacionales, se carga en el sistema MOLAP, mediante una serie de rutinas batch. Una vez cargado el dato elemental en la Base de Datos multidimensional (MDDB), se realizan una serie de cálculos en batch, para calcular los datos agregados, a través de las dimensiones de negocio, rellenando la estructura MDDB.
Tras rellenar esta estructura, se generan unos índices y algoritmos de tablas hash para mejorar los tiempos de accesos a las consultas.
Una vez que el proceso de compilación se ha acabado, la MDDB está lista para su uso. Los usuarios solicitan informes a través del interface, y la lógica de aplicación de la MDDB obtiene el dato.
La arquitectura MOLAP requiere unos cálculos intensivos de compilación. Lee de datos precompilados, y tiene capacidades limitadas de crear agregaciones dinámicamente o de hallar ratios que no se hayan precalculados y almacenados previamente.

2.2.5.1.2.-Sistemas ROLAP
La arquitectura ROLAP, accede a los datos almacenados en un Data Warehouse para proporcionar los análisis OLAP. La premisa de los sistemas ROLAP es que las capacidades OLAP se soportan mejor contra las bases de datos relacionales.
El sistema ROLAP utiliza una arquitectura de tres niveles. La base de datos relacional maneja los requerimientos de almacenamiento de datos, y el motor ROLAP proporciona la funcionalidad analítica.
• El nivel de base de datos usa bases de datos relacionales para el manejo, acceso y obtención del dato.
• El nivel de aplicación es el motor que ejecuta las consultas multidimensionales de los usuarios.
• El motor ROLAP se integra con niveles de presentación, a través de los cuales los usuarios realizan
los análisis OLAP.

Después de que el modelo de datos para el Data Warehouse se ha definido, los datos se cargan desde el sistema operacional. Se ejecutan rutinas de bases de datos para agregar el dato, si así es requerido por el modelos de datos.
Se crean entonces los índices para optimizar los tiempos de acceso a las consultas.
Los usuarios finales ejecutan sus análisis multidimensionales, a través del motor ROLAP, que transforma dinámicamente sus consultas a consultas SQL. Se ejecutan estas consultas SQL en las bases de datos relacionales, y sus resultados se relacionan mediante tablas cruzadas y conjuntos multidimensionales para devolver los resultados a los usuarios.
La arquitectura ROLAP es capaz de usar datos precalculados si estos están disponibles, o de generar dinámicamente los resultados desde los datos elementales si es preciso. Esta arquitectura accede directamente a los datos del Data Warehouse, y soporta técnicas de optimización de accesos para acelerar las consultas. Estas optimizaciones son, entre otras, particionado de los datos a nivel de aplicación, soporte a la desnormalización y joins múltiples.

2.2.5.1.3.-ROLAP vs. MOLAP (Comparativa)
Cuando se comparan las dos arquitecturas, se pueden realizar las siguientes observaciones:
• El ROLAP delega la negociación entre tiempo de respuesta y el proceso batch al diseño del sistema.
Mientras, el MOLAP, suele requerir que sus bases de datos se precompilen para conseguir un rendimiento aceptable
en las consultas, incrementando, por tanto los requerimientos batch.
• Los sistemas con alta volatilidad de los datos (aquellos en los que cambian las reglas de agregación
y consolidación), requieren una arquitectura que pueda realizar esta consolidación ad-hoc. Los sistemas
ROLAP soportan bien esta consolidación dinámica, mientras que los MOLAP están más orientados
hacia consolidaciones batch.
• Los ROLAP pueden crecer hasta un gran número de dimensiones, mientras que los MOLAP generalmente son
adecuados para diez o menos dimensiones.
• Los ROLAP soportan análisis OLAP contra grandes volúmenes de datos elementales, mientras que
los MOLAP se comportan razonablemente en volúmenes más reducidos (menos de 5 Gb)
Por ello, y resumiendo, el ROLAP es una arquitectura flexible y general, que crece para dar soporte a amplios requerimientos OLAP. El MOLAP es una solución particular, adecuada para soluciones departamentales con unos volúmenes de información y número de dimensiones más modestos.

2.2.5.2.- QUERY & REPORTING
Las consultas o informes libres trabajan tanto sobre el detalle como sobre las agregaciones de la información.
Realizar este tipo de explotación en un almacén de datos supone una optimización del tradicional entorno de informes (reporting), dado que el Data Warehouse mantiene una estructura y una tecnología mucho más apropiada para este tipo de solicitudes.
Los sistemas de "Query & Reporting", no basados en almacenes de datos se caracterizan por la complejidad de las consultas, los altísimos tiempos de respuesta y la interferencia con otros procesos informáticos que compartan su entorno.
La explotación del Data Warehouse mediante "Query & Reporting" debe permitir una gradación de la flexibilidad de acceso, proporcional a la experiencia y formación del usuario. A este respecto, se recomienda el mantenimiento de al menos tres niveles de dificultad:
• Los usuarios poco expertos podrán solicitar la ejecución de informes o consultas predefinidas según unos parámetros predeterminados.
• Los usuarios con cierta experiencia podrán generar consultas flexibles mediante una aplicación que proporcione una interfaz gráfica de ayuda.
• Los usuarios altamente experimentados podrán escribir, total o parcialmente, la consulta en un lenguaje de interrogación de datos.
Hay una extensa gama de herramientas en el mercado para cumplir esta funcionalidad sobre entornos de tipo Data Warehouse, por lo que se puede elegir el software más adecuado para cada problemática empresarial concreta.

2.2.5.3.- DATA MINING O MINERÍA DE DATOS
El Data Mining es un proceso que, a través del descubrimiento y cuantificación de relaciones predictivas en los datos, permite transformar la información disponible en conocimiento útil de negocio. Esto es debido a que no es suficiente "navegar" por los datos para resolver los problemas de negocio, sino que se hace necesario seguir una metodología ordenada que permita obtener rendimientos tangibles de este conjunto de herramientas y técnicas de las que dispone el usuario.
Constituye por tanto una de las vías clave de explotación del Data Warehouse, dado que es este su entorno natural de trabajo.
Se trata de un concepto de explotación de naturaleza radicalmente distinta a la de los sistemas de información de gestión, dado que no se basa en coeficientes de gestión o en información altamente agregada, sino en la información de detalle contenida en el almacén. Adicionalmente, el usuario no se conforma con la mera visualización de datos, sino que trata de obtener una relación entre los mismos que tenga repercusiones en su negocio.

2.2.5.3.2.Técnicas de Data Mining
Para soportar el proceso de Data Mining, el usuario dispone de una extensa gama de técnicas que le pueden ayudar en cada una de las fases de dicho proceso, las cuales pasamos a describir:
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.
4. 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.
5. 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.
6. 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.

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.

2.2.5.3.3. Metodología de aplicación:
Para utilizar estas técnicas de forma eficiente y ordenada es preciso aplicar una metodología estructurada, al proceso de Data Mining. A este respecto proponemos la siguiente metodología, siempre adaptable a la situación de negocio particular a la que se aplique:
Muestreo
Extracción de la población muestral sobre la que se va a aplicar el análisis. En ocasiones se trata de una muestra aleatoria, pero puede ser también un subconjunto de datos del Data Warehouse que cumplan unas condiciones determinadas. El objeto de trabajar con una muestra de la población en lugar de toda ella, es la simplificación del estudio y la disminución de la carga de proceso. La muestra más óptima será aquella que teniendo un error asumible contenga el número mínimo de observaciones.
En el caso de que se recurra a un muestreo aleatorio, se debería tener la opción de elegir
• El nivel de confianza de la muestra (usualmente el 95% o el 99%).
• El tamaño máximo de la muestra (número máximo de registros), en cuyo caso el sistema deberá informar del el error cometido y la representatividad de la muestra sobre la población original.
• El error muestral que está dispuesto a cometer, en cuyo caso el sistema informará del número de observaciones que debe contener la muestra y su representatividad sobre la población original.
Para facilitar este paso s debe disponer de herramientas de extracción dinámica de información con o sin muestreo (simple o estratificado). En el caso del muestreo, dichas herramientas deben tener la opción de, dado un nivel de confianza, fijar el tamaño de la muestra y obtener el error o bien fijar el error y obtener el tamaño mínimo de la muestra que nos proporcione este grado de error.
Exploración
Una vez determinada la población que sirve para la obtención del modelo se deberá determinar cuales son las variables explicativas que van a servir como "inputs" al modelo. Para ello es importante hacer una exploración por la información disponible de la población que nos permita eliminar variables que no influyen y agrupar aquellas que repercuten en la misma dirección.

El objetivo es simplificar en lo posible el problema con el fin de optimizar la eficiencia del modelo. En este paso se pueden emplear herramientas que nos permitan visualizar de forma gráfica la información utilizando las variables explicativas como dimensiones.
También se pueden emplear técnicas estadísticas que nos ayuden a poner de manifiesto relaciones entre variables. A este respecto resultará ideal una herramienta que permita la visualización y el análisis estadístico integrados
Manipulación
Tratamiento realizado sobre los datos de forma previa a la modelización, en base a la exploración realizada, de forma que se definan claramente los inputs del modelo a realizar (selección de variables explicativas, agrupación de variables similares, etc.).
Modelización
Permite establecer una relación entre las variables explicativas y las variables objeto del estudio, que posibilitan inferir el valor de las mismas con un nivel de confianza determinado.
Valoración
Análisis de la bondad del modelo contrastando con otros métodos estadísticos o con nuevas poblaciones muestrales.

2.2.5.4.- WEBHOUSING
La popularización de Internet y la tecnología Web, ha creado un nuevo esquema de información en el cual los clientes tienen a su disposición unas cantidades ingentes de información. La integración de las tecnologías Internet y Data Warehouse tienen una serie de ventajas como son:
• Consistencia: toda la organización accede al mismo conjunto de datos y ve los informes que reflejan
sus necesidades. Hay una "única versión de la verdad".
• Accesibilidad: la empresa acede a la información a través de un camino común (el browser
de Internet), simplificando el proceso de búsqueda de la información.
• Disponibilidad: la información es accesible en todo momento, independientemente de los sistemas operacionales.
• Bajos costes de desarrollo y mantenimiento, debidos a la estandarización de las aplicaciones de consultas
basadas en Internet, independientemente del sistema operativo que soporte el browser, y de la reducción
de los costes de distribución de software en los puestos clientes.
• Protección de los datos, debido al uso de tecnologías consolidadas de protección en entornos
de red (firewalls).
• Bajos costes de formación, debido al uso de interfaces tipo Web.
La interactividad de las aplicaciones en este entorno pueden tener varios niveles:
• Publicación de datos: las páginas distribuyen información obtenida del Data Warehouse,
volcada en las páginas intra/internet.
• Distribución de reportes: dando soporte a consultas simples elaboradas por los usuarios.
• Aplicaciones dinámicas: sirviendo de soporte de decisión a servicios solicitados desde el puesto
cliente, ejecutando la petición en el servidor y devolviéndolas al cliente, vía el browser
de Internet o haciendo uso de "applets" de Java.
Las arquitecturas base de una implantación de Data Warehouse en Internet, pueden tener las siguientes
alternativas:
1. Usar el Servidor Internet como router, y ejecutar la petición desde el cliente al servidor directamente.
2. Hacer uso del navegador para visualizar una página Internet residente en el servidor de Internet. Esta
página contendría información que se actualizaría en el servidor Internet, desde el
servidor DW, a petición del usuario haciendo uso de CGI's.
3. El cliente podría lanzar su consulta directamente al servidor de DW, con "applets" de Java,
haciendo el servidor Internet únicamente de encaminamiento (router).
4. El cliente podría ejecutar la aplicación DW desde el navegador, pero con un plug-in, que haría
que se tuvieran las mismas opciones que la aplicación DW.
5. Realizar una descarga masiva de datos con un protocolo de transferencia de ficheros (FTP), para su proceso
en local.

El alcance funcional de la implantación del Data Warehouse, basado en tecnologías Internet, puede ser la misma que la realizada sin su uso. En este sentido las críticas que se le pueden achacar en la actualidad, provienen de la baja velocidad de las líneas actuales, que se solventa parcialmente mediante el uso de aplicaciones Java, en lugar de hacer uso de páginas HTML, o CGI. Solución parcial, mientras la velocidad de transferencia se incrementa día a día mediante nuevos algoritmos de compresión de datos o el uso de líneas de alta capacidad RDSI.

2.2.6.- TIPOS DE APLICACIONES EN LAS QUE UTILIZAR LAS TÉCNICAS DISPONIBLES SOBRE EL DW
2.2.6.1. Data Warehouse y Sistemas de Marketing
La aplicación de tecnologías de Data Warehouse supone un nuevo enfoque de Marketing, haciendo uso del Marketing de Base de Datos. En efecto, un sistema de Marketing Warehouse implica un marketing científico, analítico y experto, basado en el conocimiento exhaustivo de clientes, productos, canales y mercado.
Este conocimiento se deriva de la disposición de toda la información necesaria, tanto interna como externa, en un entorno de Data Warehouse, persiguiendo con toda esta información, la optimización de las variables controladas del Marketing Mix y el soporte a la predicción de las variables no controlables (mediante técnicas de Data Mining). Basándose en el conocimiento exhaustivo de los clientes se consigue un tratamiento personalizado de los mismos tanto en el día a día (atención comercial) como en acciones de promoción específicas.

Las áreas en las que se puede aplicar las tecnologías de Data Warehouse a Marketing son, entre otras:
• Investigación Comercial
• Segmentación de mercados
• Identificación de necesidades no cubiertas y generación de nuevos productos, o modificación de productos existentes
• Fijación de precios y descuentos
• Definición de la estrategia de canales de comercialización y distribución
• Definición de la estrategia de promoción y atención al cliente
• Relación con el cliente:
• Programación, realización y seguimiento de acciones comerciales
• Lanzamiento de nuevos productos
• Campañas de venta cruzada, vinculación, fidelización, etc.
• Apoyo al canal de venta con información cualificada

2.2.6.2. Data Warehouse y Análisis de Riesgo Financiero
El Data Warehouse aplicado al análisis de riesgos financieros ofrece capacidades avanzadas de desarrollo de aplicaciones para dar soporte a las diversas actividades de gestión de riesgos. Es posible desarrollar cualquier herramienta utilizando las funciones que incorpora la plataforma, gracias a la potencionalidad estadística aplicada al riesgo de crédito.
Así se puede usar para llevar a cabo las siguientes funcionalidades:
• Para la gestión de la posición:
Determinación de la posición, Cálculo de sensibilidades, Análisis what/if, Simulaciones, Monitorización riesgos contra límites, etc.
• Para la medición del riesgo:
Soporte metodología RiskMetrics (Metodología registrada de J.P. Morgan / Reuters), Simulación de escenarios históricos, Modelos de covarianzas, Simulación de Montecarlo, Modelos de valoración, Calibración modelos valoración, Análisis de rentabilidad, Establecimiento y seguimiento. de límites, Desarrollo/modificación modelos, Stress testing, etc.
El uso del Data Warehouse ofrece una gran flexibilidad para creación o modificación de modelos propios de valoración y medición de riesgos, tanto motivados por cambios en la regulación, como en avances en la modelización de estos instrumentos financieros.
Ello por cuanto se puede almacenar y poner a disposición información histórica de mercado y el uso de técnicas de Data Mining nos simplifica la implantación de cualquier método estadístico. Los métodos de previsión, se pueden realizar usando series históricas, (GARCH, ARIMA, etc.)

Pero la explotación de la información nos permite no solo la exploración de los datos para un conocimiento de la información histórica, sino también para examinar condiciones de normalidad de las que la mayoría de las metodologías de valoración del riesgo parten.
Además de implantar modelos ya existentes, se pueden acometer análisis con vistas a determinar modelos propios, basados en análisis de correlación para el estudio de la valoración del riesgo de carteras o procesos de simulación de Montecarlo.
Todo ello en una plataforma avanzada de gestión de la información basada en la fácil visualización de la misma y de su análisis estadístico como soporte a metodologías estándar de facto, o a las particularidades de cada entorno.

2.2.6.3. Data Warehouse y Análisis de Riesgo de Crédito
La información relativa a clientes y su entorno se ha convertido en fuente de prevención de Riesgos de Crédito. En efecto, existe una tendencia general en todos los sectores a recoger, almacenar y analizar información crediticia como soporte a la toma de decisiones de Análisis de Riesgos de Crédito.
Los avances en la tecnología de Data Warehouse hacen posible la optimización de los sistemas de Análisis de Riesgo de Crédito:
Para la gestión del riesgo de crédito los sistemas operacionales han ofrecido:
• Sistemas de Información para Gerencia (MIS) e informes de Soporte a la Decisión de Problemas (DSS) estáticos y no abiertos a nuevas relaciones y orígenes de datos, situación en la que la incorporación de nuevas fuentes de información ha sido un problema en lugar de una ventaja.
• Exploraciones de datos e informes cerrados y estáticos.
• Análisis sin inclusión de consideraciones temporales lo que imposibilita el análisis del pasado y la previsión del futuro.
• Herramientas de credit-scoring no flexibles, construidas sobre algoritmos difícilmente modificables, no adaptados al entorno de la empresa, o exclusivamente basados en la experiencia personal no contrastada, con lo que los sistemas han ayudado a repetir los errores en vez de a corregirlos.

Pero estos sistemas tradicionales se enfrentan a una problemática difícil de resolver para acomodarse a las necesidades analíticas de los Sistemas de Análisis del Riesgo, necesidades que se pueden cubrir mediante el uso de tecnologías de Data Warehouse
Dentro de la Prevención de Impagados, utilizando sistemas OLAP se puede obtener el grado interno de concentración de riesgos con el cliente, y almacenar la variedad de fuentes internas o externas de información disponibles sobre el mismo. Ello nos permite obtener sin dificultad la posición consolidada respecto al riesgo del cliente. El análisis se puede realizar asimismo por las diferentes características de la operación para la que se realiza el análisis, en cuanto al plazo y la cuantía de la misma, la modalidad de crédito elegida, la finalidad de la operación o las garantías asociadas a la misma. Usando las mismas capacidades es fácil el establecer una segmentación ABC de la cartera de clientes potenciales o reales que nos optimicen el nivel de esfuerzo en el Análisis de Riesgos.

En el soporte al proceso de Anticipación al Riesgo, se puede dar un adecuado soporte a la correcta generación y consideración de señales de alerta, teniendo en cuenta las pautas y condicionantes diferenciados dependiendo del tipo de cliente y producto usando Data Mining

Para el caso del Seguimiento del ciclo de Impagados, de nuevo el uso de sistemas OLAP, simplifican el análisis la diversidad de los diferentes parámetros que intervienen en el mismo, tales como la jerarquía de centros de recobro a contemplar, la diferente consideración dependiendo de la antigüedad del impago, del cliente o del importe impagado. Un sistema de Data Mining puede aconsejar la mejor acción en caso de impagados, litigio, precontencioso, etc. frente a los parámetros de importe, antigüedad, zona geográfica, etc.
Estos sistemas hacen que el analista se dedique con más intensidad al análisis de la información, que es donde aporta su mayor valor añadido, que a la obtención de la misma. No obstante, estos sistemas deben de huir de las automatizaciones completas sin intervención del analista: es él el que mejor sabe lo que quiere descubrir. "La herramienta debe ser un medio y no un fin".

2.2.6.4. Data Warehouse: Otras áreas de aplicación
Otras áreas de la empresa han aplicado las soluciones que proporciona la tecnología Data Warehouse para mejorar gran parte de sus procesos actuales. Entre ellas destacamos:
• Control de Gestión:
Sistemas de Presupuestación, Análisis de Desviaciones, Reporting (EIS, MIS, etc.)
• Logística:
Mejora de la relación con proveedores, Racionalización de los procesos de control de inventarios, Optimización de los niveles de producción, Previsión de la demanda en infraestructura.
• Recursos Humanos
Planificación de incorporaciones, Gestión de carreras profesionales, Asignación de recursos a proyectos alternativos, etc.

2.2.7.- SEGURIDAD DE ACCESO Y MANIPULACIÓN DE LA INFORMACIÓN EN EL DW
A continuación trataremos las consideraciones a contemplar en cuanto a seguridad de accesos y seguridad de datos (backup), puesto que si bien la seguridad de accesos (al nivel de datos y de aplicación) debe ser tratada de la misma manera que en los sistemas operacionales, los procedimientos de copias de seguridad merecen un especial tratamiento.
Tal y como ocurre en los sistemas operacionales, un sistema Data Warehouse debe poder realizar procedimientos de recuperación de la información desde cualquier momento en el que los datos estaban validados. Un Data Warehouse, debe poder contar con procedimientos de recuperación, que permitan recuperar los datos ante cualquier situación de catástrofe.
No obstante, es preciso tener en cuenta otras consideraciones, así por ejemplo dependiendo del tamaño de un Data Mart, se puede elegir no realizar un backup, sino realizar un refresco especial desde los datos operacionales, dependiendo de la periodicidad estándar de carga.
En cuanto a la seguridad de acceso, se cumple en los sistemas de Data Warehouse, que es preciso el implantar niveles de acceso a la información, realizando un plan completo de seguridad que contemple:
• Acceso a recursos de la red (local o intranet)
• Asignación de usuarios a grupos con perfiles de seguridad diferenciados
• Asignación de niveles de autorización de aplicación a grupos de usuarios
• Seguridad a nivel de Base de Datos, mediante los procedimientos provistos por las mismas.
• Etc.

2.3.- TENDENCIAS TECNOLÓGICAS Y DE MERCADO
Describimos a continuación una recopilación de las principales tendencias observadas en el mercado. Estas tendencias se han comentado con anterioridad en otros apartados de esta Guía y se hace referencia a dichos puntos.
Tendencias hacia herramientas especializados:
El uso de herramientras de propósito general no satisface por completo las necesidades de un proyecto de Data Warehouse. Se ha comentado en esta guía las Herramientas de usuario final y tecnológicas, en el que se muestran para cada paso de la creación de un Data Warehouse, una lista de los principales vendedores y sus direcciones Web.
Webhousing
El uso de Internet como fuente de información hacia el exterior e interior (via intranets), crece constantemente, y la integración de una herramienta de Data Warehouse con Internet, se comenta en el apartado de Webhousing
Uso generalizado de Data Marts
Las peculiaridades de un proyecto Data Warehouse, y el enfoque progresivo de su construcción, hace que cada vez mas organizaciones realicen sus desarrollos mediante el uso de Data Marts integrados, tal y como comentabamos en el apartado Data Warehouse vs. Data Mart
Uso de tecnología OLAP
Este aspecto está comentado con amplitud en el apartado OLAP, ROLAP, MOLAP

3.- ASPECTOS TÉCNICOS EN EL PROCESO DE CREACIÓN Y EXPLOTACIÓN DEL DW
En este capítulo se pretende dar la orientación suficiente al comprador para la preparación del conjunto de especificaciones que definirán los requisitos que han de cumplir la Creación y Explotación de un Data Warehouse.
Se realiza en primer lugar un análisis de las necesidades del comprador, a continuación se recogen los factores relevantes a tener en cuenta en el proceso de adquisición y, finalmente, se describe cómo deben ser planteadas las especificaciones técnico - funcionales para la elaboración del Pliego de Prescripciones Técnicas, qué normas, estándares y cláusulas tipo pueden ser de aplicación, y cuál es el cuestionario técnico diseñado para normalizar las ofertas y facilitar su evaluación.

3.1.- ANÁLISIS DE LAS NECESIDADES DEL COMPRADOR
Incluimos aquí unos pasos que, tal y como se comentaban en la Fases de implantación de un Data Warehouse , son previos al inicio de un proyecto de este tipo.
En efecto, como punto de arranque de todo, es preciso "vender la idea" a los usuarios finales de un Data Warehouse. Esto es así, por ser una idea bastante novedosa y sobre la que pueden surgir recelos de su efectividad. Estos recelos se pueden eliminar comenzando por un pequeño módulo, del cual se valoren los beneficios posteriores, para iniciar progresivamente el desarrollo de nuevos módulos, cada uno con un coste unitario cada vez más reducido, pero sin embargo con unos beneficios distribuidos cada vez mayores por poder cada vez incluir más información. (Ver Data Warehouse vs. Data Mart) para comprobar un caso de este tipo.
El simple hecho de realizar un informe de necesidades previas en el que se enumeren la situación de los datos entre los diversos sistemas operacionales, puede ser un hecho decisivo para emprender un proyecto de este tipo. Muchas veces la información existente se encuentra tan poco normalizada, existen tantas discrepancias entre estos sistemas, que el abordar un Data Warehouse en el que se limpien estos datos y se normalicen pueden aportar un valor intangible: "la calidad y fiabilidad de la información".

La venta de esta idea no sólo se ha de realizar frente a la Dirección sino que es preciso realizarla a todos los niveles: a la Dirección, Gerencia e incluso al área de Desarrollo.

Tras esta venta de la idea, comienzan dos fases similares al análisis de requisitos del sistema (ARS según abreviaturas de la metodología METRICA): la definición de objetivos y requerimientos de información, en el que se analicen las necesidades del comprador.

Definición de los objetivos
En esta fase se definirá el equipo de proyecto que debe estar compuesto por representantes del departamento informático y de los departamentos usuarios del Data Warehouse además de la figura de jefe de proyecto.
Se definirá el alcance del sistema y cuales son las funciones que el Data Warehouse realizará como suministrador de información de negocio estratégica para la empresa. Se definirán así mismo, los parámetros que permitan evaluar el éxito del proyecto.

Definición de los requerimientos de información
Durante esta fase se mantendrán sucesivas entrevistas con los representantes del departamento usuario final y los representantes del departamento de informática. Se realizará el estudio de los sistemas de información existentes, que ayudaran a comprender las carencias actuales y futuras que deben ser resueltas en el diseño del Data Warehouse
Asimismo, en esta fase el equipo de proyecto debe ser capaz de validar el proceso de entrevistas y reforzar la orientación de negocio del proyecto. Al finalizar esta fase se obtendrá el documento de definición de requerimientos en el que se reflejarán no solo las necesidades de información de los usuarios, sino cual será la estrategia y arquitectura de implantación del Data Warehouse.

3.2.- FACTORES RELEVANTES EN EL PROCESO DE ADQUISICIÓN
En la definición del objeto del contrato y los requisitos inherentes al mismo, así como en la valoración y comparación de ofertas de los licitadores pueden intervenir muchos factores y de muy diversa índole.
Es de suma importancia que todos los factores relevantes que intervienen en el proceso de contratación queden debidamente recogidos en el pliego de prescripciones técnicas que regule el contrato. Así mismo, es conveniente que las soluciones ofertadas por los licitadores sean recogidas en los cuestionarios disponibles a tal efecto:
• De empresa
• Económicos
• Técnicos particulares
Se van a relacionar a continuación algunos de los factores que suelen tener mayor peso al seleccionar una herramienta de Data Warehouse. Sin embargo, debe tenerse en cuenta que la importancia de cada factor variará en función de cada caso particular, por lo que siempre será necesario identificar la importancia relativa de cada punto. Los puntos a contemplar son bastante similares a los contemplados en el apartado homónimo de los SGBD, que adaptaremos a la casuística particular de un Data Warehouse.
Pruebas en condiciones reales
Tal y como sucedía en los SGBD, el rendimiento real de un Data Warehouse es muy difícil de predecir mediante procedimientos teóricos. Por ello, de igual forma que en el SGBD, si se va a instalar un Data Warehouse que contendrá un gran volumen de datos o, si por cualquier otra razón, existen dudas sobre la capacidad del Data Warehouse de dar unas prestaciones adecuadas en las máquinas disponibles se debe exigir al suministrador una prueba anterior a la adquisición del Data Warehouse. Esta prueba debe realizarse en la propia instalación de destino.
La prueba se debería realizar en las condiciones más parecidas a las reales que se puedan conseguir. Para ello se deberá cargar el Data Warehouse con un volumen de datos adecuado y se deberán crear procesos de prueba similares a los más costosos de los que se vayan a desarrollar.
A diferencia de con los SGBD, no es preciso realizar la prueba en momentos de gran carga, por la diferente filosofía de un almacén de datos orientado al conocimiento, pero sí que será preciso la comprobación de la compatibilidad de la herramienta para los procesos de extracción y carga desde los diferentes sistemas operacionales (sistemas operativos, bases de datos, etc.) implicados .
Volumen y organización de los datos
Debe estar garantizado que el Data Warehouse es capaz de tratar el volumen de datos que se vaya a necesitar en la instalación. Para ello debe verificarse no sólo que el Data Warehouse puede manejar el volumen total de datos, sino que no existe ninguna limitación que impide organizarlo de la forma más conveniente.
No obstante, en este sentido y como factor común de un SGBD con un Data Warehouse, cabe reseñar que muchos problemas de rendimiento se deben más veces a un mal diseño del modelo de datos del Data Warehouse que a un problema de rendimiento de la herramienta en sí.
Dimensionamiento de la plataforma de instalación
De lo comentado en los dos puntos anteriores puede deducirse que existe la posibilidad de que sea necesario redimensionar la máquina en la que se instale el Data Warehouse, o mejor aun, disponer de una dedicada al Data Warehouse.
Es necesario que el suministrador detalle cual de las dos versiones está ofreciendo para cada una de las licencias que se compren y si alguna de ellas fuese una versión limitada, que especifique claramente cuales de las funcionalidades ofertadas no se encuentran presentes en la versión restringida.
Condiciones económicas y del soporte
Existen actualmente varios sistemas de cobro por el uso de Data Warehouse según el fabricante. Los más utilizados son facturar por:
• Cada máquina y/o tipo de máquina en la que se instale.
• Cada usuario que acceda al SGBD.
• Por tiempo de utilización (usualmente renovación anual).
• Por combinación de las anteriores.
Es imprescindible que el suministrador indique con toda claridad el método utilizado.
También debe explicitarse que, salvo indicación en contrario, todas las licencias son de versiones completas sin ninguna restricción respecto a las funcionalidades ofertadas.
También es conveniente pedir los precios de los productos adicionales que no se desee instalar en el momento pero que puedan ser interesantes en el futuro.
Otro factor importante es la duración de la garantía, período de tiempo durante el que el suministrador proporcionará soporte gratuito a sus productos y, también el precio del soporte en años sucesivos. Este último precio debe fijarse sobre variables presentes en el contrato no sobre futuros precios de lista del fabricante.
Otro factor que debe evaluarse es la calidad del soporte ofrecido. Este puede dividirse en un gran número de puntos cuya importancia variará en función de las necesidades del comprador. Entre ellos, se pueden citar:
• La inclusión o no de la instalación en el precio del producto.
• El tiempo máximo de entrega.
• La inclusión o no de prestaciones adicionales gratuitas como puede ser un cierto número de horas de formación.
• Capacitación y experiencia del personal que presta soporte técnico y consultoría.
• Calidad de la documentación, idioma en que está escrita, número de copias suministradas gratuitamente y precio de las copias adicionales.
• Capacidad técnica de la empresa y de la asistencia técnica que presta para lo que es recomendable pedir referencias a otros usuarios de la Administración de este tipo de productos.

3.3.- DISEÑO DEL PLIEGO DE PRESCRIPCIONES TÉCNICAS PARTICULARES
Debido a la no existencia de ninguna norma o estándar aplicable a un Data Warehouse, mas que estándares de facto, describimos a continuación cuestionarios técnicos de normalización y valoración de ofertas de SGBD.
Estos cuestionarios han de partir de unas especificaciones previas de:
Entorno Hardware:
Host: (Tipo Máquina, Sistema Operativo y Base de Datos Operacional)
Servidor de la aplicación de DW (Tipo Máquina, Nº procesadores, Memoria total y por procesador, Sistema Operativo, Capacidad de Disco)
Clientes (Tipo de Máquina, Memoria, Sistema Operativo, Capacidad de Disco)
Red local (Topología, Protocolos, Sofware de Cliente y Número de Usuarios soportados)
Entorno Software:
Gestor de Base de Datos para el Data Warehouse
Volumen estimado de la Base de Datos
A continuación y dependiendo del ámbito de aplicación del Data Warehouse describimos un cuestionario aplicado a la creación del Data Warehouse por un lado, por otro del Análisis de la Calidad del dato y la depuración, y por último de su Explotación.

3.3.1.- CUESTIONARIO PARA LA EXTRACCIÓN, MOVIMIENTO Y CARGA
Con carácter general y a fin de utilizar la información recopilada de cara a la contratación, es importante destacar que los datos recogidos en este cuestionario están dirigidos a obtener un resumen estructurado de la oferta y a demostrar la solvencia técnica o profesional de la empresa en aquellos casos en que no sea requerida la clasificación de la misma. Dicha información sólo servirá de base a la valoración cuando esté relacionada con lo expresado en la cláusula "Criterios de adjudicación del contrato", siendo, en el resto de los casos, de carácter meramente informativo.
Nota: (*) significa que hay que indicar "1" en caso afirmativo.
(**) significa que hay que repetir para cada sistema operativo ofertado.
Cuestión Respuesta Referencia a

oferta (Página)
------------------------------------------
ENTORNO OPERATIVO
- REQUERIMIENTOS LÓGICOS
. Especificar para cada uno de las paquetes software ofertados la o las posibles
plataformas (servidor central, servidor intermedio y cliente) donde podrían instalarse, detallando los requerimientos
físicos y lógicos asociados a cada alternativa, junto con los procesos que se ejecutarían
en cada una de las posibles plataformas [ ] [ ]
. Compatibilidad con Sistemas operativos (Enumerar) [ ] [ ]

. Compatibilidad con software de red [ ] [ ]
. Necesidad de software adicional [ ] [ ]
- REQUERIMIENTOS FÍSICOS
. Especificar detalladamente los requerimientos físicos mínimos
y recomendados, tales como memoria RAM, espacio libre en disco, procesadores, etc... [ ] [ ]
CARACTERÍSTICAS GENERALES
- FUENTES DE DATOS (ORIGEN) SOPORTADAS
. Permite extraer datos desde varias plataformas origen simultáneamente [ ] [ ]
. Indicar las distintas fuentes de datos operacionales a las que es posible acceder,
especificando en los casos que sea necesario las últimas versiones certificadas. [ ] [ ]
Ficheros planos [ ] [ ]
Acceso a bases de datos [ ] [ ]
Otras fuentes operacionales [ ] [ ]
Consideraciones a tener en cuenta [ ] [ ]

- BASES DE DATOS DESTINO SOPORTADAS
. Permite cargar datos en varias plataformas destino simultáneamente [ ] [ ]
.Gestores de bases de datos destino soportados, especificando las

últimas versiones certificadas

- FUNCIONALIDADES
. Enumerar las funcionalidades de la o las herramientas propuestas:
Permite manejar (leer/escribir) cadenas de caracteres de longitud variable
No limita el número de dígitos de los formatos numéricos
Es posible aplicar reglas de transformación a los números con
formato en coma flotante

Otras funcionalidades (especificar) [ ] [ ]

- TRATAMIENTO INTERMEDIO DE LOS DATOS RECUPERADOS
.Realiza un almacenamiento intermedio de los datos recuperados a partir de
los sistemas operacionales
. Especificar
Almacenamiento intermetdio físico de los datos
Fichero plano
Memoria
BBDD propia
BBDD externa
Otros
Localización
Puesto cliente
Servidor intermedio
Servidor central
Otros
Técnicas aplicadas sobre los datos intermedios
Compresión
Encriptación
Otros

Explicar el consumo de recursos asociado a este almacenamiento intermedio de los datos [ ] [ ]

- BASE DE DATOS COMO FUENTE DE DATOS OPERACIONALES
. Conocimiento de la estructura de la base de datos
Requiere algún software adicional que permita el acceso a las BBDD
para tal funcionalidad [ ] [ ]
. Detección a captura de modificaciones en la estructura de las bases
de datos
Requiere algún software adicional que permita el acceso a las BBDD
para tal funcionalidad
Explicar con detalle los mecanismos utilizados para la detección de
cambios en la estructura de las bases de datos
Es posible automatizar la detección de dichos cambios
Es posible automatizar la captura de los cambios realizados en la estructura
de las bases de datos
Indicar si la herramienta es capaz de detectar automáticamente las
transformaciones a las que afectan las modificaciones realizadas
Es necesario parar las bases de datos para realizar el proceso de captura
de cambios

Observaciones [ ] [ ]

. Acceso a las bases de datos
Requiere algún software adicional que permita el acceso a las BBDD
para tal funcionalidad
Acceden directamente a la base de datos los programas generados por la herramienta
Indicar cómo se obtienen los ficheros de descarga de los datos
Mediante una utilidad de la propia herramienta
A través de una utilidad de la BBDD
Mediante un desarrollo a medida

Otros (especificar)) [ ] [ ]

. Detección y captura de las modificaciones en los datos
Requiere algún software adicional que permita el acceso a las BBDD
para tal funcionalidad
Es posible automatizar la detección de estas modificaciones
Explicar detalladamente los mecanismos utilizados para la captura de dichas
modificaciones
Es posible automatizar la captura de dichas modificaciones
Indicar si la herramienta es capaz de detectar automáticamente las
transformaciones a las que afectan las modificaciones realizadas.

Es necesario parar las bases de datos para realizar el proceso de captura de las modificaciones realizadas sobre
los datos (Observaciones) [ ] [ ]

- RECOMENDACIONES PRÁCTICAS
. Enumerar las principales recomendaciones prácticas para asegurar una
plena explotación de la potencialidad de los paquetes software ofertados

. Enumerar y justificar brevemente los puntos fuertes tanto de la arquitectura funcional propuesta como de
las herramientas ofertadas [ ] [ ]

FUNCIONALIDAD
- FACILIDAD DE USO
. Especificar los idiomas soportados en cada una de las siguientes áreas:
Aplicación
Ayuda on-line
Manuales de ayuda
Soporte
. Soporta alfabetización internacional
. Dispone de ayuda on-line
. Es posible la presentación preliminar de la documentación
generada antes de imprimirla
. Posee un interfaz gráfico que permita tener una visión global
de las tablas incluidas en los sistemas operacionales y en el Data Warehouse
. Especificar detalladamente los diferentes perfiles de usuario contemplados
para cada una de las herramientas ofertadas, así como la curva de aprendizaje (en horas) para cada uno de
ellos.
. Posee un Editor de Diagramas que facilite las tareas de diseño de
los flujos de datos y de las transformaciones a aplicar [ ] [ ]

- PROCESOS DE EXTRACCIÓN Y TRANSFORMACIÓN
. Indicar el paquete software ofertado que incluye esta funcionalidad
y la plataforma o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente esta funcionalidad
. Es posible automatizar completamente los procesos de extracción y
transformación
. Se puede integrar con el planificador externo de tareas
. Explicar detalladamente el mecanismo de acceso a las estructuras de
las bases de datos, tanto operacionales como del Data Warehouse
. Explicar el mecanismo de extracción de los datos desde los sistemas
operacionales detallando concretamente de dónde los extraen y si se utilizan ficheros secuenciales intermedios
. Detallar los procedimientos de depuración incorporados
. Indicar las funciones de transformación más importantes incluidas
en el producto:
Importación desde ficheros planos de reglas de transformación
previamente definidas Validación y sustitución de los campos de una tabla en base a los campos de
otras tablas
Cálculos aritméticos propios de sumarización de la información
Conversión de formatos de fecha
Definición de reglas de negocio
Llamadas a subrutinas externas
Otras
. Es posible definir reglas de transformación generales que se puedan
parametrizar mediante variables para casos concretos
. En caso de exclusión de datos en base a reglas de transformación,
indicar si se pueden almacenar
. Indicar:
Almacenamiento físico de los datos excluidos
Fichero plano
Base de Datos propia
Base de Datos externa
Otros
Localización física de los datos excluidos
Puesto cliente
Servidor intermedio
Servidor central

Otros [ ] [ ]

- CARACTERÍSTICAS DE LOS PROGRAMAS GENERADOS
. Especificar el lenguaje utilizado en la generación de código
para las distintas fuentes soportadas

. Indicar si genera también los JCL o scripts de compilación y ejecución

. Es posible modificar los esqueletos de los programas a generar

. Enumerar los tipos de programas generados, con una breve descripción de los mismos, y las plataformas
(destino u origen) donde deben ser ejecutados [ ] [ ]

- GENERACIÓN DE DOCUMENTACIÓN
. Posee un Generador de Informes que automatice la generación de la
documentación sobre los procesos de extracción y transformación
. Indicar el paquete software ofertado que incluye esta funcionalidad
y la plataforma o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente esta funcionalidad
. Describir la información incluida en dicha documentación
Origen de los datos
Correspondencias
Transformaciones
Reglas de negocio aplicadas
Otras (especificar))
. Soporta el versionado de la documentación generada
. Se proporciona algún software que facilite el mantenimiento
y versionado de la documentación [ ] [ ]

- CARACTERÍSTICAS DEL ENTORNO FUNCIONAL
. Especificar el software mínimo que es necesario tener instalado
en las diferentes plataformas

. La transferencia de los programas generados desde el puesto cliente hasta los sistemas operacionales y el Data
Warehouse es automática

. Son necesarios otros requisitos software adicionales, como por ejemplo compiladores (Observaciones) [ ] [ ]

- DETECCIÓN Y CAPTURA DE MODIFICACIONES
. Indicar el paquete software ofertado que incluye esta funcionalidad
y la plataforma o plataformas donde ha de instalarse

. Requiere algún software adicional que complemente esta funcionalidad

. Explicar con detalle los mecanismos utilizados para la detección de cambios en la estructura de las
bases de datos del Data Warehouse

. Es posible automatizar la detección de dichos cambios

. Explicar detalladamente los mecanismos utilizados para la captura de dichos cambios

. Es posible automatizar la captura de los cambios realizados en la estructura de las bases de datos del Data Warehouse

. Indicar si la herramienta es capaz de detectar automáticamente las transformaciones a las que afectan
los cambios realizados

. Es necesario parar las bases de datos del Data Warehouse para realizar el proceso de captura de cambios (Observaciones) [ ] [ ]

- DETECCIÓN Y CAPTURA DE MODIFICACIONES EN LA ESTRUCTURA DE LAS BASES
DE DATOS DE DATA WAREHOUSE
. Indicar el paquete software ofertado que incluye esta funcionalidad y
la plataforma o plataformas donde ha de instalarse

. Requiere algún software adicional que complemente esta funcionalidad

. Explicar con detalle los mecanismos utilizados para la detección de modificaciones en los datos de
los sistemas operacionales fuente, enumerando las principales consideraciones a tener en cuenta

. Es posible automatizar la detección de estas modificaciones

. Explicar detalladamente los mecanismos utilizados para la captura de dichas modificaciones

. Es posible automatizar la captura de dichas modificaciones

. Indicar si la herramienta es capaz de detectar automáticamente las transformaciones a las que afectan
las modificaciones realizadas

. Es necesario parar las bases de datos operacionales para realizar el proceso de captura de las modificaciones
realizadas sobre los datos (Observaciones) [ ] [ ]

. Detección y captura de modificaciones en los datos de los
sistemas operacionales.
Indicar el paquete software ofertado que incluye esta funcionalidad y la plataforma
o plataformas donde ha de instalarse.

Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
Explicar con detalle los mecanismos utilizados para la detección de modificaciones
en los datos de los sistemas operacionales fuente, enumerando las principales consideraciones a tener en cuenta.

Posibilidad de automatizar la detección de estas modificaciones [ ] [ ]
Explicar detalladamente los mecanismos utilizados para la captura de dichas modificaciones.

Posibilidad de automatizar la captura de dichas modificaciones [ ] [ ]
Herramienta es capaz de detectar automáticamente las transformaciones
a las que afectan las modificaciones realizadas [ ] [ ]
Es necesario parar las bases de datos operacionales para realizar el proceso
de captura de las modificaciones realizadas sobre los datos [ ] [ ]

- MOVIMIENTO Y CARGA

. Indicar el paquete software ofertado que incluye esta funcionalidad
y la plataforma o plataformas donde ha de instalarse

. Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]

. Explicar detalladamente los mecanismos de movimiento y carga de
los datos en las bases de datos destino del Data
Warehouse, enumerando las principales consideraciones
a tener en cuenta. En este sentido indicar si la transferencia se realiza
directamente o a través de un servidor intermedio, en este último caso detallar requerimientos físicos y lógicos de dicho servidor intermedio

. Transferencia de datos desde los Sistemas
Operacionales al Data Warehouse automática [ ] [ ]
. Control de las filas que sean rechazadas en el proceso de carga [ ] [ ]
Indicar qué ocurre con el proceso de carga

. Para el caso de los datos rechazados indicar
Si se especifica el motivo del rechazo [ ] [ ]
Almacenamiento físico de los datos rechazados
Fichero plano [ ] [ ]
Base de Datos propia [ ] [ ]
Base de Datos externa (especificar los gestores soportados en observaciones) [ ] [ ]

Otros (especificar) [ ] [ ]

Localización física de los datos rechazados
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]

Otros (especificar) [ ] [ ]

Explicar el mecanismo de tratamiento de los datos rechazados

. Indicar las alternativas para realizar la carga final del Data Warehouse

A través de la propia herramienta [ ] [ ]
A través de programas externos [ ] [ ]
Utilidades propias del gestor [ ] [ ]

Otras (especificar) [ ] [ ]

. Incorpora la herramienta algún proceso de comunicación automática de la disponibilidad
de los datos en el Data Warehouse a los usuarios finales [ ] [ ]

. En caso afirmativo indicar
El paquete software ofertado que incluye esta funcionalidad.

Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
El medio de comunicación automático utilizado
Correo electrónico [ ] [ ]
Otros (especificar) [ ] [ ]

En caso de poder utilizar correo electrónico, indicar los paquetes del
mercado perfectamente integrables con la herramienta propuesta

- CARGA INCREMENTAL

. Explicar detalladamente el mecanismo de carga incremental de los
datos en las bases de datos destino del Data Warehouse, especificando si se realiza en base a un chequeo de los
ficheros log de los sistemas operacionales, o en base al cruce de los fichero de carga, etc.

. Enumerar las principales diferencias respecto al proceso de carga
masiva y las consideraciones a tener en cuenta

- FUNCIONALIDADES ADICIONALES

. Análisis y control de la calidad
Incorpora funcionalidades para realizar un análisis y control de la calidad
de los datos [ ] [ ]
Especificar el paquete software ofertado que incluye esta funcionalidad y la
plataforma o plataformas donde ha de instalarse.

Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]

. Limpieza
Incorpora funcionalidades para llevar a cabo una limpieza de los datos [ ] [ ]
Especificar el paquete software ofertado que incluye esta funcionalidad y la
plataforma o plataformas donde ha de instalarse

Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
Explicar detalladamente los mecanismos de limpieza proporcionados, indicando
la plataforma donde se ejecutan estos

- GESTIÓN DEL METADATA

. Procedimientos de creación, mantenimiento y consulta
Indicar cómo se almacenan físicamente los metadatos generados
Fichero plano [ ] [ ]
Base de Datos propia [ ] [ ]
Base de Datos externa (especificar los gestores soportados en observaciones) [ ] [ ]

Otros (especificar) [ ] [ ]

Dónde se almacenan dichos metadatos
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central del Data Warehouse [ ] [ ]

Servidor central operacional [ ] [ ]
La creación y actualización de los metadatos es completamente automática [ ] [ ]
Es posible definir plantillas para los metadatos que se desean generar [ ] [ ]
Todos los datos y reglas de transformación que intervienen en la creación
y mantenimiento del Data Warehouse se almacenan como metadatos [ ] [ ]
Dispone de alguna herramienta específica para el mantenimiento y consulta
de los metadatos asociados al Data Warehouse, permitiendo la navegación dentro del directorio de metadatos [ ] [ ]
En caso afirmativo indicar
* El nombre del paquete software ofertado que incluye tal funcionalidad
* La plataformas o plataformas donde ha de instalarse
* Si requiere algún software adicional para completar tal funcionalidad
* Describir el mecanismo de integración con las otras herramientas
ofertadas

Es posible crear vistas adaptadas de los metadatos para diferentes proyectos [ ] [ ]
Utiliza un formato propio de metadatos [ ] [ ]
Indicar la información contenida en los metadatos
Descripción de los esquemas de datos origen y destino [ ] [ ]
Reglas de transformación y validación de datos [ ] [ ]
Variables de conversión [ ] [ ]
Mappings origen-destino [ ] [ ]
Opciones de recuperación de datos [ ] [ ]
Opciones de manejo de excepciones [ ] [ ]
Secuencia de acciones a realizar en las conversiones (queries, sorts y merges) [ ] [ ]
Especificaciones detalladas de las conversiones [ ] [ ]

Otras (especificar) [ ] [ ]

Indicar el grado de seguridad en el acceso a los metadatos.
No incorpora funciones de seguridad (utiliza la dada por el gestor) [ ] [ ]
Sí incorpora funciones de seguridad [ ] [ ]

Explicar en detalle

Dispone de alguna herramienta específica que permita el acceso vía
Web a los metadatos asociados al Data Warehouse [ ] [ ]
En caso afirmativo especificar qué navegadores son compatibles
Microsoft Internet Explorer [ ] [ ]

Netscape [ ] [ ]
En caso afirmativo indicar
El nombre del paquete software ofertado que incluye tal funcionalidad y dónde
ha de instalarse, detallando los requerimientos lógicos y físicos asociados

Requiere algún software adicional para completar tal funcionalidad, además
del propio navegador [ ] [ ]
En base a la pregunta anterior indicar las funcionalidades disponibles vía
Web y las principales diferencias respecto a un acceso cliente/servidor directo

. Integración de los metadatos
Es posible que los metadatos generados por dicha herramienta de extracción
puedan ser interpretados e integrados con los metadatos generados por las herramientas de acceso al Data Warehouse [ ] [ ]
En base a la pregunta anterior explicar detalladamente los mecanismos de integración
utilizados, enumerando las consideraciones a tener en cuenta

Dicha integración de los metadatos completamente automática [ ] [ ]
Posibilidad de la integración entre metadatos de negocio y técnicos
provenientes de múltiples fuentes [ ] [ ]
En caso afirmativo explicar detalladamente los mecanismos de integración
utilizados, así como el grado de automatización de dicha integración

. Control de versiones y documentación del metadato
Mantiene un histórico sobre los cambios realizados que permita realizar
un control de versiones [ ] [ ]
Está automatizada la generación de documentación asociada
con los metadatos [ ] [ ]
En caso afirmativo indicar si es posible imprimir dicha documentación.
No [ ] [ ]
Sí, pero sin presentación preliminar [ ] [ ]

Sí, con presentación preliminar [ ] [ ]

. Importación y exportación de metadatos
Permite capturar los metadatos desde fuentes externas [ ] [ ]
En caso afirmativo indicar las fuentes soportadas
Procesadores de texto [ ] [ ]
Amipro [ ] [ ]
Word [ ] [ ]
WordPerfect [ ] [ ]
Otros (especificar) [ ] [ ]

Bases de datos (especificar) [ ] [ ]

Hojas de cálculo [ ] [ ]
Lotus 123 [ ] [ ]
Excel [ ] [ ]

Otros (especificar) [ ] [ ]

Ficheros planos [ ] [ ]

Otras (especificar) [ ] [ ]

Posibilidad de exportar los metadatos [ ] [ ]
En caso afirmativo indicar los formatos soportados.
CDIF (formato estándar de intercambio de datos) [ ] [ ]

Otros (especificar) [ ] [ ]

ADMINISTRACIÓN

- GESTIÓN DE RECURSOS

. Administración centralizada
Posee una herramienta de administración y control centralizada
No [ ] [ ]
Sí, pero sin interfaz gráfica [ ] [ ]

Sí, con interfaz gráfica [ ] [ ]
Indicar el paquete software ofertado que incluye esta funcionalidad

Indicar las plataformas donde es necesario instalar el software de esta herramienta
de administración
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]

Servidor central [ ] [ ]
Requiere algún software adicional que complemente dicha funcionalidad [ ] [ ]
Indicar las funcionalidades que incorpora esta herramienta
Gestión de la seguridad [ ] [ ]
Monitorización de tareas en curso [ ] [ ]
Realización de pruebas de funcionalidad a volumen pequeño [ ] [ ]

Otras (especificar) [ ] [ ]

Puede ser utilizada esta herramienta de administración desde varios puestos
No [ ] [ ]
Sí, pero no simultáneamente [ ] [ ]

Sí, simultáneamente [ ] [ ]

. Estadísticas y logs de los procesos de extracción,
transformación, movimiento y carga
Elabora automáticamente estadísticas y logs de dichos procesos [ ] [ ]
En caso afirmativo, especificar la información incluida en dichos logs
y estadísticas
Total de registros leídos [ ] [ ]
Total de registros cargados [ ] [ ]
Tiempos de ejecución [ ] [ ]
Número de registros a los que se aplica una determinada regla de transformación [ ] [ ]
Número de registros que cumplen cada una de las condiciones de una regla
de transformación [ ] [ ]

Otras (especificar) [ ] [ ]

Indicar el almacenamiento físico de dicha información
Fichero plano [ ] [ ]
Base de Datos propia [ ] [ ]
Base de Datos externa (especificar los gestores soportados en observaciones) [ ] [ ]

Otros (especificar) [ ] [ ]

Almacen de dicha información
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]

Servidor central [ ] [ ]
Indicar los tiempos estimados de extracción y transformación, en
base a volúmenes de información

Indicar los tiempos estimados de carga, en base a volúmenes de información

- SEGURIDAD

. Indicar los niveles de seguridad soportados
Por usuario [ ] [ ]
Por grupo de usuario [ ] [ ]

Otros (especificar) [ ] [ ]

. En qué plataforma se gestiona la seguridad
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]

Servidor central [ ] [ ]
. Se realiza una identificación del usuario a la hora de acceder al sistema [ ] [ ]

. Almacenamiento físico de la password
Fichero plano [ ] [ ]
Base de datos propia [ ] [ ]
Base de datos externa (especificar los gestores soportados en observaciones) [ ] [ ]

Otros (especificar) [ ] [ ]

. Localización física de la password
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]

Otros (especificar) [ ] [ ]

. Explicar en detalle los mecanismos de seguridad que incorporan la
o las herramientas ofertadas

- PROCEDIMIENTO DE PLANIFICACIÓN Y MANTENIMIENTO
. Posible construir procedimientos que automaticen las tareas de planificación
y mantenimiento
No [ ] [ ]
Sí, pero no dispone de un interfaz gráfico que facilite la programación
dedichas tareas. [ ] [ ]

Sí, con un interfaz gráfico que facilite la programación
de dichas tareas [ ] [ ]
. En caso afirmativo, indicar las posibles bases de dicha planificación
Eventos [ ] [ ]
Ventanas de tiempo [ ] [ ]

Otras (especificar) [ ] [ ]

. Indicar el paquete software ofertado que incluye esta funcionalidad y la plataforma
o plataformas donde ha de instalarse

. Requiere algún software adicional que complemente dicha funcionalidad [ ] [ ]

ACLARACIONES GENERALES

REFERENCIAS

3.3.2.- CUESTIONARIO DE ANÁLISIS DE CALIDAD
Con carácter general y a fin de utilizar la información recopilada de cara a la contratación, es importante destacar que los datos recogidos en este cuestionario están dirigidos a obtener un resumen estructurado de la oferta y a demostrar la solvencia técnica o profesional de la empresa en aquellos casos en que no sea requerida la clasificación de la misma. Dicha información sólo servirá de base a la valoración cuando esté relacionada con lo expresado en la cláusula "Criterios de adjudicación del contrato", siendo, en el resto de los casos, de carácter meramente informativo.
Nota: (*) significa que hay que indicar "1" en caso afirmativo.
(**) significa que hay que repetir para cada sistema operativo ofertado.
Cuestión Respuesta Referencia a oferta (Página)
------------------------------------------ ---------- ----------

ENTORNO OPERATIVO

- REQUERIMIENTOS LÓGICOS

. Especificar para cada uno de las paquetes software ofertados la o las posibles plataformas (servidor central,
servidor intermedio y cliente) donde podrían instalarse, detallando los requerimientos físicos y
lógicos asociados a cada alternativa, junto con los procesos que se ejecutarían en cada una de las
posibles plataformas. [ ] [ ]

. Compatibilidad con Sistemas operativos. (Enumerar) [ ] [ ]

. Compatibilidad con software de red [ ] [ ]

. Necesidad de software adicional. (Enumerar) [ ] [ ]

- REQUERIMIENTOS FÍSICOS

. Memoria RAM Mínima requerida [ ] [ ]

. Memoria RAM Recomendada [ ] [ ]

. Espacio libre de disco Mínimo requerido [ ] [ ]

. Espacio libre de disco Recomendado [ ] [ ]

. Procesador mínimo requerido [ ] [ ]

. Porcesador recomendado [ ] [ ]

. Observaciones

CARACTERISTICAS GENERALES [ ] [ ]
- ORIGEN DE LOS DATOS A ANALIZAR
. Indicar si se analiza el total de los datos o bien sólo una muestra
significativa de los mismos
Todos los datos [ ] [ ]
Muestra
Ambos [ ] [ ]
. Observaciones

. Indicar y explicar detalladamente el mecanismo de obtención de los datos
a analizar.
Acceso directo a las fuentes de datos y análisis de la calidad de los
datos [ ] [ ]
Acceso directo a las fuentes de datos, extracción de los datos a analizar
y almacenamiento de los mismos para su análisis. [ ] [ ]
Análisis de la calidad de los datos que otras herramientas han extraído
de las fuentes de datos. [ ] [ ]
. Observaciones

. Explicación detallada del mecanismo seguido

. En el caso de acceder directamente a las fuentes de datos indicar
Si es posible analizar la calidad de los datos de varias fuentes simultáneamente [ ] [ ]
Observaciones

Las fuentes de datos a las que es posible acceder, especificando en los casos
en que sea necesario las últimas versiones certificadas
Ficheros planos [ ] [ ]
Bases de datos (especificar) [ ] [ ]

Otras fuentes de datos (especificar) [ ] [ ]

Observaciones

. En el caso de extraer los datos a analizar desde las fuentes soportadas y almacenarlos
para su análisis, indicar
Almacenamiento físico de los datos analizar
Fichero plano [ ] [ ]
Memoria [ ] [ ]
Base de Datos propia [ ] [ ]
Base de Datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]

Observaciones

Localización física de los datos
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Otros (especificar) [ ] [ ]

Observaciones

Técnicas aplicadas sobre los datos intermedios
Compresión [ ] [ ]
Encriptación [ ] [ ]
Otros (especificar) [ ] [ ]

En caso de aplicar compresión, indicar la relación de compresión

Observaciones

En base a las preguntas anteriores, explicar en detalle el consumo de recursos
asociado a este almacenamiento intermedio de los datos.

. En el caso de analizar los datos que otras herramientas han extraído
de las fuentes de datos, especificar de qué herramientas se trata. así como sus requerimientos lógicos
y físicos y la plataforma o plataformas donde han de instalarse.

- ELECCION Y TRATAMIENTO DE LAS MUESTRAS
. Describir el mecanismo de elección de la muestra, para asegurar la aleatoriedad
de la misma
Lo fija la herramienta sin intervención del usuario [ ] [ ]
El usuario selecciona un criterio de entre los posibles que proporciona la herramienta [ ] [ ]
El usuario puede confeccionar los criterios de elección de la muestra
a medida [ ] [ ]
Otros (especificar) [ ] [ ]

Describir detalladamente el mecanismo seguido

Observaciones

. Indicar el almacenamiento físico de la muestra de datos
Fichero plano [ ] [ ]
Memoria [ ] [ ]
Base de Datos propia [ ] [ ]
Base de Datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]

Observaciones

. Indicar la localización física de la muestra de datos
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Otros (especificar) [ ] [ ]

Observaciones

. Porcentaje que supone la muestra sobre el volumen total de datos

Observaciones

. Técnicas aplicadas sobre la muestra de datos
Compresión [ ] [ ]
Encriptación [ ] [ ]
Otras (especificar) [ ] [ ]

En caso de aplicar compresión, indicar la relación de compresión.............................
Observaciones

- MECANISMOS DE ANALISIS DE LA CALIDAD Y FUNCIONALIDADES
. Explicar detalladamente el mecanismo de análisis de calidad utilizado
y las funcionalidades disponibles

. Indicar los niveles de análisis de calidad disponibles
A nivel de campo [ ] [ ]
A nivel de grupo de campos [ ] [ ]
A nivel de registros [ ] [ ]
Otros (especificar) [ ] [ ]

Observaciones

. Indicar la plataforma o plataformas donde se ejecutan los procesos de análisis
de calidad de los datos
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central del Data Warehouse [ ] [ ]
Servidor central operacional [ ] [ ]
Otros (especificar) [ ] [ ]

Observaciones

. Indicar las métricas que proporciona la herramienta por defecto para
cuantificar la calidad de los datos
Validación de formatos [ ] [ ]
Ausencia de información en campos obligatorios [ ] [ ]
Cardinalidad de las variables [ ] [ ]
Comprobación de reglas de integridad: [ ] [ ]
Entre campos del mismo fichero [ ] [ ]
Entre campos de distintos ficheros [ ] [ ]
Rango de valores [ ] [ ]
Comprobación cruzada de valores contra una tabla de referencia [ ] [ ]
Validación de fechas [ ] [ ]
Rango de fechas [ ] [ ]
Otras (especificar): [ ] [ ]

Observaciones

. Posibilidad de utilizar "métricas" definidas por el usuario
para cuantificar la calidad de los datos
No [ ] [ ]
Sí, pero no posee un asistente que facilita la definición de dichas
métricas [ ] [ ]
Sí, y posee un asistente que facilita la definición de dichas métricas [ ] [ ]
Observaciones. Describir el mecanismo de definición de métricas
utilizado [ ] [ ]

- LIMITACIONES
. Existencia de alguna limitación interna de la herramienta en cuanto
al volumen máximo de información que se puede analizar
Sí , limitado por número de registros [ ] [ ]
Sí , limitado por volumen de información [ ] [ ]
No [ ] [ ]
En caso afirmativo, especificar el límite definido

Observaciones

- RECOMENDACIONES PRACTICAS
. Enumerar las principales recomendaciones prácticas para asegurar una
plena explotación de la potencialidad de los paquetes software ofertados.

. Enumerar y justificar brevemente los puntos fuertes tanto de la arquitectura
funcional propuesta como de las herramientas ofertadas.

FUNCIONALIDAD
- FACILIDAD DE USO
. Especificar los idiomas soportados en cada una de las siguientes áreas
A nivel de aplicación
Español [ ] [ ]
Inglés [ ] [ ]
Otros (especificar) [ ] [ ]

A nivel de ayuda on-line
Español [ ] [ ]
Inglés [ ] [ ]
Otros (especificar) [ ] [ ]

A nivel de manuales de ayuda
Español [ ] [ ]
Inglés [ ] [ ]
Otros (especificar) [ ] [ ]

A nivel de soporte
Español [ ] [ ]
Inglés [ ] [ ]
Otros (especificar) [ ] [ ]

. Incluye los caracteres exclusivos del español: Ñ, ñ y
vocales acentuadas [ ] [ ]
. Interfaz gráfico [ ] [ ]
. Ayuda on-line [ ] [ ]

. Presentación preliminar de la documentación antes
de la impresión [ ] [ ]

. Observaciones

. Especificar detalladamente los diferentes perfiles de usuario contemplados
para cada una de las herramientas ofertadas, así como la curva de aprendizaje (en horas)para cada uno de
ellos.

- ACCESO A LAS FUENTES DE DATOS

. Conocimiento de la estructura de las bases
de datos
Requerimiento de algún software adicional que permita conocer la estructura
de las bases de datos [ ] [ ]
En caso afirmativo indicar la plataforma o plataformas donde ha de instalarse
dicha herramienta

Explicar detalladamente el mecanismo que utiliza la herramienta para conocer
la estructura de las bases de datos

. Detección y captura de modificaciones en la estructura de
las bases de datos
Requiere algún software adicional que permita detectar y capturar las
modificaciones hechas en la estructura de las bases de datos [ ] [ ]
Explicar con detalle los mecanismos utilizados para la detección de cambios
en la estructura de las bases de datos.

Posibilidad de automatizar la detección de dichos cambios [ ] [ ]
Explicar detalladamente los mecanismos utilizados para la captura de dichos cambios

Posibilidad de automatizar la captura de los cambios realizados en la estructura
de las bases de datos [ ] [ ]
Es necesario parar las bases de datos para realizar el proceso de captura de
cambios [ ] [ ]

. Acceso a las bases de datos
Requiere algún software adicional que permita el acceso a las bases de
datos [ ] [ ]
Accede directamente a la base de datos [ ] [ ]
En caso afirmativo describir el mecanismo de acceso seguido

En caso de no acceder directamente a la base de datos indicar cómo se
obtienen los ficheros de datos
Mediante una utilidad de la propia herramienta [ ] [ ]
A través de una utilidad del gestor [ ] [ ]
Mediante un desarrollo a medida. [ ] [ ]
Otros (especificar) [ ] [ ]

- PROCEDIMIENTOS DE ANALISIS DE CALIDAD

. Indicar el paquete software ofertado que incluye esta funcionalidad
y la plataforma o plataformas donde ha de instalarse

. Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]

. Es posible automatizar completamente los procesos de análisis
de calidad [ ] [ ]

. Es posible mantener un histórico sobre evolución temporal
de la calidad de los datos [ ] [ ]

. Formatos soportados para la exportación de los resultados
obtenidos
Hojas de cálculo [ ] [ ]
Lotus 123 [ ] [ ]
Excel [ ] [ ]
Otras (especificar) [ ] [ ]

Procesadores de texto [ ] [ ]
Amipro [ ] [ ]
WordPerfect [ ] [ ]
Word [ ] [ ]
Otros (especificar) [ ] [ ]

Herramientas gráficas [ ] [ ]
FreeLance [ ] [ ]
PowerPoint [ ] [ ]
Otros (especificar) [ ] [ ]

Bases de datos (especificar) [ ] [ ]

Ficheros Planos [ ] [ ]

Otros (especificar) [ ] [ ]

. Adjuntar como anexo un ejemplo, lo más completo posible,
que contenga la información sobre un análisis
de calidad, efectuado con la herramienta propuesta

- GENERACION DE DOCUMENTACION

. Posee un Generador de Informes que permita la generación
de la documentación sobre los resultados
obtenidos
No [ ] [ ]
Sí, pero bajo la petición del usuario [ ] [ ]

Sí, automáticamente [ ] [ ]

. Indicar el paquete software ofertado que incluye esta funcionalidad
y la plataforma o plataformas donde ha de instalarse

. Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]

. Describir la información incluida en dicha documentación
Origen de los datos [ ] [ ]
Posibles correspondencias entre datos [ ] [ ]
Métricas aplicadas [ ] [ ]

Otras (especificar) [ ] [ ]

. Soporta el versionado de la documentación generada [ ] [ ]

. Se proporciona algún software que facilite el mantenimiento
y versionado de la documentación [ ] [ ]

- CARACTERISTICAS DEL ENTORNO FUNCIONAL

. Especificar el software mínimo que es necesario tener instalado
en las diferentes plataformas

. Son necesarios otros requisitos software adicionales [ ] [ ]

- FUNCIONALIDADES ADICIONALES

. Limpieza de datos
Incorpora alguna funcionalidad que permita la limpieza de datos [ ] [ ]
Especificar el paquete software ofertado que incluye esta funcionalidad y la
plataforma o plataformas donde ha de instalarse

Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
Explicar detalladamente los mecanismos de limpieza proporcionados, indicando
la plataforma donde se ejecutan estos

. Otras funcionalidades
Incorpora otras funcionalidades (enumerarlas) [ ] [ ]

Especificar el paquete o paquetes software ofertados que incluyen estas funcionalidades
y la plataforma o plataformas donde ha de instalarse

Requiere algún software adicional que complemente estas funcionalidades [ ] [ ]
Explicar detalladamente los mecanismos asociados a dichas funcionalidades, indicando
la plataforma donde se ejecutan estos

- GESTION DE LOS METADATOS DE CALIDAD

. Se generan metadatos sobre la calidad de los datos [ ] [ ]

. Procedimientos de creación, mantenimiento y consulta
Indicar cómo se almacenan físicamente los metadatos generados.
Fichero plano [ ] [ ]
Base de Datos propia [ ] [ ]
Base de Datos externa (especificar los gestores soportados en observaciones) [ ] [ ]

Otros (especificar) [ ] [ ]

Dónde se almacenan dichos metadatos
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]

Servidor central [ ] [ ]
La creación y actualización de los metadatos es completamente automática [ ] [ ]
En caso negativo indicar qué metadatos se alimentan automáticamente
y cuáles no, especificando en este último caso el mecanismo seguido

Es posible definir plantillas para los metadatos que se desean generar [ ] [ ]
Dispone de alguna herramienta específica para el mantenimiento y consulta
de los metadatos de calidad asociados al Data Warehouse, así como para la navegación dentro del directorio
de metadatos [ ] [ ]
El nombre del paquete software ofertado que incluye tal funcionalidad
La plataformas o plataformas donde ha de instalarse
Requiere algún software adicional para completar tal funcionalidad [ ] [ ]
Es posible crear vistas adaptadas de los metadatos para diferentes proyectos [ ] [ ]
Utiliza un formato propio de metadatos [ ] [ ]
Indicar la información contenida en los metadatos
Descripción de los esquemas de datos origen [ ] [ ]
Métricas definidas por defecto [ ] [ ]
Métricas definidas por el usuario [ ] [ ]

Otras (especificar) [ ] [ ]

Indicar el grado de seguridad en el acceso a los metadatos
No incorpora funciones de seguridad [ ] [ ]

Sí incorpora funciones de seguridad [ ] [ ]
Dispone de alguna herramienta específica que permita el acceso vía
Web a los metadatos de calidad [ ] [ ]
especificar qué navegadores son compatibles

El nombre del paquete software ofertado que incluye tal funcionalidad y dónde
ha de instalarse, detallando los requerimientos lógicos y físicos asociados

Requiere algún software adicional para completar tal funcionalidad, además
del propio navegador [ ] [ ]
En base a la pregunta anterior indicar las funcionalidades disponibles vía
Web y las principales diferencias respecto a un acceso cliente/servidor directo

. Integración de los metadatos de calidad con otros metadatos
Es posible que los metadatos generados por dicha herramienta de análisis
puedan ser interpretados e integrados con los generados por otras herramientas, tanto de usuario final como de
extracción, movimiento y carga [ ] [ ]
En caso afirmativo especificar las herramientas de compatibles, indicando si
son o no del mismo fabricante

En base a la pregunta anterior explicar detalladamente los mecanismos de integración
utilizados, enumerando las consideraciones a tener en cuenta

Dicha integración de los metadatos completamente automática [ ] [ ]

. Control de versiones y documentación del metadato de calidad
Se mantiene un histórico sobre los cambios realizados en los metadatos
de calidad que permita realizar un control de versiones [ ] [ ]
si existe algún límite en el número de versiones [ ] [ ]
Está automatizada la generación de documentación asociada
con los metadatos de calidad [ ] [ ]
Posibilidad de imprimir dicha documentación
No [ ] [ ]
Sí, pero sin presentación preliminar [ ] [ ]
Sí, con presentación preliminar [ ] [ ]
. Importación y exportación de los metadatos de calidad
Permite importar los metadatos de calidad desde fuentes externas [ ] [ ]
Indicar las fuentes soportadas
Procesadores de texto [ ] [ ]
Amipro [ ] [ ]
Word [ ] [ ]
WordPerfect [ ] [ ]
Otros (especificar) [ ] [ ]

Bases de datos (especificar) [ ] [ ]

Hojas de cálculo [ ] [ ]
Lotus 123 [ ] [ ]
Excel [ ] [ ]
Otros (especificar) [ ] [ ]

Ficheros planos [ ] [ ]
Otras (especificar) [ ] [ ]

Consideraciones a tener en cuenta

Posibilidad de exportar los metadatos de calidad [ ] [ ]
Formatos soportados
CDIF (formato estándar de intercambio de datos) [ ] [ ]
Otros (especificar) [ ] [ ]

- PLANIFICACION DEL ANALISIS DE CALIDAD
. Posibilidad de construir procedimientos que automaticen las tareas de análisis
de la calidad de los datos
No [ ] [ ]
Sí, pero no dispone de un interfaz gráfico que facilite la programación
de dichas tareas. [ ] [ ]
Sí, con un interfaz gráfico que facilite la programación
de dichas tareas [ ] [ ]
. Indicar las posibles bases de dicha planificación
Eventos [ ] [ ]
Ventanas de tiempo [ ] [ ]
Otras (especificar) [ ] [ ]

. Indicar el paquete software ofertado que incluye esta funcionalidad y la plataforma
o plataformas donde ha de instalarse

. Requiere algún software adicional que complemente dicha funcionalidad [ ] [ ]
ACLARACIONES GENERALES

REFERENCIAS
Resumen de las principales instalaciones donde se encuentran instaladas las herramientas
propuestas, con una breve descripción del entorno tecnológico y de los volúmenes de información
manejados

3.3.3.- CUESTIONARIO DE HERRAMIENTAS DE USUARIO FINAL: OLAP, EIS, REPORTING
Con carácter general y a fin de utilizar la información recopilada de cara a la contratación, es importante destacar que los datos recogidos en este cuestionario están dirigidos a obtener un resumen estructurado de la oferta y a demostrar la solvencia técnica o profesional de la empresa en aquellos casos en que no sea requerida la clasificación de la misma. Dicha información sólo servirá de base a la valoración cuando esté relacionada con lo expresado en la cláusula "Criterios de adjudicación del contrato", siendo, en el resto de los casos, de carácter meramente informativo.
Nota: (*) significa que hay que indicar "1" en caso afirmativo.
(**) significa que hay que repetir para cada sistema operativo ofertado.
Cuestión Respuesta Referencia a oferta (Página)
------------------------------------------ ---------- ----------

ENTORNO OPERATIVO

- REQUERIMIENTOS LÓGICOS
Es compatible con los sistemas operativos de las plataformas
[ ]
[ ]
Es compatible con otros sistemas operativos (enumerar)
[ ]
[ ]

Es compatible con el software de red del entorno
[ ]
[ ]
Necesidad software adicional (enumerar)
[ ]
[ ]

- REQUERIMIENTOS FÍSICOS

. Memoria RAM Mínima requerida [ ] [ ]

. Memoria RAM Recomendada [ ] [ ]

. Espacio libre de disco Mínimo requerido [ ] [ ]

. Espacio libre de disco Recomendado [ ] [ ]

. Procesador mínimo requerido [ ] [ ]

. Porcesador recomendado [ ] [ ]

. Observaciones

CARACTERÍSTICAS GENERALES
- INTERFACES DE USUARIO FINAL APORTADAS Y SOPORTADAS

. Especificar los diferentes interfaces de usuario final que aportan
las herramientas ofertadas, indicando el perfil de usuario adecuado a cada uno de ellos
Aplicaciones EIS [ ] [ ]
Entornos OLAP [ ] [ ]
Reporting [ ] [ ]
Otros (especificar) [ ] [ ]

. Especificar los diferentes interfaces de usuario final que se soportan,
indicando el perfil de usuario adecuado a cada uno de ellos
Aplicaciones EIS [ ] [ ]
Entornos OLAP [ ] [ ]
Reporting [ ] [ ]
Lotus 123 [ ] [ ]
Excel [ ] [ ]
Otros (especificar) [ ] [ ]

- DESCRIPCIÓN DEL ACCESO

. Especificar el tipo de acceso efectuado
ROLAP [ ] [ ]
MOLAP [ ] [ ]
Observaciones

. Indicar las arquitecturas cliente/servidor soportadas
2 niveles (acceso directo a la base de datos desde el puesto cliente) [ ] [ ]
3 niveles (acceso a la base de datos a través de un servidor intermedio) [ ] [ ]
4 niveles (acceso vía Web) [ ] [ ]
Observaciones

. Indicar los gestores de bases de datos que soporta, así como
las últimas versiones certificadas para cada uno de ellos
Adabas....................... [ ] [ ]
DB2....................... [ ] [ ]
Informix....................... [ ] [ ]
Oracle....................... [ ] [ ]
Redbrick....................... [ ] [ ]
SQL Server....................... [ ] [ ]
Sybase Adaptive Server Enterprise....................... [ ] [ ]
Sybase Adaptive Server IQ ....................... [ ] [ ]
Teradata....................... [ ] [ ]
Otros (especificar)....................... [ ] [ ]

. Almacenamiento físico de los datos recuperados
Fichero plano [ ] [ ]
Memoria [ ] [ ]
Base de datos propia [ ] [ ]
Base de datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]

. Dónde se almacena la información recuperada
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Otros (especificar) [ ] [ ]

. Indicar la visión lógica de los datos recuperados.
Relacional [ ] [ ]
Multidimensional (cubos) [ ] [ ]

. En caso de almacenar la información recuperada de manera
multidimensional indicar cómo y cuándo se genera el cubo
En el momento de la consulta [ ] [ ]
En un proceso diferido [ ] [ ]
Otros (especificar) [ ] [ ]

Para cualquiera de las respuestas describir en detalle el mecanismo seguido

. En caso de almacenamiento multidimensional explicar qué ocurre
si los datos necesarios para dar respuesta a una consulta no se encuentran en el cubo
Genera en el momento un nuevo acceso a la base de datos del Data [ ] [ ]
Warehouse [ ] [ ]
Se indica que la consulta en cuestión no puede ser ejecutada [ ] [ ]
Otros (especificar) [ ] [ ]

Para cualquiera de las respuestas describir en detalle el mecanismo seguido

- TÉCNICAS DE EXPLORACIÓN DE DATOS

. Técnicas de exploración de datos soportadas
Drill down [ ] [ ]
Drill up [ ] [ ]
Drill across [ ] [ ]
Otras (especificar) [ ] [ ]

. Para las técnicas de navegación soportadas indicar
en qué casos se vuelve a lanzar una query contra la base de datos con el fin de obtener los detalles solicitados,
especificando si se hace de forma desatendida o no

. En el caso de utilizar alguna de las técnicas de exploración
de datos, se mantiene la visualización de los datos asociados a cada uno de los pasos seguidos, de manera
que siempre tendremos los datos anteriores para poder iniciar otro camino de navegación. [ ] [ ]

Observaciones

. Es posible navegar por más de una ocurrencia
del mismo atributo simultáneamente [ ] [ ]
Especificar si existe algún límite en el número de ocurrencias
desde las que iniciar una navegación

Observaciones

- FUNCIONALIDADES. POTENCIA DE CÁLCULO

. Principales funcionalidades proporcionadas
Rankings
[ ]
[ ]
Tendencias
[ ]
[ ]
Comparativas
[ ]
[ ]

Otras (especificar)
[ ]
[ ]

Descripción de las funcionalidades

. Enumerar las funciones estadísticas disponibles

. Funcionalidades de cálculo dinámico soportadas
Definición de múltiples criterios de ordenación dentro de
un informe
[ ]
[ ]
Redimensionamiento automático de la anchura de las columnas
[ ]
[ ]
Cálculo automático de totales y estadísticas
[ ]
[ ]

Otras (especificar)
[ ]
[ ]

. Posibilidad de utilizar fechas dinámicas,
tomando como base la fecha actual
[ ]
[ ]

(especificar)

. Posible realizar cálculos dinámicos
entre las columnas o incluso celdas que componen un informe ya calculado, de forma semejante a como lo hace una hoja de cálculo, sin necesidad de lanzar una nueva consulta
No
[ ]
[ ]
Sí, pero es necesario definir una nueva métrica
[ ]
[ ]

Sí, sin necesidad de definir nuevas métricas
[ ]
[ ]

- VISIÓN DEL MODELO DE NEGOCIO

. Posee un interfaz gráfica que muestre el modelo de negocio
utilizado, es decir, las dimensiones de forma jerarquizada
y los atributos que las componen
No
[ ]
[ ]
Sí, pero sin la posibilidad de limitar la expansión de los atributos
hasta el nivel deseado.
[ ]
[ ]

Sí, con la posibilidad de limitar la expansión.
[ ]
[ ]

. En caso de poder limitar esta expansión especificar los posibles
criterios a seguir, y describir el mecanismo de
limitación utilizado
Por usuario
[ ]
[ ]
Por grupo de usuario
[ ]
[ ]

Otros (especificar)
[ ]
[ ]

. Posible en dicho interfaz gráfico visualizar
los valores de los atributos que forman parte del
modelo de negocio
[ ]
[ ]
afirmativo explicar la técnica utilizada para obtener dichos valores

- LIMITACIONES

. Limitación interna de la herramienta
en cuanto al volumen máximo de información
que se puede recuperar
Sí , limitado por número de registros
[ ]
[ ]
Sí , limitado por volumen de información
[ ]
[ ]
No
[ ]
[ ]

Especificar el límite definido

. Limitación en cuanto al número
de dimensiones o atributos a incluir dentro del
modelo de datos de negocio
[ ]
[ ]

(especificar)

. Especificar detalladamente las principales limitaciones de los paquetes
software ofertados

- RECOMENDACIONES PRÁCTICAS

. Indicar el modelo de datos recomendado (en el servidor de datos)
Copo de nieve
[ ]
[ ]
Estrella
[ ]
[ ]
Relacional
[ ]
[ ]

Otros (especificar)
[ ]
[ ]

. Especificar detalladamente las principales recomendaciones prácticas
para asegurar una plena explotación de la
potencialidad de las herramientas ofertadas

. Enumerar y justificar brevemente los puntos fuertes tanto de la
arquitectura funcional propuesta como de las herramientas
ofertadas

3.3.3.- CUESTIONARIO DE HERRAMIENTAS DE USUARIO FINAL: OLAP, EIS, REPORTING
Con carácter general y a fin de utilizar la información recopilada de cara a la contratación, es importante destacar que los datos recogidos en este cuestionario están dirigidos a obtener un resumen estructurado de la oferta y a demostrar la solvencia técnica o profesional de la empresa en aquellos casos en que no sea requerida la clasificación de la misma. Dicha información sólo servirá de base a la valoración cuando esté relacionada con lo expresado en la cláusula "Criterios de adjudicación del contrato", siendo, en el resto de los casos, de carácter meramente informativo.
Nota: (*) significa que hay que indicar "1" en caso afirmativo.
(**) significa que hay que repetir para cada sistema operativo ofertado.
Cuestión Respuesta Referencia a oferta (Página)
------------------------------------------ ---------- ----------

ENTORNO OPERATIVO

- REQUERIMIENTOS LÓGICOS
Es compatible con los sistemas operativos de las plataformas
[ ]
[ ]
Es compatible con otros sistemas operativos (enumerar)
[ ]
[ ]

Es compatible con el software de red del entorno
[ ]
[ ]
Necesidad software adicional (enumerar)
[ ]
[ ]

- REQUERIMIENTOS FÍSICOS

. Memoria RAM Mínima requerida [ ] [ ]

. Memoria RAM Recomendada [ ] [ ]

. Espacio libre de disco Mínimo requerido [ ] [ ]

. Espacio libre de disco Recomendado [ ] [ ]

. Procesador mínimo requerido [ ] [ ]

. Porcesador recomendado [ ] [ ]

. Observaciones

CARACTERÍSTICAS GENERALES
- INTERFACES DE USUARIO FINAL APORTADAS Y SOPORTADAS

. Especificar los diferentes interfaces de usuario final que aportan
las herramientas ofertadas, indicando el perfil de usuario adecuado a cada uno de ellos
Aplicaciones EIS [ ] [ ]
Entornos OLAP [ ] [ ]
Reporting [ ] [ ]
Otros (especificar) [ ] [ ]

. Especificar los diferentes interfaces de usuario final que se soportan,
indicando el perfil de usuario adecuado a cada uno de ellos
Aplicaciones EIS [ ] [ ]
Entornos OLAP [ ] [ ]
Reporting [ ] [ ]
Lotus 123 [ ] [ ]
Excel [ ] [ ]
Otros (especificar) [ ] [ ]

- DESCRIPCIÓN DEL ACCESO

. Especificar el tipo de acceso efectuado
ROLAP [ ] [ ]
MOLAP [ ] [ ]
Observaciones

. Indicar las arquitecturas cliente/servidor soportadas
2 niveles (acceso directo a la base de datos desde el puesto cliente) [ ] [ ]
3 niveles (acceso a la base de datos a través de un servidor intermedio) [ ] [ ]
4 niveles (acceso vía Web) [ ] [ ]
Observaciones

. Indicar los gestores de bases de datos que soporta, así como
las últimas versiones certificadas para cada uno de ellos
Adabas....................... [ ] [ ]
DB2....................... [ ] [ ]
Informix....................... [ ] [ ]
Oracle....................... [ ] [ ]
Redbrick....................... [ ] [ ]
SQL Server....................... [ ] [ ]
Sybase Adaptive Server Enterprise....................... [ ] [ ]
Sybase Adaptive Server IQ ....................... [ ] [ ]
Teradata....................... [ ] [ ]
Otros (especificar)....................... [ ] [ ]

. Almacenamiento físico de los datos recuperados
Fichero plano [ ] [ ]
Memoria [ ] [ ]
Base de datos propia [ ] [ ]
Base de datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]

. Dónde se almacena la información recuperada
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Otros (especificar) [ ] [ ]

. Indicar la visión lógica de los datos recuperados.
Relacional [ ] [ ]
Multidimensional (cubos) [ ] [ ]

. En caso de almacenar la información recuperada de manera
multidimensional indicar cómo y cuándo se genera el cubo
En el momento de la consulta [ ] [ ]
En un proceso diferido [ ] [ ]
Otros (especificar) [ ] [ ]

Para cualquiera de las respuestas describir en detalle el mecanismo seguido

. En caso de almacenamiento multidimensional explicar qué ocurre
si los datos necesarios para dar respuesta a una consulta no se encuentran en el cubo
Genera en el momento un nuevo acceso a la base de datos del Data [ ] [ ]
Warehouse [ ] [ ]
Se indica que la consulta en cuestión no puede ser ejecutada [ ] [ ]
Otros (especificar) [ ] [ ]

Para cualquiera de las respuestas describir en detalle el mecanismo seguido

- TÉCNICAS DE EXPLORACIÓN DE DATOS

. Técnicas de exploración de datos soportadas
Drill down [ ] [ ]
Drill up [ ] [ ]
Drill across [ ] [ ]
Otras (especificar) [ ] [ ]

. Para las técnicas de navegación soportadas indicar
en qué casos se vuelve a lanzar una query contra la base de datos con el fin de obtener los detalles solicitados,
especificando si se hace de forma desatendida o no

. En el caso de utilizar alguna de las técnicas de exploración
de datos, se mantiene la visualización de los datos asociados a cada uno de los pasos seguidos, de manera
que siempre tendremos los datos anteriores para poder iniciar otro camino de navegación. [ ] [ ]

Observaciones

. Es posible navegar por más de una ocurrencia
del mismo atributo simultáneamente [ ] [ ]
Especificar si existe algún límite en el número de ocurrencias
desde las que iniciar una navegación

Observaciones

- FUNCIONALIDADES. POTENCIA DE CÁLCULO

. Principales funcionalidades proporcionadas
Rankings
[ ]
[ ]
Tendencias
[ ]
[ ]
Comparativas
[ ]
[ ]

Otras (especificar)
[ ]
[ ]

Descripción de las funcionalidades

. Enumerar las funciones estadísticas disponibles

. Funcionalidades de cálculo dinámico soportadas
Definición de múltiples criterios de ordenación dentro de
un informe
[ ]
[ ]
Redimensionamiento automático de la anchura de las columnas
[ ]
[ ]
Cálculo automático de totales y estadísticas
[ ]
[ ]

Otras (especificar)
[ ]
[ ]

. Posibilidad de utilizar fechas dinámicas,
tomando como base la fecha actual
[ ]
[ ]

(especificar)

. Posible realizar cálculos dinámicos
entre las columnas o incluso celdas que componen un informe ya calculado, de forma semejante a como lo hace una hoja de cálculo, sin necesidad de lanzar una nueva consulta
No
[ ]
[ ]
Sí, pero es necesario definir una nueva métrica
[ ]
[ ]

Sí, sin necesidad de definir nuevas métricas
[ ]
[ ]

- VISIÓN DEL MODELO DE NEGOCIO

. Posee un interfaz gráfica que muestre el modelo de negocio
utilizado, es decir, las dimensiones de forma jerarquizada
y los atributos que las componen
No
[ ]
[ ]
Sí, pero sin la posibilidad de limitar la expansión de los atributos
hasta el nivel deseado.
[ ]
[ ]

Sí, con la posibilidad de limitar la expansión.
[ ]
[ ]

. En caso de poder limitar esta expansión especificar los posibles
criterios a seguir, y describir el mecanismo de
limitación utilizado
Por usuario
[ ]
[ ]
Por grupo de usuario
[ ]
[ ]

Otros (especificar)
[ ]
[ ]

. Posible en dicho interfaz gráfico visualizar
los valores de los atributos que forman parte del
modelo de negocio
[ ]
[ ]
afirmativo explicar la técnica utilizada para obtener dichos valores

- LIMITACIONES

. Limitación interna de la herramienta
en cuanto al volumen máximo de información
que se puede recuperar
Sí , limitado por número de registros
[ ]
[ ]
Sí , limitado por volumen de información
[ ]
[ ]
No
[ ]
[ ]

Especificar el límite definido

. Limitación en cuanto al número
de dimensiones o atributos a incluir dentro del
modelo de datos de negocio
[ ]
[ ]

(especificar)

. Especificar detalladamente las principales limitaciones de los paquetes
software ofertados

- RECOMENDACIONES PRÁCTICAS

. Indicar el modelo de datos recomendado (en el servidor de datos)
Copo de nieve
[ ]
[ ]
Estrella
[ ]
[ ]
Relacional
[ ]
[ ]

Otros (especificar)
[ ]
[ ]

. Especificar detalladamente las principales recomendaciones prácticas
para asegurar una plena explotación de la
potencialidad de las herramientas ofertadas

. Enumerar y justificar brevemente los puntos fuertes tanto de la
arquitectura funcional propuesta como de las herramientas
ofertadas

3.3.3.- CUESTIONARIO DE HERRAMIENTAS DE USUARIO FINAL: OLAP, EIS, REPORTING (cont.)
Con carácter general y a fin de utilizar la información recopilada de cara a la contratación, es importante destacar que los datos recogidos en este cuestionario están dirigidos a obtener un resumen estructurado de la oferta y a demostrar la solvencia técnica o profesional de la empresa en aquellos casos en que no sea requerida la clasificación de la misma. Dicha información sólo servirá de base a la valoración cuando esté relacionada con lo expresado en la cláusula "Criterios de adjudicación del contrato", siendo, en el resto de los casos, de carácter meramente informativo.
Nota: (*) significa que hay que indicar "1" en caso afirmativo.
(**) significa que hay que repetir para cada sistema operativo ofertado.
Cuestión Respuesta Referencia a oferta (Página)
------------------------------------------ ---------- ----------

ADMINISTRACIÓN

- GESTIÓN DE RECURSOS

. Administración centralizada
Posee una herramienta de administración centralizada

No
[ ]
[ ]

Sí, pero sin interfaz gráfica
[ ]
[ ]
Sí, con interfaz gráfica
[ ]
[ ]
Indicar y describir las funcionalidades que incorpora esta herramienta
Gestión de la seguridad
[ ]
[ ]

Monitorización de tareas en curso
[ ]
[ ]

Definición de perfiles de usuario
[ ]
[ ]

Asignación y limitación de recursos
[ ]
[ ]

Otras (especificar)
[ ]
[ ]

Observaciones. Describir las funcionalidades soportadas

Posibilidad de utilización de esta herramienta de administración
desde varios puestos

No
[ ]
[ ]
Sí, pero no simultáneamente
[ ]
[ ]
Sí, simultáneamente
[ ]
[ ]
Indicar el paquete software ofertado que incluye esta funcionalidad

Indicar las plataformas donde es necesario instalar el software de esta herramienta
de administración
Puesto cliente
[ ]
[ ]

Servidor intermedio
[ ]
[ ]

Servidor central
[ ]
[ ]
Requierimiento de algún software adicional que complemente dicha funcionalidad
[ ]
[ ]

Observaciones (especificar
en caso afirmativo)

Observaciones

. Tratamiento de los datos recuperados
Técnicas aplicadas sobre los datos recuperados
Compresión
[ ]
[ ]
Encriptación
[ ]
[ ]

Otros (especificar)
[ ]
[ ]

En caso de aplicar compresión, indicar la relación de compresión

Salva el resultado de la consulta
No
[ ]
[ ]

Sí, bajo petición del usuario
[ ]
[ ]

Sí, automáticamente
[ ]
[ ]
En caso afirmativo especificar los formatos soportados
HTML
[ ]
[ ]

Dbase
[ ]
[ ]
RTF
[ ]
[ ]

Lotus 123
[ ]
[ ]

Excel
[ ]
[ ]

Amipro
[ ]
[ ]
WordPerfect
[ ]
[ ]

Word
[ ]
[ ]

Tablas del gestor
[ ]
[ ]
Otros (especificar)
[ ]
[ ]

Utilización tablas temporales en la resolución de las consultas
efectuadas
[ ]
[ ]
Observaciones. Indicar el volumen de almacenamiento recomendado para dichas tablas,
en función del volumen de datos

En caso afirmativo especificar la posible localización física de
dichas tablas
Puesto cliente (base de datos auxiliar)
[ ]
[ ]

Servidor intermedio (base de datos auxiliar)
[ ]
[ ]

Servidor central (base de datos del Data Warehouse)
[ ]
[ ]

Observaciones

. Estadísticas de ejecución
Realización una elaboración automática de estadísticas
sobre la utilización de recursos
[ ]
[ ]
Información incluida en dichas estadísticas
Tipos de consultas más frecuentes
[ ]
[ ]
Tiempos de ejecución
[ ]
[ ]

Número de accesos realizados por usuario
[ ]
[ ]
Volúmenes recuperados de información
[ ]
[ ]

Estadísticas asociadas a threads de diferentes prioridades
[ ]
[ ]

Otras estadísticas (especificar)
[ ]
[ ]

Almacenamiento físico de dicha información estadística
Fichero plano
[ ]
[ ]

Base de Datos propia
[ ]
[ ]

Base de Datos externa (especificar los gestores soportados en observaciones)
[ ]
[ ]

Otros (especificar)
[ ]
[ ]

Dónde se almacena la información estadística
Puesto cliente
[ ]
[ ]
Servidor intermedio
[ ]
[ ]
Servidor central
[ ]
[ ]

Observaciones

. Simulación, estimaciones de consumo y
recomendaciones sobre el diseño del Data Warehouse
Dispone de alguna herramienta de simulación que permita estimar el consumo
de recursos y el tiempo de respuesta de las consultas
[ ]
[ ]
Permite estimar el consumo de recursos y tiempo de respuesta de una consulta
antes de su ejecución

No
[ ]
[ ]
Sí, en base a ejecuciones anteriores (especificar qué ocurre si
es la primera vez que se ejecuta dicha consulta
[ ]
[ ]

Sí, en base a otros criterios (especificar)
[ ]
[ ]

Dispone de alguna herramienta que en base a estadísticas de ejecución
haga recomendaciones sobre el diseño del Data Warehouse
No
[ ]
[ ]

Sí, con la ayuda del usuario final
[ ]
[ ]

Sí, hace las recomendaciones automáticamente, sin necesitar
al usuario final
[ ]
[ ]
En caso afirmativo, explicar en qué consisten dichas recomendaciones

Observaciones

. Asignación dinámica de recursos
Es posible definir threads de consulta con diferentes prioridades de acceso para
queries simultáneas
[ ]
[ ]
Indicar el abanico de prioridades asignadas a dichos threads

Los posibles criterios de definición de dichos threads
Por tiempo estimado de ejecución de la consulta
[ ]
[ ]
Por perfil de usuario
[ ]
[ ]
Por grupo de usuario
[ ]
[ ]
Por consulta específica
[ ]
[ ]

Por volumen estimado de datos a recuperar
[ ]
[ ]

Ventana de ejecución (temporal)
[ ]
[ ]

Otras (especificar)
[ ]
[ ]

Observaciones

. Limitación del consumo de recursos en las consultas
Posibilidad de la herramienta de limitar el consumo de recursos

No
[ ]
[ ]
Sí. La herramienta lo hace automáticamente, sin pedir confirmación
al usuario y sin tener en cuenta el perfil de usuario
[ ]
[ ]
Sí. Se pide confirmación al usuario siempre para lanzar o no la
consulta independientemente del perfil del mismo
[ ]
[ ]

Sí. Para ciertos perfiles se limita automáticamente
y para otros no se limita
[ ]
[ ]
Sí. Para ciertos perfiles se limita automáticamente y para otros
se pide confirmación al usuario para lanzar o no la consulta
[ ]
[ ]
Permite evitar la ejecución de una consulta si el tiempo estimado de ejecución
es superior a un umbral definido

No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]

Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Permite evitar la ejecución de una consulta si el número estimado
de filas a devolver es superior a un umbral definido

No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]

Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Permite evitar la ejecución de una consulta si el número estimado
de filas a acceder es superior a un umbral definido

No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]

Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Permite evitar la ejecución de una consulta si el volumen estimado de
datos a devolver es superior a un umbral definido

No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]

Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Permite evitar la ejecución de una consulta si el volumen estimado de
datos a acceder es superior a un umbral definido

No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]

Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Cancela automáticamente la ejecución de una consulta cuando el
tiempo de respuesta sobrepasa un umbral definido
No
[ ]
[ ]
Sí, totalmente (no devuelve nada) independientemente del perfil de usuario
[ ]
[ ]
Sí, totalmente (no devuelve nada) para ciertos perfiles de usuario, y
para otros no la cancela
[ ]
[ ]
Sí, pero devuelve al menos la información recuperada hasta ese
momento,independientemente del perfil de usuario
[ ]
[ ]
Cancela automáticamente la ejecución de una consulta cuando el
número de filas devueltas sobrepasa un umbral definido
No
[ ]
[ ]
Sí, totalmente (no devuelve nada) independientemente del perfil de usuario
[ ]
[ ]
Sí, totalmente (no devuelve nada) para ciertos perfiles de usuario, y
para otros no la cancela
[ ]
[ ]
Sí, pero devuelve al menos la información recuperada hasta ese
momento,independientemente del perfil de usuario
[ ]
[ ]
Cancela automáticamente la ejecución de una consulta cuando el
número de filas accedido sobrepasa un umbral definido
No
[ ]
[ ]
Sí, totalmente (no devuelve nada) independientemente del perfil de usuario
[ ]
[ ]
Sí, totalmente (no devuelve nada) para ciertos perfiles de usuario, y
para otros no la cancela
[ ]
[ ]
Sí, pero devuelve al menos la información recuperada hasta ese
momento, independientemente del perfil de usuario
[ ]
[ ]
Cancela automáticamente la ejecución de una consulta cuando el
volumen de información recuperado sobrepasa un umbral definido
No
[ ]
[ ]

Sí, totalmente (no devuelve nada) independientemente del perfil
de usuario
[ ]
[ ]
Sí, totalmente (no devuelve nada) para ciertos perfiles de usuario, y
para otros no la cancela
[ ]
[ ]
Sí, pero devuelve al menos la información recuperada hasta ese
momento, independientemente del perfil de usuario
[ ]
[ ]
Cancela automáticamente la ejecución de una consulta cuando el
volumen deinformación accedido sobrepasa un umbral definido
No
[ ]
[ ]
Sí, totalmente (no devuelve nada) independientemente del perfil de usuario
[ ]
[ ]
Sí, totalmente (no devuelve nada) para ciertos perfiles de usuario, y
para otros no la cancela
[ ]
[ ]
Sí, pero devuelve al menos la información recuperada hasta ese
momento, independientemente del perfil de usuario
[ ]
[ ]
Permite rechazar consultas en base a la franja horaria
No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]

Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Permite rechazar consultas en base a la carga del sistema
No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]

Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]

Observaciones

- GESTIÓN DE ACCCESO Y EJECUCIÓN

. Seguridad de acceso
Indicar los niveles de seguridad soportados
Por usuario
[ ]
[ ]

Por grupo de usuario
[ ]
[ ]

Por consulta específica
[ ]
[ ]

Otros (especificar)
[ ]
[ ]

En qué plataforma se gestiona la seguridad
Puesto cliente
[ ]
[ ]

Servidor intermedio
[ ]
[ ]

Servidor central
[ ]
[ ]
Se realiza una identificación del usuario a la hora de acceder al sistema

No
[ ]
[ ]

Sí, sin password
[ ]
[ ]

Sí, con password
[ ]
[ ]
Almacenamiento físico de la password
Fichero plano
[ ]
[ ]
Base de datos propia
[ ]
[ ]

Base de datos externa (especificar los gestores soportados en observaciones)
[ ]
[ ]

Otros (especificar)
[ ]
[ ]

Localización física de la password
Puesto cliente
[ ]
[ ]
Servidor intermedio
[ ]
[ ]

Servidor central
[ ]
[ ]

Otros (especificar)
[ ]
[ ]

Se permite a nivel de seguridad auditar las operaciones realizadas por los diferentes
usuarios
[ ]
[ ]
En caso afirmativo, ¿cómo se almacena esta información?
Ficheros planos
[ ]
[ ]
Base de datos propia
[ ]
[ ]

Base de datos externa (especificar los gestores soportados en observaciones)
[ ]
[ ]

Otros (especificar)
[ ]
[ ]

En caso afirmativo, dónde se almacena esta información
Puesto cliente
[ ]
[ ]
Servidor intermedio
[ ]
[ ]

Servidor central
[ ]
[ ]

Otros (especificar)
[ ]
[ ]

Observaciones

. Limitaciones a nivel de acceso
Número máximo de accesos concurrentes para el mismo usuario
[ ]
[ ]
Número máximo de usuarios concurrentes
[ ]
[ ]
Existe la posibilidad de limitar el acceso a la información a nivel de
registro
[ ]
[ ]
En caso afirmativo, en base a qué criterio
Por consulta específica
[ ]
[ ]
Por grupo de usuario
[ ]
[ ]

Por usuario
[ ]
[ ]

Otros (especificar)
[ ]
[ ]

Es posible lanzar desde un mismo puesto cliente una consulta, y sin esperar a
recibir la respuesta lanzar otra
[ ]
[ ]

Observaciones

. Prioridades de ejecución
Se pueden establecer distintos grados de prioridad a la hora de ejecutar varias
consultas
[ ]
[ ]
En base a qué criterios se pueden dar prioridades de ejecución
Por usuario
[ ]
[ ]
Por grupo de usuario
[ ]
[ ]

Consultas específicas
[ ]
[ ]

Otros (especificar)
[ ]
[ ]

Observaciones

ACLARACIONES GENERALES

Observaciones

REFERENCIAS
Resumen de las principales instalaciones donde se encuentran instaladas las herramientas
propuestas, con una breve descripción del entorno tecnológico y de los volúmenes de información
manejados

Observaciones

4.- PRUEBAS DE VERIFICACIÓN Y CONTROL
Un Data Warehouse precisa de un conjunto de pasos desde su creación hasta su explotación final. En todos estos pasos se precisa de una herramienta que nos permita simplificar su ejecución. Debido a la amplia variedad de herramientas disponibles, y para asegurar la idoneidad de la herramienta, caben varias alternativas:
Evaluación distribuida: En ella se evaluaría cada herramienta en un paso concreto. Se vería cual es la que mejor se adapta a nuestras necesidades, y a continuación, examinaríamos la compatibilidad en cascada de todas ellas.
Evaluación centralizada: En ella se evaluaría el soporte que cada herramienta proporciona a todos los pasos, y a continuación se examina cual es la que globalmente se adecua de forma global a nuestras necesidades.
La elección de una u otra alternativa tiene sus ventajas e inconvenientes: la primera nos permitiría obtener la mejor herramienta (la de mejor relación cumplimiento expectativas/ precio), pero podría comprometer la cadena completa de uso de un Data Warehouse. Lo contrario ocurriría en la segunda alternativa.
Debido a la creciente información disponible de cada fabricante en Internet, y a su frecuente actualización, recomendamos la visita al Data Warehousing Information Center (LGI Systems Incorporated), desde su página principal en http://pwp.starnetinc.com/larryg/index.html en donde, desde donde se encuentran enlaces a:
Vendedores de herramientas de usuario final:
• Herramientas de Query and Reporting
• Bases de Datos OLAP y Multidimensionales
• Sistemas EIS (Executive Information Systems)
• Herramientas de Data Mining
• Recuperación de Documentos
• Sistemas de Información Geográfica (GIS)
• Herramientas de Análisis de Decisiones
• Estadísticas
• Modelado de Procesos
• Filtrado de Información
• Obtención de Informes
• Otras herramientas
Vendedores de Infraestrutura Tecnológica:
• Extracción de Datos, Limpieza y Carga
• Catalogación de la Información
• Bases de Datos para Data Warehousing
• Administración de Consulas y Almacenamiento
• Modelado de Datos para Data Warehouse
• Herramientas iddleware
• Aceleradoras de Query's y Carga
• Otras utilidades de BD
• Hardware
Vendedores por Función e Industria:
• Herramientas de Análisis Financiero
• Herramientas de Marketing y Análisis de Ventas
• Herramientas de Análisis de la cadena de suministro
• Herramientas para la Industria de la Salud
• Herramientas para la Industria Detallista
• Herramientas para el Sector Financiero
• Otras herramientas específicas

¿Qué es Business Intelligence?

2008-11-11T10:09:00.002+01:00

Business Intelligence es la habilidad para transformar los datos en información, y la información en conocimiento, de forma que se pueda optimizar el proceso de toma de decisiones en los negocios.

Desde un punto de vista más pragmático, y asociándolo directamente con las tecnologías de la información, podemos definir Business Intelligence como el conjunto de metodologías, aplicaciones y tecnologías que permiten reunir, depurar y transformar datos de los sistemas transaccionales e información desestructurada (interna y externa a la compañía) en información estructurada, para su explotación directa (reporting, análisis OLTP / OLAP, alertas...) o para su análisis y conversión en conocimiento, dando así soporte a la toma de decisiones sobre el negocio.

La inteligencia de negocio actúa como un factor estratégico para una empresa u organización, generando una potencial ventaja competitiva, que no es otra que proporcionar información privilegiada para responder a los problemas de negocio: entrada a nuevos mercados, promociones u ofertas de productos, eliminación de islas de información, control financiero, optimización de costes, planificación de la producción, análisis de perfiles de clientes, rentabilidad de un producto concreto, etc...

Los principales productos de Business Intelligence que existen hoy en día son:

* Cuadros de Mando Integrales (CMI)

* Sistemas de Soporte a la Decisión (DSS)

* Sistemas de Información Ejecutiva (EIS)

Por otro lado, los principales componentes de orígenes de datos en el Business Intelligence que existen en la actualidad son:

* Datamart

* Datawarehouse

Los sistemas y componentes del BI se diferencian de los sistemas operacionales en que están optimizados para preguntar y divulgar sobre datos. Esto significa típicamente que, en un datawarehouse, los datos están desnormalizados para apoyar consultas de alto rendimiento, mientras que en los sistemas operacionales suelen encontrarse normalizados para apoyar operaciones continuas de inserción, modificación y borrado de datos. En este sentido, los procesos ETL (extracción, transformación y carga), que nutren los sistemas BI, tienen que traducir de uno o varios sistemas operacionales normalizados e independientes a un único sistema desnormalizado, cuyos datos estén completamente integrados.

En definitiva, una solución BI completa permite:

* Observar ¿qué está ocurriendo?

* Comprender ¿por qué ocurre?

* Predecir ¿qué ocurriría?

* Colaborar ¿qué debería hacer el equipo?

* Decidir ¿qué camino se debe seguir?

Razones por las que invertir en Business Intelligence

2008-11-11T10:07:00.000+01:00

Según un artículo de Gartner Research, la falta de conocimiento es la mayor amenaza para las empresas modernas. Para ello, apuntan, “el objetivo del Business Intelligence es eliminar las conjeturas y la ignorancia en los ambientes empresariales, aprovechando los vastos volúmenes de datos cuantitativos que las empresas recolectan todos los días en sus diversas aplicaciones corporativas”.

* BI como solución tecnológica

* Centralizar, depurar y afianzar los datos. Las tecnologías de BI permiten reunir, normalizar y centralizar toda la información de la empresa, mediante un almacén de datos, permitiendo así su explotación sin esfuerzo. De esta forma, los departamentos comercial, operativo y financiero basan las decisiones estratégicas en la misma información.

* Descubrir información no evidente para las aplicaciones actuales. En el día a día de las aplicaciones de gestión se pueden esconder pautas de comportamiento, tendencias, evoluciones del mercado, cambios en el consumo o en la producción, que resulta prácticamente imposible reconocer sin el software adecuado. Es lo que se puede calificar como extraer información de los datos, y conocimiento de la información.

* Optimizar el rendimiento de los sistemas. Las plataformas de BI se diseñan para perfeccionar al máximo las consultas de alto nivel, realizando las transformaciones oportunas a cada sistema (OLTP - OLAP), y liberando los servidores operacionales.

* BI como ventaja competitiva

* Seguimiento real del plan estratégico. Si su empresa dispone de plan estratégico, el business intelligence le permite, mediante un cuadro de mando, crear, manejar y monitorizar las métricas y los objetivos estratégicos propuestos en ese plan, para poder detectar a tiempo las desviaciones, adoptando las acciones oportunas para corregirlas.

* Aprender de errores pasados. Al historizar los datos relevantes, una aplicación de BI permite que una empresa aprenda de su historia y de sus mejores prácticas, y que pueda evitar tropezarse de nuevo con los mismos errores del pasado.

* Mejorar la competitividad. Según la consultora internacional Gartner, 7 de cada 10 compañías realizan análisis sobre sus datos de forma diaria, o incluso instantánea, en el 2.006. Este mecanismo les permite maximizar su rentabilidad. La acuciante tendencia a explotar la información marca cada vez más la diferencia en los sectores.

* Obtener el verdadero valor de las aplicaciones de gestión. Durante los últimos años, las empresas se han embarcado en la construcción de estas aplicaciones clave para sus negocios. Sin embargo, no siempre han sabido aprovechar todo el potencial que les pueden proporcionar: cuentas de resultados, cash-flow, etc… Con el business intelligence, todos los empleados, desde el director general hasta el último analista, tienen acceso a información adecuada, integrada y actualizada

¿Cómo saber si su empresa necesita una solución BI?

2008-11-11T10:05:00.002+01:00

¿Cómo saber si su empresa necesita una solución BI?

Recuerde que el objetivo del Business Intelligence es colocar todos los datos al alcance de toda la empresa, proporcionando las herramientas para extraerlos de las aplicaciones, conferirles un formato estándar, y posteriormente almacenarlos en un repositorio optimizado para una entrega de la información rápida y resumida que haga posible un análisis muy detallado.

Para realizar un diagnóstico instantáneo de su empresa, sólo tiene que responder al siguiente cuestionario:

* ¿Está seguro de qué productos y clientes son los más importantes para su empresa?
Sí / No / N/a

* ¿Tiene problemas para crear una visión clara de toda su organización?
Sí / No / N/a

* ¿Sabe si está perdiendo cuota de mercado con respecto a su competencia?
Sí / No / N/a

* ¿Ha perdido oportunidades de negocio por recibir información atrasada?
Sí / No / N/a

* ¿Dedica horas extras a analizar documentos e informes?
Sí / No / N/a

* ¿Tiene informes de varios sistemas operacionales que no concuerdan?
Sí / No / N/a

* ¿Dispone de alguna ventaja competitiva clara con respecto a las demás empresas de su sector?
Sí / No / N/a

* ¿Sabe con certeza si su gente está alcanzando los objetivos planificados?
Sí / No / N/a

Si al menos la mitad de las respuestas han sido afirmativas, su empresa puede encontrar importantes beneficios al implantar un sistema de Business Intelligence. En caso contrario, puede consultar aquí los motivos por los que quizá llegue a interesarle en un futuro.

Datos, información, conocimiento

2008-11-11T10:03:00.000+01:00

¿En qué se diferencia el conocimiento de los datos y de la información? En una conversación informal, los tres términos suelen utilizarse indistintamente y esto puede llevar a una interpretación libre del concepto de conocimiento. Quizás la forma más sencilla de diferenciar los términos sea pensar que los datos están localizados en el mundo y el conocimiento está localizado en agentes de cualquier tipo (personas, empresas, máquinas...), mientras que la información adopta un papel mediador entre ambos.

Los conceptos que se muestran a continuación se basan en las definiciones de Davenport y Prusak (1999).

Datos

Los datos son la mínima unidad semántica, y se corresponden con elementos primarios de información que por sí solos son irrelevantes como apoyo a la toma de decisiones. También se pueden ver como un conjunto discreto de valores, que no dicen nada sobre el por qué de las cosas y no son orientativos para la acción.

Un número telefónico o un nombre de una persona, por ejemplo, son datos que, sin un propósito, una utilidad o un contexto no sirven como base para apoyar la toma de una decisión. Los datos pueden ser una colección de hechos almacenados en algún lugar físico como un papel, un dispositivo electrónico (CD, DVD, disco duro...), o la mente de una persona. En este sentido las tecnologías de la información han aportado mucho a recopilación de datos.

Como cabe suponer, los datos pueden provenir de fuentes externas o internas a la organización, pudiendo ser de carácter objetivo o subjetivo, o de tipo cualitativo o cuantitativo, etc.

Información

La información se puede definir como un conjunto de datos procesados y que tienen un significado (relevancia, propósito y contexto), y que por lo tanto son de utilidad para quién debe tomar decisiones, al disminuir su incertidumbre. Los datos se pueden transforman en información añadiéndoles valor:

* Contextualizando: se sabe en qué contexto y para qué propósito se generaron.

* Categorizando: se conocen las unidades de medida que ayudan a interpretarlos.

* Calculando: los datos pueden haber sido procesados matemática o estadísticamente.

* Corrigiendo: se han eliminado errores e inconsistencias de los datos.

* Condensando: los datos se han podido resumir de forma más concisa (agregación).

Por tanto, la información es la comunicación de conocimientos o inteligencia, y es capaz de cambiar la forma en que el receptor percibe algo, impactando sobre sus juicios de valor y sus comportamientos.

Información = Datos + Contexto (añadir valor) + Utilidad (disminuir la incertidumbre)

Conocimiento

El conocimiento es una mezcla de experiencia, valores, información y know-how que sirve como marco para la incorporación de nuevas experiencias e información, y es útil para la acción. Se origina y aplica en la mente de los conocedores. En las organizaciones con frecuencia no sólo se encuentra dentro de documentos o almacenes de datos, sino que también esta en rutinas organizativas, procesos, prácticas, y normas.

El conocimiento se deriva de la información, así como la información se deriva de los datos. Para que la información se convierta en conocimiento es necesario realizar acciones como:

* Comparación con otros elementos.

* Predicción de consecuencias.

* Búsqueda de conexiones.

* Conversación con otros portadores de conocimiento.