• Author / Uploaded
• Fiorella D Alfaro

Citation preview

DATA WAREHOUSE & BI Definiciones 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 Ralph Kimball “El Data Warehouse es un conjunto integrado de base de datos, con orientación temática, que están diseñados para el apoyo a la Toma de Decisiones, y donde cada unidad de datos es relevante en algún momento del tiempo.” Bill Inmon “Se considera al DW como algo que provee dos beneficios empresariales reales: Integración y Acceso de Datos. DW elimina una gran cantidad de datos inútiles y no deseados, como también el procesamiento desde el ambiente operacional clásico.” Susan Osterfeldt

Objetivos 







Hace que la información de la organización sea accesible: los contenidos del Data WareHouse son entendibles y navegables, y el acceso a ellos son caracterizado por el rápido desempeño. Hacer que la información de la organización sea consistente: la información de una parte de la organización puede hacerse coincidir con la información de la otra parte de la organización. Es información adaptable y elástica: el Data WareHouse esta diseñado para cambios continuos. Cuando se le hacen nuevas preguntas al Data WareHouse, los datos existentes y las tecnologías no cambian ni se corrompen. Cuando se agregan datos nuevos al Data WareHouse, los datos existentes y las tecnologías tampoco cambian ni se corrompen. Es la fundación de la toma de decisiones: el Data WareHouse tiene los datos correctos para soportar la toma de decisiones. Solo hay una salida verdadera del

DW: las decisiones que son hechas después de que el Data WareHouse haya presentado las evidencias. La original etiqueta que preside el Data WareHouse sigue siendo la mejor descripción de lo que queremos construir: un sistema de soporte a las decisiones.

Comparaciones DWH vs BD Operacional Se puede caracterizar un data warehouse haciendo un contraste de cómo los datos de un negocio almacenados en un data warehouse, difieren de los datos operacionales usados por las aplicaciones de producción.

Base de Datos Operacional

Data Warehouse

Datos Operacionales

Datos del negocio para Información

Orientado a la aplicación

Orientado al sujeto

Actual

Actual + histórico

Detallada

Detallada + más resumida

Cambia continuamente

Estable

DWH vs DataMarts Un Data Mart cumple los mismos principios que un Data Warehouse, construir un repositorio de datos único, consistente, fiable y de fácil acceso. Entonces ¿Qué diferencia hay entre un data warehouse y un data mart? Su alcance. El data mart está pensado para cubrir las necesidades de un grupo de trabajo o de un determinado departamento dentro de la organización, en cambio, el ámbito de un data warehouse es la organización en su conjunto. Se caracterizan por disponer la una estructura óptima de datos para analizar la información al detalle desde todas las perspectivas que afecten a los procesos de dicho departamento. Supone una buena opción para pequeñas y medianas empresas que no puedan afrontar el coste de poner en marcha un Data Warehouse. La escalabilidad de los data marts hacia el data warehouse puede ser una solución si el número de data marts aumenta considerablemente.

Características Entre las principales se tiene: o o o o

Orientado al tema Integrado De tiempo variante No volátil

ORIENTADA AL TEMA: Una primera característica del data warehouse es que la información se clasifica en base a los aspectos que son de interés para la empresa. Siendo así, los datos tomados están en contraste con los clásicos procesos orientados a las aplicaciones. En la Figura N° 1 se muestra el contraste entre los dos tipos de orientaciones.













El ambiente operacional se diseña alrededor de las aplicaciones y funciones tales como préstamos, ahorros, tarjeta bancaria y depósitos para una institución financiera. Por ejemplo, una aplicación de ingreso de órdenes puede accesar a los datos sobre clientes, productos y cuentas. La base de datos combina estos elementos en una estructura que acomoda las necesidades de la aplicación. En el ambiente data warehousing se organiza alrededor de sujetos tales como cliente, vendedor, producto y actividad. Por ejemplo, para un fabricante, éstos pueden ser clientes, productos, proveedores y vendedores. Para una universidad pueden ser estudiantes, clases y profesores. Para un hospital pueden ser pacientes, personal médico, medicamentos, etc. La alineación alrededor de las áreas de los temas afecta el diseño y la implementación de los datos encontrados en el data warehouse. Las principales áreas de los temas influyen en la parte más importante de la estructura clave. Las aplicaciones están relacionadas con el diseño de la base de datos y del proceso. En data warehousing se enfoca el modelamiento de datos y el diseño de la base de datos. El diseño del proceso (en su forma clásica) no es separado de este ambiente. Las diferencias entre la orientación de procesos y funciones de las aplicaciones y la orientación a temas, radican en el contenido de la data a nivel detallado. En el data warehouse se excluye la información que no será usada por el proceso de sistemas de soporte de decisiones, mientras que la información de las orientadas a las aplicaciones, contiene datos para satisfacer de inmediato los requerimientos funcionales y de proceso, que pueden ser usados o no por el analista de soporte de decisiones. Otra diferencia importante está en la interrelación de la información. Los datos operacionales mantienen una relación continua entre dos o más tablas basadas en una regla comercial que está vigente. Las del data warehouse miden un espectro de tiempo y las relaciones encontradas en el data warehouse son muchas. Muchas de las reglas comerciales (y sus correspondientes relaciones de datos) se representan en el data warehouse, entre dos o más tablas.

INTEGRACIÓN El aspecto más importante del ambiente data warehousing es que la información encontrada al interior está siempre integrada. La integración de datos se muestra de muchas maneras: en convenciones de nombres consistentes, en la medida uniforme de variables, en la codificación de estructuras consistentes, en atributos físicos de los datos consistentes, fuentes múltiples y otros.

El contraste de la integración encontrada en el data warehouse con la carencia de integración del ambiente de aplicaciones, se muestran en la Figura N° 2, con diferencias bien marcadas. A través de los años, los diseñadores de las diferentes aplicaciones han tomado sus propias decisiones sobre cómo se debería construir una aplicación. Los estilos y diseños personalizados se muestran de muchas maneras. Se diferencian en la codificación, en las estructuras claves, en sus características físicas, en las convenciones de nombramiento y otros. La capacidad colectiva de muchos de los diseñadores de aplicaciones, para crear aplicaciones inconsistentes, es fabulosa. La Figura N° 2 mencionada, muestra algunas de las diferencias más importantes en las formas en que se diseñan las aplicaciones. o

Codificación. Los diseñadores de aplicaciones codifican el campo GENERO en varias formas. Un diseñador representa GENERO como una "M" y una "F", otros como un "1" y un "0", otros como una "X" y una "Y" e inclusive, como "masculino" y "femenino".

No importa mucho cómo el GENERO llega al data warehouse. Probablemente "M" y "F" sean tan buenas como cualquier otra representación. Lo importante es que sea de

cualquier fuente de donde venga, el GENERO debe llegar al data warehouse en un estado integrado uniforme. Por lo tanto, cuando el GENERO se carga en el data warehouse desde una aplicación, donde ha sido representado en formato "M" y "F", los datos deben convertirse al formato del data warehouse. o

Medida de atributos. Los diseñadores de aplicaciones miden las unidades de medida de las tuberías en una variedad de formas. Un diseñador almacena los datos de tuberías en centímetros, otros en pulgadas, otros en millones de pies cúbicos por segundo y otros en yardas.

Al dar medidas a los atributos, la transformación traduce las diversas unidades de medida usadas en las diferentes bases de datos para transformarlas en una medida estándar común. Cualquiera que sea la fuente, cuando la información de la tubería llegue al data warehouse necesitará ser medida de la misma manera. o

o

Convenciones de Nombramiento.- El mismo elemento es frecuentemente referido por nombres diferentes en las diversas aplicaciones. El proceso de transformación asegura que se use preferentemente el nombre de usuario. Fuentes Múltiples.- El mismo elemento puede derivarse desde fuentes múltiples. En este caso, el proceso de transformación debe asegurar que la fuente apropiada sea usada, documentada y movida al depósito.

Tal como se muestra en la figura, los puntos de integración afectan casi todos los aspectos de diseño - las características físicas de los datos, la disyuntiva de tener más de una de fuente de datos, el problema de estándares de denominación inconsistentes, formatos de fecha inconsistentes y otros. Cualquiera que sea la forma del diseño, el resultado es el mismo - la información necesita ser almacenada en el data warehouse en un modelo globalmente aceptable y singular, aun cuando los sistemas operacionales subyacentes almacenen los datos de manera diferente. Cuando el analista de sistema de soporte de decisiones observe el data warehouse, su enfoque deberá estar en el uso de los datos que se encuentre en el depósito, antes que preguntarse sobre la confiabilidad o consistencia de los datos. DE TIEMPO VARIANTE Toda la información del data warehouse es requerida en algún momento. Esta característica básica de los datos en un depósito, es muy diferente de la información

encontrada en el ambiente operacional. En éstos, la información se requiere al momento de accesar. En otras palabras, en el ambiente operacional, cuando usted accesa a una unidad de información, usted espera que los valores requeridos se obtengan a partir del momento de acceso. Como la información en el data warehouse es solicitada en cualquier momento (es decir, no "ahora mismo"), los datos encontrados en el depósito se llaman de "tiempo variante". Los datos históricos son de poco uso en el procesamiento operacional. La información del depósito por el contraste, debe incluir los datos históricos para usarse en la identificación y evaluación de tendencias. (Ver Figura N° 3).

El tiempo variante se muestra de varias maneras: 1° La más simple es que la información representa los datos sobre un horizonte largo de tiempo - desde cinco a diez años. El horizonte de tiempo representado para el ambiente operacional es mucho más corto - desde valores actuales hasta sesenta a noventa días. Las aplicaciones que tienen un buen rendimiento y están disponibles para el procesamiento de transacciones, deben llevar una cantidad mínima de datos si tienen cualquier grado de flexibilidad. Por ello, las aplicaciones operacionales tienen un corto horizonte de tiempo, debido al diseño de aplicaciones rígidas. 2° La segunda manera en la que se muestra el tiempo variante en el data warehouse está en la estructura clave. Cada estructura clave en el data warehouse contiene, implícita o explícitamente, un elemento de tiempo como día, semana, mes, etc. El elemento de tiempo está casi siempre al pie de la clave concatenada, encontrada en el data warehouse. En ocasiones, el elemento de tiempo existirá implícitamente, como el caso en que un archivo completo se duplica al final del mes, o al cuarto.

3° La tercera manera en que aparece el tiempo variante es cuando la información del data warehouse, una vez registrada correctamente, no puede ser actualizada. La información del data warehouse es, para todos los propósitos prácticos, una serie larga de "snapshots" (vistas instantáneas). Por supuesto, si los snapshots de los datos se han tomado incorrectamente, entonces pueden ser cambiados. Asumiendo que los snapshots se han tomado adecuadamente, ellos no son alterados una vez hechos. En algunos casos puede ser no ético, e incluso ilegal, alterar los snapshots en el data warehouse. Los datos operacionales, siendo requeridos a partir del momento de acceso, pueden actualizarse de acuerdo a la necesidad. NO VOLATIL La información es útil sólo cuando es estable. Los datos operacionales cambian sobre una base momento a momento. La perspectiva más grande, esencial para el análisis y la toma de decisiones, requiere una base de datos estable. En la Figura N° 4 se muestra que la actualización (insertar, borrar y modificar), se hace regularmente en el ambiente operacional sobre una base de registro por registro. Pero la manipulación básica de los datos que ocurre en el data warehouse es mucho más simple. Hay dos únicos tipos de operaciones: la carga inicial de datos y el acceso a los mismos. No hay actualización de datos (en el sentido general de actualización) en el depósito, como una parte normal de procesamiento. Hay algunas consecuencias muy importantes de esta diferencia básica, entre el procesamiento operacional y del data warehouse. En el nivel de diseño, la necesidad de ser precavido para actualizar las anomalías no es un factor en el data warehouse, ya que no se hace la actualización de datos. Esto significa que en el nivel físico de diseño, se pueden tomar libertades para optimizar el acceso a los datos, particularmente al usar la normalización y de normalización física. Otra consecuencia de la simplicidad de la operación del data warehouse está en la tecnología subyacente, utilizada para correr los datos en el depósito. Teniendo que soportar la actualización de registro por registro en modo on-line (como es frecuente en el caso del procesamiento operacional) requiere que la tecnología tenga un fundamento muy complejo debajo de una fachada de simplicidad.

La tecnología permite realizar backup y recuperación, transacciones e integridad de los datos y la detección y solución al estancamiento que es más complejo. En el data warehouse no es necesario el procesamiento. La fuente de casi toda la información del data warehouse es el ambiente operacional. A simple vista, se puede pensar que hay redundancia masiva de datos entre los dos ambientes. Desde luego, la primera impresión de muchas personas se centra en la gran redundancia de datos, entre el ambiente operacional y el ambiente de data warehouse. Dicho razonamiento es superficial y demuestra una carencia de entendimiento con respecto a qué ocurre en el data warehouse. De hecho, hay una mínima redundancia de datos entre ambos ambientes. Se debe considerar lo siguiente: Los datos se filtran cuando pasan desde el ambiente operacional al de depósito. Existe mucha data que nunca sale del ambiente operacional. Sólo los datos que realmente se necesitan ingresarán al ambiente de data warehouse. El horizonte de tiempo de los datos es muy diferente de un ambiente al otro. La información en el ambiente operacional es más reciente con respecto a la del data warehouse. Desde la perspectiva de los horizontes de tiempo únicos, hay poca superposición entre los ambientes operacional y de data warehouse. El data warehouse contiene un resumen de la información que no se encuentra en el ambiente operacional. Los datos experimentan una transformación fundamental cuando pasa al data warehouse. La mayor parte de los datos se alteran significativamente al ser seleccionados y movidos al data warehouse. Dicho de otra manera, la mayoría de los datos se alteran física y radicalmente cuando se mueven al depósito. No es la misma data que reside en el ambiente operacional desde el punto de vista de integración. En vista de estos factores, la redundancia de datos entre los dos ambientes es una ocurrencia rara, que resulta en menos de 1%.

Metodología De Diseño De Un Data WareHouse Metodología Kimball La metodología se basa en lo que Kimball denomina Ciclo de Vida Dimensional del Negocio. Este ciclo de vida del proyecto de DW, está basado en cuatro principios básicos:  Centrarse en el negocio: Hay que concentrarse en la identificación de los requerimientos del negocio y su valor asociado, y usar estos esfuerzos para

desarrollar relaciones sólidas con el negocio, agudizando el análisis del mismo y la competencia consultiva de los implementadores.  Construir una infraestructura de información adecuada: Diseñar una base de información única, integrada, fácil de usar, de alto rendimiento donde se reflejará la amplia gama de requerimientos de negocio identificados en la empresa.  Realizar entregas en incrementos significativos: crear el almacén de datos (DW) en incrementos entregables en plazos de 6 a 12 meses. Hay que usa el valor de negocio de cada elemento identificado para determinar el orden de aplicación de los incrementos. En esto la metodología se parece a las metodologías ágiles de construcción de software.  Ofrecer la solución completa: proporcionar todos los elementos necesarios para entregar valor a los usuarios de negocios. Para comenzar, esto significa tener un almacén de datos sólido, bien diseñado, con calidad probada, y accesible. También se deberá entregar herramientas de consulta ad hoc, aplicaciones para informes y análisis avanzado, capacitación, soporte, sitio web y documentación. La construcción de una solución de DW/BI (Datawarehouse/Business Intelligence) es sumamente compleja, y Kimball nos propone una metodología que nos ayuda a simplificar esa complejidad. A continuación se muestra un cuadro de esta medología: Primero, hay que resaltar el rol central de la tarea de definición de requerimientos. Los requerimientos del negocio son el soporte inicial de las tareas subsiguientes. También tiene influencia en el plan de proyecto (nótese la doble fecha entre la caja de definición de requerimientos y la de planificación). En segundo lugar podemos ver tres rutas o caminos que se enfocan en tres diferentes áreas:

 



Tecnología (Camino Superior). Implica tareas relacionadas con software específico, por ejemplo, Microsoft SQL Analysis Services. Datos (Camino del medio). En la misma diseñaremos e implementaremos el modelo dimensional, y desarrollaremos el subsistema de Extracción, Transformación y Carga (Extract, Transformation, and Load - ETL) para cargar el DW. Aplicaciones de Inteligencia de Negocios (Camino Inferior). En esta ruta se encuentran tareas en las que diseñamos y desarrollamos las aplicaciones de negocios para los usuarios finales.

Estas rutas se combinan cuando se instala finalmente el sistema. En la parte de debajo de la figura se muestra la actividad general de administración del proyecto.

Fases Para La Elaboración de un DWH -

Organización

Factores en planificación de una Data Warehouse Establecer una asociación de usuarios, gestión y grupos Construir prototipos rápida y frecuentemente Implementación incremental Reportar activamente y publicar los casos de éxito. Estrategias para el desarrollo de una Data Warehouse Establecer un ambiente Data Warehouse Virtual Construir una copia de los datos operacionales desde un sistema opcional único y posibilitar al data warehouse de una serie de herramientas de acceso a la información. La estrategia Data Warehousing óptima es seleccionar el número de usuarios basados en el valor de la empresa y hacer un análisis de sus puntos, preguntas y necesidades de acceso a datos. Estrategias para el diseño de una data warehouse Los usuarios de una DWH generalmente no conocen mucho sobre sus requerimientos y necesidades como los usuarios operacionales.

El diseño de una DWH, con frecuencia involucra lo que se piensa en términos más amplios y con conceptos del negocio mas difíciles de definir que en el diseño de un sistema operacional. Al respecto, un DWH esta bastante cerca a la reingeniería de los procesos del negocio. Finalmente la estrategia de diseño ideal para un DWH es generalmente de afuera hacia adentro a diferencia de arriba hacia abajo. Estrategias para la gestión de un DWH Un DWH es una buena inversión, sólo si los usuarios finales realmente pueden conseguir información vital más rápida y más barata de lo que obtienen con la tecnología actual. La administración debe de reconocer que el mantenimiento de la estructura de un DWH es tan crítico como el mantenimiento de cualquier otra aplicación de misión critica. -

Desarrollo

¿Porqué construir bloques de DWH? El crecimiento de la computación Cliente/Servidor, ha creado servidores de hardware y software más poderosos y sofisticados que nunca. Los servidores de hoy compiten con los mainframes de ayer y ofrecen arquitecturas superiores, procesadores de alta velocidad y capacidades de almacenamiento masivas. Consideraciones previas al desarrollo de un DWH Hay muchas maneras de desarrollar DWH como tantas organizaciones existan. Sin embargo hay un número de dimensiones diferentes que necesitan ser nombradas: Alcance de un DWH Redundancia de datos Tipo de usuario final Elementos claves para desarrollar una DWH Si se escoge incorrectamente, el DWH se convierte en un gran problema para empresas las cuales no pueden trabajar en sus plataformas, costosas de arreglar y difíciles de justificar. Para conseguir que la implementación del depósito tenga un inicio exitoso, se necesita enfocar hacia tres bloques claves de construcción:

Arquitectura total de depósito Arquitecturas de servidor Sistemas de gestión de base de datos Confiabilidad de datos La data “sucia” es peligrosa. Las herramientas de limpieza especializadas y las formas de programar de los clientes proporcionan redes de seguridad. No importa como este diseñado un programa o cuan habitual se use. Si se implementa mala información, se obtendrá resultados incorrectos o falsos. Desafortunadamente, los datos que se usan satisfactoriamente en las aplicaciones de línea comercial operacionales pueden ser basura en lo que concierne a la aplicación DWH. FACTORES DECISIVOS PARA DECIDIR EL DESARROLLO DE UN DWH La data sucia es un serio peligro para el éxito de un proyecto de DWH, Dependiendo del alcance del problema, simplemente podría no ser posible dirigirlo rápidamente y abaratarlo. Los principales factores son: El tiempo que toma la programación interna El costo de la herramienta -

IMPLEMENTACIÓN

ELEMENTOS A CONSIDERAR EN LA IMPLEMENTACIÓN Es más viable el desarrollo de proyectos en fases que produzcan resultados a corto plazo que el desarrollo de un proyecto que entregue resultados al término de varios años. Por ello el proyecto debe estar centrado en un área o en un proceso. El modelo lógico de datos debe tener un alcance más alto y cubrir todas las áreas de interés, así como procesos más estratégicos de cada uno de ellas. Decidir sobre qué tipo de proyecto, es algo más complicado. Un proyecto especializado soporta directamente un proyecto específico, por ejemplo: Retención de clientes. Un proyecto base entrega capacidad genérica de análisis a todos los usuarios que tengan acceso al DWH, pero no tiene, entre sus funcionalidades, la solución de un problema especifico o el soporte especializado de un proceso especifico.

ESTRATEGIAS PARA EL PROCESO DE IMPLEMENTACIÓN Identificar el problema en el cual el uso estratégico de la información detallada, permita conseguir una solución para generar una ventaja competitiva o un ahorro de costos. Definir el modelo lógico de datos a implementar para resolver el problema planteado. -

EVALUACIÓN

COSTOS Y BENEFICIOS Costos preliminares   

Planificación Diseño Modelamiento

Costos iniciales  

Plataforma de hardware Software base de datos

Costos en procesamiento  

Desarrollo de aplicaciones Capacitación y soporte

Beneficios tácticos  

Impresión y emisión de reporte Demanda reducida para consulta de clientes

Beneficios estratégicos    

Aplicaciones y herramientas de acceso para los usuarios finales Decisiones con mayor información Toma de decisiones más rápida Capacidad de soporte a la información organizacional

BENEFICIOS A OBTENER Para la empresa El DWH hace lo posible por aprovechar el valor potencial enorme de los recursos de información de la empresa y volver ese valor potencial en valor verdadero.

Para los usuarios En DWH extiende el alcance de la información para que puedan acceder directamente en línea, lo que a la vez contribuye en su capacidad para operar con mayor efectividad las áreas rutinarias o no.

Productos, Suites o marcas que brindan esta solución BI4Dynamics NAV Es un software de Business Intelligence que se considera el mejor en relación a tareas de reporting y analisis. El sistema BI4Dynamics NAV soluciona este hecho utilizando las herramientas de Data Warehouse, el “corazón” de la solución. La mayoría de los expertos de inteligencia de negocio consideran esta solución como la mejor infraestructura para apoyar iniciativas estratégicas. Data Warehouse permite integrar información dispar, información histórica que puede ser analizada desde prácticamente cualquier perspectiva, y la oportunidad de crear un sistema para proporcionar información consistente para la toma de decisiones a los responsables de la Compañía. Data warehouse está específicamente diseñada para responder a las necesidades de análisis de datos y reportes, a diferencia de las soluciones que se basan en la utilización de sistemas operacionales, penalizando así a los mismos, y sin llegar a las capacidades analíticas de una herramienta de Data Warehouse. ORACLE Oracle Business Intelligence Suite es una solución integrada de productos de inteligencia empresarial (BI) con cuadros de mando, un completo sistema de consultas ad hoc, alertas e información proactiva, informes financieros y corporativos, datos predictivos en tiempo real y análisis desconectado entre otras funciones. Los componentes de Oracle Business Intelligence Suite se basan en una arquitectura web orientada a servicios que se integra en la infraestructura empresarial existente, con el menor coste total de propiedad. Oracle Business Intelligence Suite Enterprise Edition Plus proporciona el conocimiento completo y relevante al alcance de cada una de las personas de la organización, simplifica la toma de decisiones y mejora la productividad de los procesos empresariales. Con el Business Intelligence puede convertir los datos almacenados de su empresa en información útil de la situación actual y de la evolución de su empresa. Puede establecer diferentes fuentes de datos, ya sea de su ERP, CRM, una base de datos, ficheros en Excel de presupuestos, ficheros de texto..., y analizar toda la información conjuntamente.

Fuentes de datos soportadas:                

Oracle Database Oracle E-Business Suite JDEdwards EPM Siebel CRM Hyperion Essbase SAP BW Microsoft Analysis Services Hyperion Planning - System 9 Hyperion Financial Management - System IBM DB/2 Database Teradata Warehouse Microsoft SQL Server Microsoft Excel Ficheros de texto Fuentes ODBC XML

Dyssa Logistics Warehouse Ofrece la funcionalidad necesaria para regular los flujos, optimizar la rotación, mejorar el GMROI(1), la rapidez en la entrega, calidad de servicio y reducir costes, son algunos de los indicadores de medida de la eficiencia del almacén que sólo un SGA permite controlar. Dyssa Logistics Warehouse dirige y controla, mediante códigos de barras, mercancías, recursos y flujos de almacenes. Dyssa Logistics Warehouse gestiona y controla todo tipo de almacenes: manuales y automáticos, con o sin radiofrecuencia y mixtos. Dyssa Logistics Warehouse se integra con plataformas SAP© y otros ERPs del mercado. La arquitectura multialmacén lo convierte en un SGA ideal tanto para operadores logísticos como para empresas con procesos logísticos complejos. Dyssa Logistics Warehouse es una solución de gestión y control de almacén (SGA) con o sin radiofrecuencia. MERCADO PERUANO: ESTADO ACTUAL Y EVOLUCION DE BI EN PERÚ. En la actualidad no son muchas las empresas que conocen a fondo los conceptos del Business Intelligence o Inteligencia de Negocio (traducido al español). Y es que muchas de las empresas están amarradas u obligadas a tener toda su data en los software convencionales que en muchos casos no hacen otra función que contener datos sin arrojar

datos estadísticos que brinden a las empresas la “inteligencia de negocio” que ellos desean. Este concepto ocurre mayormente en las pequeñas y medianas empresas que por su condición en el mercado no ven o avizoran el amplio panorama de oportunidades que tienen de aplicar este tipo de metodología en sus empresas permitiendo de esta manera una evolución constante hacia sus metas. Estos conceptos de inteligencia de negocios han ido cobrando relevancia en los últimos años y aquí presentamos un caso de éxito: CASO INTERBANK: Interbank, una de las empresas pioneras en el sector financiero peruano, confirma los beneficios que ofrece SAP BusinessObjects, en la gestión de datos, brindando visibilidad del negocio para la toma de decisiones. A través de la herramienta SAP BusinessObjects, el banco ha logrado la democratización la información, facilitando su acceso y obtención de manera inmediata y confiable. Hasta hace unos años el banco InterBank contaba con información recopilada en hojas de Excel, los cuales no le permitían a la entidad bancaría contar con información actual o fiable que le permita tomar desiciones sobre el qué hacer o cual sería el siguiente paso para la toma y gestión de información que generaba cada cliente al acceder y consultar distintos procesos en sus sistemas. Es por este motivo que en la búsqueda de la gestión de información y correcta toma de decisiones es que obtarón por SAP BusinessObject, es cual cuenta con un layout de navegación y análisis de información donde es posible tomar datos de una base central y complementarlo con otras para llevar a cabo el análisis a profundidad de lo que se requiere en función a las necesidades de los usuarios. De tal manera que con esta herramienta se la logrado la integración de gran parte de la información que se maneja, cubriendo canales, es decir de las diferentes sucursales que la compañía tiene, enfocados a la atención masiva de clientes y las áreas de Staff, incluyendo Planeamiento, Gestión y Seguimiento de Banca Personal y Comercial, Cobranzas, Riesgo de Mercado, además de las áreas comerciales. Empresas o compañías como InterBank, poco a poco esta adoptando estas nuevas medidas para el manejo y gestión de la información que ellos generan día a día, pero que aún no saben como gestionarlas. Es por ello que casos de éxitos como este generan relevancia y ayudan a educar a empresas en temas como la Inteligencia de Negocios.

Conclusión  Un Data Warehouse almacenar y proveer a la Organización de información relevante y a tiempo.  Para diseñar una buena arquitectura de DWH es necesario como primer paso conocer bien los requerimientos del negocio y hacer un estudio profundo de las fuentes externas que nos van a suministrar los datos. Además, hacer un buen diseño del área de transformación de datos, cuales son las transformaciones que se van a realizar y como se van a implementar el modelo dimensional con sus tablas de hechos y de dimensiones.  La metodología de Kimball proporciona una base empírica y metodológica adecuada para las implementaciones de almacenes de datos pequeños y medianos, dada su gran versatilidad y su enfoque ascendente, que permite construir los almacenes en forma escalonada. Además presenta una serie de herramientas, tales como planillas, gráficos y documentos, que proporcionan una gran ayuda para iniciarse en el ámbito de la construcción de un Datawarehouse.  La utilización de la metodología HEFESTO, nos ayuda a tener una nueva perspectiva sobre la fase de construcción e implementación de una Data Warehouse, ya que esta toma gran parte de la metodología Kimball y la fusiona con la suya para este fin. Cabe resaltar que esta metodología usa la base del OpenSource, por lo cual está en constante evolución.