Inteligencia de Negocios

Proyectos de Sistemas de Informacin Gerencial nuevaCapitulo 1. Introduccin a la Inteligencia de NegociosQue es Inteligencia de Negocios?Es un modelo de negocios que permite una toma de decisiones mas rpida y fcil. Las empresas renen enormes cantidades de datos todos los das: informacin sobre ordenes, inventarios, cuentas por pagar, transacciones de los puntos de venta y por supuesto clientes. Las empresas tambin adquieren datos (direcciones de correos, datos demogrficos) de fuentes externas. Desafortunadamente mas del 93% de los datos corporativos no se emplean en los procesos de toma de decisiones empresariales segn una reciente encuesta. La consolidacin y organizacin de los datos para la toma de decisiones permite lograr una ventaja competitiva y la inteligencia de negocios esta justamente orientada a descubrir y mantener esta ventaja competitiva. Mas que una combinacin de datos y tecnologa. BI le ayuda a crear conocimiento de un mundo de informacin. Obtener los datos apropiados, descubrir su potencialidad y compartir el valor, BI transforma la informacin en conocimiento. La Inteligencia de Negocios es la actividad que coloca la informacin apropiada en las manos de los usuarios adecuados en el momento adecuado para el proceso de toma de decisiones mas eficiente.

Como Identificar a un candidato de Inteligencia de Negocios?El siguiente proceso le ayudara a descubrir o determinar a candidatos a Inteligencia de Negocios. La siguiente seccin proporciona algunas interrogantes que le ayudara en el proceso de anlisis, estas preguntas son categorizadas por niveles de decisin y reas dentro de una negocio, seguida por posibles respuestas.

Ejecutivo Senior de una corporacin Como en la actualidad monitorea los indicadores claves de performance de su empresa? Como en la actualidad recibe los reportes mensuales de gerencia? Cuan fcil puede en la actualidad responder a preguntas ad hoc con su actual sistema de reportes? Puede usted rapidamente detectar tendencias y excepciones en su empresa? Alguna persona de la gerencia esta trabajando sobre la misma informacin? Dependiendo de las respuestas del ejecutivo, se establecen los requerimientos que podran definir si es un buen candidato a BI. Las respuestas siguientes a las preguntas anteriores podran indicar una necesidad de BI de parte del cliente: Insatisfaccin con el actual sistema de reportes, especialmente en los temas de flexibilidad, tiempos, exactitud, detalle, consistencia e integridad de la informacin a travs de los diferentes usuarios. Muchos empleados de la empresa gastan mucho tiempo en la redigitacin de datos en las hojas electrnicas. El ejecutivo senior no tiene claridad en como se controlan las variables claves de performance en la empresa.

Documento traducido de: The IBM Business Intelligence - Professional Certification Program

Proyectos de Sistemas de Informacin GerencialPrincipales trminos de BI Base de Datos OperacionalSon base de datos orientadas al detalle diseadas para cubrir las necesidades de algunos procesos complejos de la empresa. Los datos son normalizados para evitar redundancia y doble mantenimiento.

OLTPEl Procesamiento de transacciones On-Line (OLTP) describe la manera en que los datos son procesados por el usuario final o el sistema. Esta orientada al detalle, repetitiva con mucha informacin actualizada y agregada por el usuario final.

Data warehouseEs una base de datos cuyos datos es almacenada para los propsitos de anlisis. La principal caracterstica de un datawarehouse es su propsito. La mayora de los datos es reunido para administrar la marcha delos negocios de una empresa. Este tipo de datos se conoce como datos operacionales. Los sistemas que administran estos datos operacionales se conocen como sistemas OLTP (On-Line Transaction Processing). Un datawarehouse recoge, organiza y convierte los datos disponibles para los propsitos de anlisis del negocio. Este tipo de dato se conoce como dato informacional Los sistemas empleados para trabajar con data informacional se conocen como OLAP (On line Analitycal Processing) . Bill Inmon acuo el termino "data warehouse" en 1990. Su definicin es: "Un (data) warehouse es una coleccin de datos orientada a temas, integrada, variante en el tiempo y no voltil que ayuda al proceso de toma de decisiones empresariales." Orientada a temas Los datos proporcionan informacin sobre un aspecto o rea de la empresa. Integrada Los datos son reunidos en un repositorio de datos provenientes de una variedad de sistemas fuentes. Variante en el tiempo Todos los datos en el data warehouse estn asociados a un periodo de tiempo especifico.

Data martUn data mart contiene una parte de la informacin corporativa que solo tiene valor para una determinado unidad de negocio, departamento o grupo de usuarios. Esta sub rea de datos consiste de datos historicos, detallados y resumidos capturados de los sistemas de procesamiento de transacciones o del datawarehouse de la empresa.

Fuentes de datos externasDatos externos son datos que no pueden ser encontrados en los sistemas OLTP pero que son necesarios para mejorar la calidad de los datos del datawarehouse.

OLAPOn-Line Analytical Processing (OLAP) es una categora de software que permite a los analistas, gerentes y ejecutivos alcanzar un conocimiento profundo de los datos a travs de un acceso rpido, consistente e interactivo a una amplia variedad de vistas de datos que han sido


Proyectos de Sistemas de Informacin Gerencialtransformados de datos no procesados para reflejar la realidad de una empresa tal como es entendida por el usuario final. La funcionalidad OLAP se caracteriza por el anlisis multidimensional dinmico de los datos consolidados de una empresa, que incluyen: Clculos y modelamientos aplicadas a las dimensiones en forma cruzada a travs de jerarquas. Anlisis de tendencias en periodos de tiempos secuenciales. Anlisis de segmentos de travs de vistas en pantallas. Drill-down para profundizar niveles de anlisis de consolidacin. Rotacin a nuevas comparaciones dimensinales en las vistas. OLAP es implementado en modo cliente / servidor multi - usuario y ofrece consistente y rpida respuestas a consultas independientemente del tamao y complejidad de la base de datos. OLAP ayuda a los usuarios a sintetizar la informacin del negocio a travs de vistas personalizadas y comparativas as como anlisis de informacin histrica y proyectada basadas en escenarios tipo "what-if". Esto es logrado gracias al uso del servidor OLAP.

OLAP serverUn servidor OLAP es un motor de administracin de datos multi usuarios, de alta capacidad especialmente diseado para operar en estructuras de datos multi dimensinales. Una estructura multi dimensional es definida de modo que cada campo de datos esta localizado y es accesado, basado en las intersecciones de las dimensiones que definen cada dato. El diseo de el servidor y la estructura de los datos son optimizados para una recuperacin de datos rpida y ad hoc.

Metadata una definicinMetadata es el tipo de informacin que describe como esta almacenada los datos en la base de datos e incluye informacin como: Una descripcin de tablas y campos en el data warehouse, incluyendo los tipos de datos y el rango de los datos que pueden ser aceptados. Una descripcin similar de tablas y campos en las base de datos fuentes, con un mapeo de los campos de la fuente al repositorio. Una descripcin de como los datos han sido transformados incluyendo las formulas, formateos, conversin de moneda y agregacin de tiempos. formatting, currency conversion, and time aggregation. Cualquier otra informacin que es necesaria para soportar y administrar las operaciones en el data warehouse.

Base de datos operacional versus informacionalLa mayor diferencia entre la base de datos operacional e informacional es la frecuencia de actualizacin: 1. En la D.B operacional un gran numero de transacciones se ejecuta cada hora. La base de datos siempre esta actualizndose y representa una fotografa de la situacin actual del negocio o mas comnmente conocida como un punto en el tiempo. 2. Las D.B Informacionales son usualmente estables en el tiempo y permiten representar una situacin en un pasado en el tiempo, la cual refleja datos histricos. Por ejemplo un data warehouse es cargado (actualizado) al final de la noche. Este proceso extrae todos los cambios producidos y los nuevos registros de las D.B operacionales.


Proyectos de Sistemas de Informacin Gerencial

Data miningEs el proceso de extraccin de informacin valida, til, previamente desconocida y comprensible para el empleo en la toma de decisiones del negocio.


Proyectos de Sistemas de Informacin Gerencial Capitulo 2. Implementacin de BI y conceptos de warehouse2.1. Diferentes implementaciones BIDistintos mtodos se han implementado en el pasado para encontrar un adecuado modo de satisfacer los requerimientos del Procesamiento Analtico On Line (On Line Analytical Processing). El presente grafico muestra los 4 modelos principales para implementar un Sistema de Soporte a las Decisiones.


Proyectos de Sistemas de Informacin Gerencial2.1.1 Tablas consolidadas (Summary table)Una tabla resumen en un sistema OLTP es la implementacin mas comn que viene incluida en la mayora de los paquetes de software. Usualmente estas tablas de resumen cubren solo algunas reas de requerimientos de los analistas de negocios. La siguiente figura muestra las ventajas y desventajas de este mtodo:

2.1.2. OLTP data en Servidor separadoLos datos de un sistema OLTP movidos a un servidor independiente, no implica cambios en la estructura de la base de datos. Este arreglo en espejo es el primer paso para descargar el flujo de trabajo de un sistema OLTP a un servidor dedicado OLAP. El siguiente cuadro muestra este mtodo, llamado tambin A Poor Mans Data Warehouse.



La tcnica de mover los datos originales OLTP peridicamente a un servidor dedicado para propsitos de reportes es un paso que se puede realizar para evitar los periodos largos de procesamiento para las consultas en el sistema. Adicionalmente a las ventajas en performance, la seguridad es mas fcil de manejar en esta arquitectura. Los sistemas completamente aislados eliminan cualquier interdependencia entre el flujo de trabajo operacional y el de anlisis. El mayor problema que aun persiste en esta arquitectura es que la arquitectura de la base de datos no ha sido optimizada para los procesos de consulta. El mayor nivel de detalle de la informacin se copia en el servidor de anlisis dedicado.

2.1.3 Data mart unicoUn creciente nmero de clientes estn implementando data marts nicos para tener la experiencia de trabajar con data warehousing. Este primer nivel (muro) en el datawarehouse debe estar bajo control, ya que la creacin de muchos datamarts pueden generar una pesadilla para la administracin. El modelo de 2 niveles en la creacin de un nico data mart en un servidor dedicado incluye mayor preparacin, planeamiento e inversin. El siguiente cuadro muestra este mtodo:



El mayor beneficio de esta solucin frente a los otros modelos esta en la performance, en los valores agregados y precalculados, en la gran flexibilidad para agregar datos adicionales de mltiples sistemas y aplicaciones OLTP y en las mas eficientes posibilidades de almacenar datos histricos. Un Metadata puede ser agregado al data mart para mejorar la facilidad de uso y la navegacin en la base de datos informacional. El modelo de data warehouse de 3 bloques (three-tiered data warehouse) consiste de 3 fases de datos almacenados en el sistema (como se muestra en la figura siguiente): Datos OLTP en base de datos operacional Datos extrados, detallados, de normalizados, organizados en un modelo Star-Join Schema para mejorar las performances de consulta. Diversos data marts precalculados para presentar los datos al usuario final.



Las caracteristicas de este modelo son: Data marts departamentales que mantienen los datos organizados que son optimizados de acuerdo a requerimientos especficos. Nuevos requerimientos precisan usualmente la creacin de un nuevo data mart que no afecta los componentes ya existentes del data warehouse. Cambios en la informacin histrica despus de tiempo pueden ser almacenados en el data warehouse. Metadata es el componente que garantiza el xito de esta arquitectura. Fcil de usar y navegar para el usuario final. La transformacin y depuracin de datos tambin es empleada en esta arquitectura. Las 3 etapas en la agregacin / transformacin de datos ofrece la posibilidad de efectuar tareas de data mining con los datos extrados sin necesidad de crear flujos de trabajo en el sistema operacional.


Proyectos de Sistemas de Informacin GerencialComponentes de un Data WarehouseLa siguiente figura muestra los diversos componentes de un data warehouse.

En el grafico se muestran los siguientes conceptos: Los procesos y / o elementos esenciales para tener actualizado el data warehouse son: extraccin / propagacin, refinamiento de datos, presentacin y herramientas de anlisis. Las diferentes etapas en la agregacin de datos son: OLTP data, ODS, Star-Join Schema, y data marts. El Metadata y las relaciones con cada proceso se muestran a travs de conectores. La lnea horizontal punteada separa las actividades en 2 grupos: Las tareas ejecutadas en el sistema dedicado OLTP son mejoradas por el contacto interactivo y permiten el manejo de transacciones diarios del negocio. Las tareas que son ejecutadas en el servidor de data warehouse dedicado precisan de una alta performance para manejar las numerosas agregaciones, clculos y consultas.

Data sourcesPueden ser D.B operacionales, datos histricos (archivados en cintas), datos externos (por ejemplo de Internet o de alguna empresa proveedora de Mercado) o informacin de algn data warehouse ya existente. Las fuentes de datos pueden ser DB relacionales, pueden estar en diversas plataformas o pueden tener informacin estructurada como tablas u hojas electrnicas o informacin no estructurada tal como archivos planos de texto o imgenes y otras informaciones multimediales. Documento traducido de: The IBM Business Intelligence - Professional Certification Program



Proyectos de Sistemas de Informacin GerencialExtraccion / PropagacinEs el proceso de agrupacin y recojo de datos de diversas fuentes y diversas plataformas para trasladarlas al data warehouse. La extraccin de datos es un proceso selectivo para importar informacin relevante para toma de decisiones al data warehouse. Data extraction / data propagation es mucho mas que un proceso de reflejo o copia de datos de una DB a otra. Dependiendo de la tcnica este proceso puede ser: Pulling (Extraccin) o Pushing (Propagacin)

Transformacin / limpiezaLa transformacin de datos involucra recodificaciones de informacion a traves de tablas de mapeo (ejemplo: Cambiar 0 para mujeres y 1 para hombres en el campo de genero). Tambien implica resolucin de reglas de negocio ocultas en los campos de datos como por ejemplo los numeros de cuenta. La transformacin ocurre en el proceso de poblacin (carga), usualmente en mas de 1 paso. En los primeros pasos del proceso, la transformacin es usada mas para consolidar los datos provenientes de las diferentes fuentes de informacin y luego en los pasos posteriores los datos son acomodados de acuerdo a los anlisis del problema o herramientas del proceso. El Data warehousing cambia los datos en informacin, de otro forma el cleansing asegura que el data warehouse tendr informacin valida, til y significativa. Data cleansing tambin puede ser descrita como la estandarizacin de datos.

Data refiningRepresenta la creacin de sub. reas en el data warehouse de la empresa, la cual tiene un formato multidimensional o relacional para optimizar la performance OLAP. La siguiente figura muestra donde esta ubicado este proceso dentro de la arquitectura BI. El pequeo nivel de informacin de el star schema requiere ser agregado, sumariado y modificado para requerimientos especficos. Este proceso de refinacin de datos generan data marts que: Crean una sub rea de datos en el star schema. Crea campos calculados / campos virtuales. Sumariza la informacin. Agrega la informacin.



Este nivel en la arquitectura data warehouse es necesario para mejorar la performance de consulta y minimizar la cantidad de datos a transferir en la red para la consulta del usuario o herramienta de anlisis. Cuando se habla de transformacin / depuracin (limpieza), hay 2 formas de obtener los resultados. Estas son: Data aggregation: Cambia el nivel de granularidad en la informacin. Ejemplo: Los datos originales son almacenados diariamente, el data mart solo contiene valores semanales. As la agregacin de datos origina menores registros. Data summarization: Agregar valores en ciertos grupos de informacin. Ejemplo: El proceso de refinamiento genera registros que contienen los ingresos e un grupo de productos, generando mas registros.

Modelo fsico de Base de DatosEn BI hablar del modelo fsico de base de datos es hablar sobre modelo relacional o multidimensional de base de datos. En la siguiente figura se muestra la diferencia entre estos 2 modelos de datos fsicos.



Ambas arquitecturas puden ser seleccionadas para crear data marts departamentales, pero la manera de acceder a los datos en la DB es diferente: Para acceder a datos en un modelo de DB relacional, pueden ser usados mtodos de acceso comn como SQL o productos middleware. DB Multidimensionales requieren rutinas APIs especializadas para acceder a la arquitectura de base de datos usualmente propietaria.

Modelo de base de datos lgicoCuando se habla de BI el modelo logico mas comunmente usado es el Star-Join Schema. El StarJoin Schema consiste de 2 componentes que se muestran en la siguiente figura: Fact tables Dimension tables



La siguiente son las definiciones de los componentes del Star-Join Schema: Fact Tables que estamos midiendo? Contiene la informacin a nivel de transacciones de la empresa que es de inters para una aplicacin particular. En anlisis de mercado por ejemplo: son los datos bsicos de transaccin de ventas. Las Fact Tables son de grandes dimensiones con millones de registros, principalmente numricos. Dimension Tables "Para que estamos midiendo?" Contiene informacin descriptiva y son de menor tamao en comparacin con las Fact Tables. En una aplicacin de anlisis de mercado, por ejemplo, fact tables tpicas pueden incluir periodo de tiempo, regiones de mercado, tipos de productos....

Informacion de MetadataMetadata estructura la informacin en categoras, tpicos, jerarquas, grupos ...etc dentro del data warehouse. Es utilizada para obtener informacin sobre los datos dentro de un data warehouse. "Subject oriented", basadas en abstracciones de entidades reales del mundo como Proyectos, clientes, empresas... Define la manera en que los datos transformados son interpretados ('5/9/99' = 5th September 1999 or 9th May 1999 British or US?). Proporciona informacin sobre datos relacionados en el Data Warehouse. Estima tiempos de respuestas mostrando los registros procesados en una rutina de consulta. Mantiene campos calculados y formulas pre calculadas para evitar malas interpretaciones.



La perspectiva del que administra el data warehouse es que un metadata representa un recipiente completo de documentacin de todos los eventos, contenidos y procesos de un data warehouse frente a la perspectiva del usuario final de que es un camino hacia la informacin dentro del data warehouse.

ODS Fuente de datos operacionalesLos datos operacionales (ver figura) pueden ser definidos como un conjunto actualizable de datos integrados empleados para la toma de decisiones tcticas en la empresa. Estas contienen data en vivo, no fotografas e informacin histrica mnima que debe ser guardada.



Algunas caracteristicas de los Operational Data Store (ODS): Un ODS es orientado a temas (subject oriented): Esta diseado y organizado alrededor de los mas importantes topicos de una corporacion, tales como clientes o productos. No son organizados en base aplicaciones o funciones especificas, tales como ingreso de ordenes o cuentas por cobrar. Un ODS es integrado: representa informacin integrada de data orientada a temas. Si el topico cliente esta incluido, entonces toda la informacin de clientes de la empresa es considerada como parte del ODS. Un ODS tiene valor actual: Refleja informacin valida de sus sistemas fuentes propietarios. El ODS no deberia contener fotografias multiples de la situacin de la empresa con respecto a lo que se define como valor actual. Esto es que si el valor actual es definido por la informacin de un periodo contable, el ODS no debe incluir informacin de mas de un periodo contable. Un ODS es volatil: Ya que la informacion de un ODS tiene valor actual, esta sometida a cambios de acuerdo a la frecuencia definida en el periodo de anlisis. Asi idnticas consultas realizadas en distintos tiempos mostraran diferentes resultados debido a que los datos son cambiados. Un ODS es detallado: La definicion de detallado depende del problema de negocios que esta siendo resuelto por el ODS. La granularidad de los datos en el ODS puede o no puede ser igual a aquella en el sistema operacional de datos.


Proyectos de Sistemas de Informacin GerencialData martLa siguiente figura muestra donde el data mart se ubica dentro de la arquitectura BI. El propsito del data mart puede definirse de la siguiente manera: Almacena informacin pre - agregada Controla el acceso del usuario final a la informacin. Proporciona un rapido acceso a la informacion para requerimientos analiticos especificos o grupos de usuarios. Representa la vista del usuario final y la interface de datos del data warehouse. Crea vistas de datos multidimensionales / relacionales. Ofrece capacidades de analisis segmentados de la informacin. El formato de database puede ser multidimensional o relacional.

Herramientas de anlisis y presentacinDesde la perspectiva del usuario final, la herramienta de presentacin es el mas importante componente de la arquitectura BI. Categoras To find the adequate tools for the end users with information requirements, the assumption can be made that there are at least four user categories and the possibility of any combination of these categories. El "poder del usuario" Documento traducido de: The IBM Business Intelligence - Professional Certification Program

Proyectos de Sistemas de Informacin GerencialUsuarios que son ansiosos y capaces de manejar herramientas de anlisis mas o menos complejas para crear reportes. Estos usuarios tienen un buen entendimiento de la estructura del data warehouse, de las interdependencias de los datos en el data warehouse. El "usuario no frecuente " Este grupo de usuarios consiste en personas que no estn interesadas en los detalles del data warehouse pero que estn interesados en tener acceso a la informacin en cualquier momento. Estos usuarios participan en las actividades diarias de la empresa y no tienen el tiempo ni la necesidad de trabajar intensamente con la informacin del data warehouse. Su capacidad de manejar reportes o herramientas de anlisis es limitada.

Usuarios que requieren informacion estatica Este grupo de usuarios tiene un especifico interes en obtener informacion en un intervalo especifico de tiempo, como por ejemplo: "Debo tener este reporte resumen de calidad cada viernes a las 10.00 AM como requisito para las reuniones semanales y para propsitos de documentacin. Usuarios que requieren reportes especiales dinmicos y capacidades de anlisis. Tpicamente este es un analista de negocios. Toda la informacin en un data warehouse puede ser importante para estos usuarios al mismo tiempo. Su enfoque esta dirigido a las capacidades de performance y drill-down para segmentar la informacin desde distintas perspectivas en cualquier momento de tiempo. Los usuarios requieren diversas soluciones o herramientas de front-end pero todos pueden acceder a la misma arquitectura de data warehouse. Tambien los diferentes niveles de habilidades requieren diferentes formas de visualizacin de los resultados, tales como grficos de alto nivel de presentacin o tablas para anlisis posteriores.


Proyectos de Sistemas de Informacin Gerencial Captulo 3. Un proyecto de Inteligencia de NegociosA simple vista uno puede esperar que los proyectos de BI sean muy similares a otros proyectos de TI, con las tipicas etapas de requerimientos, anlisis, diseo, desarrollo, pruebas, instalacin, produccin y mantenimiento. Bsicamente esto es verdad sin embargo existen algunas caractersticas en los proyectos de BI que los distinguen de los dems. Es muy importante que todas las areas del negocio esten involucradas en el proyecto, ya que los analistas del negocio accesaran directamente a los modelos de datos, sin ninguna aplicacin que oculte la complejidad del modelo (como sucede en los sistemas OLTP tradicionales). Para facilitar que los analistas del negocio puedan navegar y manipular el modelo, la estructura de la solucion data mart debe ajustarse a su percepcin de los objetos y procesos del negocio. Esto requiere que los especialistas en el Negocio y los especialistas en IT trabajen juntos. Diferencias culturales entre las reas de Negocios e IT pueden influenciar mas de lo usual en el proyecto. Un proyecto de BI requiere de diversas habilidades y recursos que pueden estar dispersas en la empresa. Algunos de estos recursos pueden no estar disponibles y debern ser adquiridos del exterior (consultores, tcnicos y especialistas), los cuales debern integrarse al equipo de la empresa ya que desde el punto de vista tcnico un proyecto de BI es un proyecto de integracin de sistemas. Normalmente mas de una plataforma interviene en el proyecto y debe negociarse con diversos proveedores de herramientas de software, desarrollar diversas interfaces de integracin con sistemas propietarios y cliente/servidor y soluciones en tecnologa web. La efectiva negociacin y coordinacin con estos agentes es una de las claves del proyecto. Los requerimientos de los proyectos de BI son usualmente confusos e incompletos. La capacidad de absorber nuevos requerimientos durante el desarrollo del proyecto debe ser alta ya que el usuario reacciona y visualiza las soluciones cuando ve los primeros modelos preliminares. Esta es la razn por la que las soluciones de BI deben ser iterativas y diseadas para el cambio. Cada rea del negocio debe ser tratada separadamente, para acortar el ciclo de entrega (no mayor de 6 meses por cada rea) y proporcionar un mayor valor al negocio. Se comienza con la fase piloto, y se continua trabajando en ciclos de iteracin pequea con mejoras continuas de la solucin con el objetivo de entregar valor a los usuarios a travs del proyecto y buscando alinear la solucin los mas posible con el negocio. Luego selecciona la siguiente rea de la empresa y nuevamente delimita los alcances del proyecto por no mas de 6 meses. No intente incorporar todos los aspectos del negocio en un solo modelo. Los proyectos de Inteligencia de Negocios tienden a ser nter departamentales. As aunque solo sea cubierta un rea de negocio dentro del proyecto las definiciones del modelo de negocio y reglas del negocio deben ser estandarizadas para ser comprendidas a nivel de la empresa y deben ser consistentes para permitir una reutilizacin posterior. Este aspecto puede llevar a largas discusiones sobre los alcances y sobre como es visto el negocio y como es interpretado por las diferentes reas del negocio. El gerente de proyecto de Inteligencia de Negocios debe asegurarse que existe un acuerdo formal sobre las definiciones de los entregables (esto es modelo de datos, reportes y el catalogo de metadata).


Proyectos de Sistemas de Informacin GerencialLas soluciones BI deben consolidar informacin de muchas fuentes de datos y de distintos niveles de la empresa. La planificacin para el sistema de poblamiento que transforma los datos fuentes en informacin dentro del contexto del negocio debe considerar los aspectos de calidad que normalmente son descubiertos durante este proceso de poblamiento. El proceso de asegurar la calidad de datos de modo que estos sean 100% correctos, significativos y claros puede ser un proceso complejo y que tome bastante tiempo. Sin embargo este es un proceso critico que debe ser revisado y aprobado por los analistas del negocio. Una de las razones mas comunes en el fracaso de los proyectos de Inteligencia de Negocios es la falta de validez en los resultados del anlisis debido a los problemas de calidad de datos o interpretaciones ambiguas.

Quienes conforman el equipo de BI?El numero de personas para realizar una tarea depende de la organizacin y de los alcances del proyecto de Inteligencia de Negocios.

Equipo de Proyecto del NegocioEl equipo de proyecto son las personas mas involucradas en obtener mayor valor al negocio con la solucin a desarrollar. Los miembros del equipo de proyecto conducen el proyecto ya que son los usuarios mas importantes de la solucin de BI. El equipo de proyecto del negocio define los requerimientos y el alcance del proyecto. Es responsable por que la nueva solucin este alineada con los objetivos de negocios de la empresa, Sponsor En general un Sponsor es un elemento necesario en todos los proyectos y en especial en los proyectos de BI. El sponsor juega un muy importante papel en el proyecto y es la persona que tiene la necesidad de parte de la empresa de implementar la solucin y asimismo la responsabilidad del control financiero del proyecto. El Sponsor tambin es responsable de aprobar los alcances del proyecto y apoyar los compromisos a lo largo del proyecto. El Sponsor tiene la visin de los alcances y beneficios del proyecto y es la persona que debe alentar y apoyar a los usuarios de la empresa. Es critico que el equipo de proyecto mantenga permanente comunicacin con el Sponsor. El Sponsor usualmente designa al Lder de Proyecto que representa a la comunidad de la empresa y trabaja muy cerca del Gerente Tcnico del Proyecto. Lder de Proyecto El lder de proyecto forma parte de la organizacin del cliente. El o ella ser tambin usuario de la solucin y debe ser capaz de tomar decisiones desde una perspectiva de la empresa durante el proyecto. El lder de proyecto tiene un entendimiento claro de los requerimientos del negocio. El trabaja cercanamente al Gerente Tcnico del Proyecto. Usuario final Es muy importante encontrar usuarios que sean abiertos a las nuevas tecnologas. Ellos estaran mas dispuestos a compartir informacin sobre los diferentes procesos y necesidades de la empresa.


Proyectos de Sistemas de Informacin GerencialEquipo de desarrollo del ProyectoEl equipo de desarrollo trabaja estrechamente con el equipo de negocios del proyecto para elaborar una solucin optima que satisfaga los requerimientos del negocio. Gerente Tcnico de Proyecto Profesional con mucha experiencia en estos proyectos. Debe definir a los miembros del equipo de proyecto. Este proceso es critico para el xito del proyecto ya que el personal del proyecto tiene diferentes habilidades y hablan diferentes lenguajes de negocio. Es responsable de coordinar los recursos, administrar las actividades del proyecto, hacer seguimiento al estado del proyecto y definir la estructura de comunicaciones para el proyecto. Debe ser capaz de desarrollar una buena comunicacin y poseer conocimiento tcnico. Debe ser capaz de establecer los vnculos entre la parte tcnica y de negocios del proyecto y debe moverse por todo el ambiente de la organizacin. Arquitecto de soluciones Business Intelligence Esta a cargo de la solucin tcnica del proyecto. Es la persona que conoce las diversas arquitecturas y productos disponibles para disear la solucin. Debe ser capaz de integrar las diferentes plataformas, herramientas y productos en una solucin end-to-end que satisfaga los requerimientos de la empresa y pueda crecer con las nuevas demandas del negocio. El Arquitecto de Soluciones participa en la definicin de los componentes principales de la solucin (the data staging and population subsystem, databases and connectivity, information catalog, warehouse management subsystem, analysis applications and tools, and archiving solution). El controla el trabajo de los diversos especialistas y tcnicos. 3.1.2.3 Business Subject Area Specialist El Especialista Funcional del Negocio debera tener conocimiento de los procesos de negocios, aplicaciones y datos relacionados con la problemtica empresarial. Esta persona debe saber quienes son los recursos claves dentro de la organizacin que puedan definir cuestiones claves de la empresa referidas a definiciones de procesos. Junto con el Arquitecto de Soluciones esta encargado de verificar la calidad de la informacin proporcionada por el sistema. 3.1.2.4 Administrador de Base de Datos En cooperacin con el Especialista Funcional del Negocio el administrador de base de datos sabe donde encontrar y como interpretar los datos fuentes. El conoce la estructura de los datos y sus relaciones y tambin es responsable de la seguridad de la informacin. 3.1.2.5 Especialista de Plataformas El especialista en plataformas se encarga de resolver los problemas de conectividad y acceso a los recursos en los diferentes sistemas propietarios o fuentes que se conectan a la solucin (UNS, NT, etc...). Generalmente el personal de IT de la empresa es designado para estos temas.


Proyectos de Sistemas de Informacin Gerencial3.1.2.6 Especialista de herramientas Muchas herramientas son necesarias emplear en los proyectos de BI para los distintos procesos de extraction, transformation, and cleansing tools para acceder a los datos, para administrar los procesos de poblacin del data warehouse, para desarrollar las consultas y reportes que se precisan y para los procesos OLAP y data mining. El especialista en productos debe saber como implementar cada tipo de herramientas.

3.2 El Proceso de desarrolloEn un proyecto de BI se deben realizar basicamente estas 3 etapas: Infraestructura Datos Applicaciones Infraestructura incluye todas las actividades necesarias para disponer de los elementos tcnicos necesarios para el ambiente de BI. Esto incluye la instalacin e implementacin de nuevo hardware y software la conectividad entre los sistemas propietarios y el nuevo ambiente de BI en la red, as como la configuracin de las bases de datos, la implementacin del subsistema de poblacin de datos y el sistema de administracin. Datos Se refiere a los accesos de datos, mapeo, derivacin, transformacin y agregacin de acuerdo a los requerimientos y reglas del negocio as como la definicin adecuada de los campos de datos en trminos del negocio (metadata). Tambin es referido a las tareas necesarias para asegurar la consistencia y calidad de la informacin transferida al sistema de Inteligencia de Negocios. Aplicacin Incluye la definicin de los requerimientos del negocio, el diseo del modelo, y la implementacin, visualizacin y publicacin de los resultados del anlisis en trminos de consultas, reportes o grficos. La solucin de Inteligencia de Negocios se muestra a continuacin:



Como puede apreciar en el grafico, cada ciclo de entrega de resultados deja mas espacio para que los esfuerzos de desarrollo de aplicacin reuse muchos elementos del ciclo anterior y reduzca el esfuerzo de desarrollo.

Planeando un proyectoLas siguientes son algunas preguntas que deben ser respondidas antes de comenzar un proyecto de BI: 1. Cuales son los objetivos estratgicos de la empresa que la solucin de BI pretende apoyar o alcanzar? La solucin BI debe estar dirijida a apoyar el logro de los objetivos y estrategias de la empresa. 2 Cual es la especifica variable de medicion que sera usada para el calculo del ROI del sistema de BI? 3. Los usuarios claves del data warehouse han identificado y se han comprometido en el exito del proyecto?


Proyectos de Sistemas de Informacin Gerencial4. El proyecto de data warehouse es apoyado por la Gerencia de la empresa? 5. La organizacion tiene un concepto claro de los conceptos y herramientas involucrados en un data warehouse?

3.4 Factores de xito para la solucin BI Delimitar el alcance del proyecto para entregarlo en un mximo de 6 meses. Seleccionar un rea especifica de negocios; no intente resolver todos los requerimientos del negocio en un solo proyecto. Encontrar un Sponsor de parte de la Gerencia de la empresa para el proyecto. Involucrar al Sponsor en el proyecto. Establecer los canales de comunicacin del proyecto. Definir los contenidos y tipos de entregables de el proyecto tan pronto sea posible y con el mayor detalle. Junto con el usuario final validar los resultados de la fase de anlisis (modelo dimensional inicial) frente a la definicin de los entregables. Establecer acuerdos sobre definiciones del negocio para todos los tem dentro de los alcances del proyecto. Validad la calidad y exactitud de la informacin antes de ponerla a disposicin del usuario final. Mantener al usuario final involucrado en el desarrollo del proyecto. Estar preparado para los obstculos culturales y polticos entre los departamentos de la empresa y el rea de IT. Algunos indicadores de exito se detallan a continuacion: 1. Return on investment (ROI). El ROI puede ser alcanzado de diversas maneras como: Menores costos Mejora de la productividad Aumento de los ingresos 2. El data warehouse es utilizado. Estos resultados se miden en base a la cantidad de reportes y consultas que son generados en el data warehouse. Si estos son empleados regularmente entonces esto es un buen indicativo que los reportes se estan usando con ciertos beneficios. 3. El data warehouse es util. Se debe consultar con los usuarios no solo si emplean el data warehouse sino tambin si el uso de esta herramienta a representado un cambio significativo en los procesos de decisiones que realizan. 4. EL proyecto es entregado en los plazos previstos. 5. El proyecto en entregado dentro de los presupuestos establecidos. 6. Existen mejoras en la satisfaccin del usuario. 7. Hay requerimientos adicionales para el data warehouse functions. 8. Objetivos y metas son alcanzados. 9. Los problemas del negocio son resueltos. 10.Son logradas oportunidades de negocio.


Proyectos de Sistemas de Informacin Gerencial3.6 Pasos para la implementacin exitosa de un data warehouse.Para alcanzar el xito en la implementacion de un proyecto de BI debe seguir los siguientes 6 pasos: Definir el proyecto Preparar el proyecto Iniciar la base de datos Explorar la base de datos Implementarla Iterar/Expandir

3.6.1 Definir el proyectoPara definir el proyecto debe realizar las siguientes actividades: 1. Obtener el compromiso de la gerencia corporative y el Sponsoramiento. 2. Definir el nivel de la arquitectura a desarrollar. 3. Sealar las oportunidades. 4. Establecer metas realistas. 5. Desarrollar los niveles del plan de proyecto.

3.6.2 Preparar el proyectoLas tareas involucradas en la preparacion del proyecto son: 1. Definir las tareas a desarrollar (categories principales). Quien y que hace cada persona en el equipo de proyecto. Las actividades habituales son: - Data acquisition - Data Modeling - Operations - Metadata - Tools selection - Support 2. Reunir los requerimientos de alto nivel. Los requerimientos de alto nivel pueden ser separados en de negocios y tecnicos: Requerimientos del negocio - Procesos involucrados - Factores crticos de xito. - Entidades del negocio, atributos y relaciones (jerrquicas, horizontal, etc) - Medidas del negocio - Tipos de usuarios (ejecutivos, nuevos, analistas, desarrolladores) - Presupuesto para el proyecto Requerimientos tcnicos. - Topologa fsica (hardware/software) y configuracion de redes - Topologa lgica - Base de datos fuentes - Aspectos de definicion de base de datos del Warehouse como estructura, transporte, transformacin, depuracin, propagacin de requerimientos etc. 3. Equipo de proyecto de ensamble. - Technical staff (habilidades necesarias) para trabajar como lideres de proyecto, disear e implementar la base de datos warehouse, disear e implementar los data marts y metadata y Documento traducido de: The IBM Business Intelligence - Professional Certification Program

Proyectos de Sistemas de Informacin Gerencialasegurar la performance del SQL Estas personas son usualmente programadores de base de datos, administradores y analistas de base de datos. - Equipo professional de Negocios, especialistas en analisis de requerimientos del negocio. - Corporate sponsors - End user staff

3.6.3 Inicializar la base de datosEste proceso puede ser separado en las siguientes actividades: 1. Acumular los requerimientos detallados de usuarios. Los requerimientos de usuarios son variados dependiendo del tipo de usuario: ejecutivo / analista de negocios / desarrollador ..etc. Cada usuario tiene diferentes habilidades y puede influenciar en forma particular en el diseo de la base de datos. Tambin difieren en las expectativas que tienen con relacin a los resultados del proyecto como performance, frecuencia de acceso, cantidad de datos por acceso, disponibilidad, acceso al metadata...etc. 2. Identificar atributos de transformacin y derivacin. En esta actividad puede ser una buena idea extraer (tener un fotografa) la data operacional en un sistema aislado para poder realizar un anlisis mas profundo de la calidad de la fuente de datos. Los datos deben ser analizados para tener una idea del esfuerzo a realizar cuando se ejecuten: - Limpieza (depuracin) para verificar la validez, veracidad, consistencia y exactitud de los datos. - Mapping / traduccin (cdigos a caracteres) cuando se consolidan distintas fuentes de datos. - Calculos necesarios para agregar datos. - Totalizaciones requeridas. 3. Modelo de facts y dimensiones. Como paso siguiente para inicializar la base de datos, los facts (eventos) y dimensiones deben ser definidos. El equipo involucrado en esta actividad debe conocer bien los datos disponibles, el negocio y los requerimientos de anlisis que deben ser efectuados. A continuacin mostramos un ejemplo de la fact table y la dimension tables.



4. Arquitecturar la base de datos (incluyendo el metadata). El ultimo paso referido al diseo de la base de datos es tomar una decisin sobre la arquitectura del data warehouse. Estas consideraciones cubren aspectos como: la definicin sobre si el data warehouse que ser implementado tendr 1-2-3 niveles de jerarqua as como la decisin si el modelo de base de datos a implementar ser relacional (ROLAP) o multi dimensional (MDD). Este paso termina al disear el modelo del rea de negocio aplicado a la realidad. 5. Disear la infraestructura. Despus que la base de datos a sido diseada necesita considerarse la infraestructura que la soportara. Los aspectos a considerar en este proceso son: - Hardware/software configuracin necesaria para la implementacin. - Metodos de propagacion necesarios. - Frecuencia de propagacin. - Disponibilidad del sistema global 6. Adquirir datos fuentes. La base de datos esta definida, la infraestructura ya esta configurada e implementada, ahora es el momento de definir informacin inicial de prueba. Este proceso deberia incluir a los usuarios finales que deberian seleccionar los datos necesarios. 7. Poblar la base de datos del data warehouse Despues del exito de las pruebas las dimensions tables necesitan ser pobladas. Para esto se deben realizar los siguientes pasos: - Extraccion manual y carga del fact table - Implementar solo las transformaciones necesarias. No se impaciente y no trate de encontrar fallas en todos estos pasos. - Itere en el proceso de carga de datos hasta que la salida sea lo suficientemente limpia para el acceso del usuario final. Documento traducido de: The IBM Business Intelligence - Professional Certification Program



Proyectos de Sistemas de Informacin Gerencial3.6.4 Explorar la base de datosDespus de cargar los datos de prueba en el data warehouse, la base de datos deberia ser explorada para verificar el diseo, utilizacin, etc. Esto ayudar a: Identificar las dependencias de propagacin y preparacin. Monitorear la utilizacion del usuario final, los modelos de acceso y performance. Ajustar la base de datos y herramientas para una performance optima. Planificar y programar procesos de actualizacion. Definir el monitoreo y los procedimientos de control. Definir los metodos de backup y recuperacion. Disear planes y tecnicas para recuperacion y archivamiento. Crear el plan de control y seguimiento para la implementacion total.

3.6.5 Implementar la solucinLa implementacin final de la solucin global requiere el desarrollo de las siguientes actividades: 1. Preparar el ambiente de produccin. La solucin debe ser probada en el siguiente orden: a. Proceso de adquisicin / propagacin b. Actualizacin / poblacin del Warehouse c. Ambiente de consulta e instalacin de herramientas del usuario final 2. Entrenamiento a los usuarios. 3. Definir e iniciar el proceso de soporte. 4. Moverse al ambiente de produccin.

3.6.6 Iterar para mejorar el warehouseUna vez implementada la solucin global se debe permanentemente revisar la solucin para detectar futuras expansiones, mejoras o el desarrollo de nuevos proyectos. Las acciones que se deben desarrollar para esto son: Continuar con el monitoreo del uso del data warehouse. Iniciar la definicin de requerimientos para nueva informacin.

3.7 Midiendo los resultados del data warehousePara determinar el xito del proyecto debemos monitorear permanentemente el proyecto. Las mediciones pueden ser objetivas o subjetivas. Alguna test de verificacin pueden representar efectos negativos en la estabilidad o performance del sistema. Algunas mediciones son costosas, requieren personal capacitado y equipos para llevarlos a cabo. Dependera de la habilidad del gerente de proyecto para seleccionar los tests de pruebas que seran implementados. Las mtricas que se pueden implementar son: 1. Calidad funcional La funcionalidad del data warehouse satisface los requerimientos del usuario? El data warehouse proporciona la informacin necesaria para el desarrollo del trabajo de los usuarios? 2. Calidad de los datos Si los datos del data warehouse no son fiables o utiles, los usuarios los rechazaran. Hay 2 medios para medir la calidad de los datos: - Preguntar a los usuarios si sus reportes son exactos. - Use un software que proporcione un diagnostico de la calidad de los datos. 3. Performance de la computadora Hay 4 indicadores de performance que deberiamos considerar: - Tiempo de respuesta de las consultas - Tiempo de respuesta de los reportes Documento traducido de: The IBM Business Intelligence - Professional Certification Program

Proyectos de Sistemas de Informacin Gerencial- Tiempo de carga / actualizacin del data warehouse - Recursos de maquina utilizado 4. Performance de red La capacidad de la red de atender el trafico de las comunicaciones impactara directamente en el tiempo de respuesta. Software de red mide la carga de las lneas, el trafico y otros aspectos de red. 5. Satisfaccin del usuario Los usuarios deben ser peridicamente encuestados para medir el grado de satisfaccin del sistema de parte del usuario final. 6. Numero de consultas Algunas herramientas de monitoreo proporcionan indicadores sobre el numero de consultas realizadas por cada departamento y cada persona de la empresa. 7. Que datos son consultados Muchas empresas tienen datos que nunca son accesados. Esto se debe a la mala o incompleta determinacin de los requerimientos o al cambio de la forma pensar de los usuarios. 8. Satisfacer los acuerdos sobre los alcances de cada una de las etapas del proyecto 9. Beneficios logrados Antes del inicio del proyecto defina los beneficios tangibles e intangibles. Luego de la implementacin usted requiere medir estos beneficios tangibles y hacer una medicin aproximada sobre los beneficios intangibles. Ya que los beneficios no se alcanzan inmediatamente despus de la implementacin del proyecto se deber esperar por lo menos 2 meses para efectuar estas mediciones. Ningn proyecto es perfecto al inicio. Siempre hay oportunidades para mejorar la solucin. En muchas casos estas mejoras deben ser inmediatas para asegurar la supervivencia del sistema.


Proyectos de Sistemas de Informacin Gerencial Captulo 4. BI data sourcing/movementTodas las aplicaciones de BI como un data warehouse, OLAP, y Data Mining, entregan datos limpios y consistentes. Estos datos son recogidos de distintos sistemas fuentes y almacenados en un data warehouse. Este capitulo toca aspectos del traslado de datos.

4.1 Replicacin de datos - definicinEn BI la replicacin de datos tiene las siguientes caractersticas: Control la replicacin de datos asegura consistencia de resultados independientemente de como los datos fueron copiados o manipulados. Administracin Capacidad de elaborar y reutilizar funciones. Flexibilidad Permite la mezcla y cruce de funciones y tcnicas cuando son necesarias. Facilidad de mantenimiento rpido y de costo eficiente. Integracin del metadata proporciona vnculos al metadata para los datos fuentes y destinos. Performance ofrece mantenimiento para grandes fuentes de datos para una variedad de niveles de sincronizacin. Variedad de fuentes soporta una amplia variedad de fuentes de datos. Contexto de negocios mantiene las relaciones establecidas en los procesos de negocios cuando los datos son replicados.

4.2 Proceso de replicacin de datosLos pasos en el proceso de replicacion de datos son: 1. Identificar la fuente de datos. 2. Identificar el destino de los datos. Frecuentemente el destino de los datos debe ser definido en el proceso de replicacion. Idealmente la estructura de los datos destinos deben ser definidos en el proceso de modelamiento. Sin embargo en algunas oportunidades cuando el proceso de replicacion es usado para poblar ciertos tipos de datos derivados la definicin de los datos destinos pueden ser parte del proceso de replicacin. 3. Crear un diseo entre fuente y destino. Una vez definido los datos fuentes y destino se deben definir el algoritmo de transformacin de los datos fuente a destino. Se deberan considerar los diversos tipos de formatos de datos existentes de los mas simples como EBCDIC (extended binary-coded decimal interchange code), ASCII (American standard code for information interchange), hasta los mas complejos. 4. Definir el modo de replicacin. Hay 2 mtodos de replicacin de datos: refresh y update. El modo Refresh implica traslado de datos de la fuente al destino Update identifica y traslada solo los datos modificados de la fuente al ambiente destino. Es importante definir al inicio el modo de replicacin que se efectuara. 5. Programar el proceso de replicacin. El proceso de replicacin puede realizarse en intervalos definidos por el usuario final que pueden ser diarios, semanales, mensuales, etc., y estos deben estar en capacidad de ejecutarse en forma automtica. 6. Capturar los datos necesarios de la fuente. Es el primer paso del proceso de replicacin. Se realiza de acuerdo a la programacin de actividades y sin intervencin humana posterior. 7. Transferir los datos capturados de la fuente al destino. El proceso de transferencia debe soportar heterogeneos ambientes de datos donde los datos fuente y destino pueden residir en distintos tipos de maquinas, en diferentes formatos y en diferentes ubicaciones.


Proyectos de Sistemas de Informacin Gerencial8. Transformar los datos capturados de acuerdo al diseo definido. La transformacin de datos se puede dar en la fuente o destino o puede estar distribuida. 9. Aplicar los datos capturados al destino. Los datos se pueden aplicar al destino de 2 formas: - Datos ingresantes reemplazan los datos existentes. - Datos ingresantes se agregan a los datos existentes. 10.Confirmar el xito o fracaso de la replicacin. El fracaso del proceso de replicacin puede darse en cualquier etapa del proceso y debe ser inmediatamente comunicada a la persona apropiada. 11.Documentar los resultados de la replicacin en el metadata. Proporciona informacin al usuario final de los datos actuales resultados de la replicacin. 12.Mantener las definiciones de fuente, destino y mapeo. Es necesario documentar el proceso de replicacin para reflejar cambios en la fuente de datos, nuevos requerimientos en los datos destino y nuevos transformaciones de datos.

4.3 Captura una introduccinCaptura es un componente de la replicacin de datos que interacta con los datos fuente para obtener una copia de todo o una parte de los datos, de un registro o de algn cambio contenidos en la fuente (ver figura).


Proyectos de Sistemas de Informacin GerencialEn general no se necesitan todos los datos de la fuente. Aunque todos los datos pueden ser capturados y los datos no deseados pueden ser filtrados es mas eficiente capturar solo el area requerida. La captura de tal segmento o area sin referencia a ninguna dependencia de tiempo de la fuente es llamada Captura estatica (static capture). Ademas, cuando las bases de datos cambian con el tiempo, nosotros requerimos capturar la historia de estos cambios. En algunos casos repetir el proceso de Static Capture puede ser suficiente. Sin embargo en muchos casos debemos capturar los cambios actuales que han ocurrido en la fuente. Ambas consideraciones de operacin y la necesidad de transformar datos periodicos o semi periodicos en datos periodicos guia este requerimiento. Este tipo es llamado captura incremental.

4.3.1 Static captureStatic capture esencialmente toma una foto de los datos fuente en un punto del tiempo. Esta fotografia puede contener todos los datos de la fuente, pero usualmente solo contiene una area o seccion de los datos, Static capture ocurre en diversos casos, aunque no estan comun como los procesos mas complejos de capture incremental, Ejemplos son: Static capture ocurre la primera vez en que los datos de un area en particular de un sistema operacional deben ser agregados a un data warehouse, en la cual el sistema operacional mantiene una historia completa de los datos y del volumen de datos. En estos casos, casi nunca es necesario mover los datos de una fuente particular al ambiente destino. Muchos campos en la base de datos operacional solo existen por razones tcnicas. En los sistemas propietarios puede haber datos redundantes y/o obsoletos, asi que estos datos son irrelevantes para las tareas de administracin y no requieren ser capturados.

4.3.2 Incremental captureIncremental capture es el mtodo de captura de un registro de cambios que se producen en el area de datos fuente. Incremental capture reconoce que la mayora de datos tiene una dependencia del tiempo, y que por tanto requiere un mtodo eficiente para manejar esta dependencia. El volumen de cambios en un rea de datos casi siempre depende de una magnitud menor al volumen total. As una captura incremental de los cambios en los datos en vez de una captura esttica del rea de datos resultantes completos es mas eficiente. Captura incremental debe recoger los cambios de tal forma que al aplicar estos cambios en el destino construya una representacin valida de los datos en el ambiente. Sin embargo es claro que la captura incremental es mucho mas compleja que la captura esttica.

4.3.3 Captura retrasada (Delayed capture)Captura retrasada ocurre en momentos predefinidos y no con las ocurrencias de cada cambio. En los datos peridicos este comportamiento produce un registro completo de los cambios en la fuente. En los datos periodicos y semi periodicos sin embargo los resultados en ciertas circunstancias puede ser un registro incompleto de cambios que han ocurrido. Estos problemas aumentan en el caso de las anulaciones y mltiples actualizaciones en los datos temporales y semi temporales.


Proyectos de Sistemas de Informacin Gerencial4.3.4 Tcnicas de captura de datosAntes de hablar de las tcnicas de captura de datos debemos distinguir entre los 2 metodos de captura: Incremental y esttico. Aqu discutiremos el tema con mas detalle. Static capture es la tcnica mas sencilla; su funcionalidad basica esta en el subconjunto de datos capturados. Incremental capture, sin embargo no es un mtodo sencillo. Esta se puede dividir en 5 diferentes tcnicas como se muestran abajo. Las primeras 3 son de captura inmediata los cambios en la fuente de datos son capturados inmediatamente despus de el evento que origina el cambio en los datos fuentes. Captura inmediata garantiza la captura de todos los cambios producidos en el sistema operacional independientemente si los datos operacionales son temporales, peridicos o semi peridicos. 1. Application-assisted capture depende de la aplicacin que actualiza los datos operacionales para almacenar los datos actualizados tambin en una manera mas permanente. 2. Triggered capture depende del administrador de base de datos para almacenar los datos actualizacdos en una manera mas permanente. 3. Log/journal capture depende del diario del administrador de base de datos para almacenar los datos cambiados. Debido a la capacidad de capturar un registro completo de los cambios en los datos fuente estas 3 tcnicas (techniques 2 - 4) son usualmente empleadas en la captura de datos incremental. Sin embargo en algunos ambientes, las limitaciones tcnicas impiden su uso. En estos casos algunos de las 2 tecnicas de captura retrasada pueden ser empleadas: 4. Timestamp-based capture selecciona los datos cambiados en el momento de impresin (timestamps) proporcionado por la aplicacin que da mantenimiento a los datos. 5. File comparison compara las versions de los datos para detectar cambios.

4.4 Depuracin Limpieza (Cleansing)Los consultores de negocios remarcan que los datos son el activo mas importante de una empresa. Es utilizada y reutilizada en diversas aplicaciones de inteligencia de negocios para apoyar el desarrollo de anlisis sofisticados y la toma de decisiones que proporcionan mayor competitividad a la empresa. Pero el valor de los datos es claramente dependiente de la calidad de los mismos (ver siguiente figura para un ejemplo de datos sucios). Decisiones basadas en datos dbiles y poco consistentes pueden generar importantes costos para la empresa. De acuerdo a la empresa internacional: INFORMATION IMPACT International, Inc., Esta demostrado que los datos inconsistentes y de baja calidad pueden originar hasta un 20% en perdidas de ingresos para el negocio y puede generar serios problemas operacionales. Considerando este factor es muy importante para la corporacin depurar (limpiar) los datos antes de almacenarlos en un almacenamiento secundario, como el data warehouse, y usarlo como elemento en el proceso de toma de decisiones.

4.4.1 Efectuar la valoracin de la calidad de los datosCualquier persona que investiga sobre la calidad de los datos rpidamente se da cuenta que la calidad de los datos es un factor critico de xito en un data warehousing. Los expertos aconsejan tener una valoracin de la calidad de los datos reunidos, acumulados en un data warehouse o data mart. Lo curioso es que muchos Gerentes de Tecnologa intentan obviar esta fase de depuracin y valorizacin de calidad de los datos. Una de las razones principales para esta omisin es el tiempo y el costo impredecible que se genera de esta fase de depuracin y limpieza.


Proyectos de Sistemas de Informacin GerencialEn un reporte del sector de Administracin de Datos titulado "Data Integrity and Cleansing," Curt Hall escribe De lejos el los costos operativos mas grandes inesperados en la implementacion de un data warehouse son aquellos de limpieza y depuracin de datos asociados a los procesos de carga. El estima que hasta el 70% del esfuerzo es debido a la depuracin, limpieza y transformacin de datos.

4.4.1.1 Que son los datos sucios Dirty Data ? Ken Orr, coinventor de la metodologa de diseo Warnier-Orr Design y experto en data warehouse dice: "el Metadata puede ser definido como una descripcin de que es lo que se desea en sus campos de datos." El problema puede vincular no solo los datos sino el metadata (data referida a los datos informacin de los nombres de campos, nombres de archivos, datos, etc). Algunos ejemplos de este problema son: Informacin propietaria oculta en campos de forma libre (Legacy Info buried in freeform fields): Como determinara y extraer relaciones de entidades? Distintas claves de distintas fuentes de datos que identifican la misma entidad sern un problema. El tener mltiple claves que relacionan a algunos datos pero no a todos en forma correcta es peor que no contar con claves. La siguiente figura muestra un ejemplo de una fuente de base de datos con campos de datos en formato libre.



Falta de estndares para los sistemas propietarios Formatos, estructuras, atributos y definiciones de cdigos ilimitados son almacenados dentro de los campos con las mismas etiquetas creando una pesadilla para el proceso de consolidacin y para el traslado de los datos al warehouse. La Figura siguiente muestra un ejemplo de 3 diferentes fuentes de datos, que en apariencia proporcionan la misma informacin.



4.4.2 Tcnicas de depuracin de datosEl primer paso para la depuracin de los datos es el anlisis de los datos del sistema operacional para determinar que tipo de inconsistencias o discrepancias pudieran presentarse en el proceso de extraccin, transformacin y carga en el data warehouse (ver Figura).



4.4.2.1 Data conditioning Data conditioning y la estandarizacion es necesaria para mantener por ejemplo cierto rangos permitidos para algunos campos. Esto puede realizarse mejor empleando herramientas de reingeniera que realicen las siguientes tareas: Parsing - anlisis Data typing Tipeo de datos Pattern analysis Analisis de modelos Business rule discovery descubriendo reglas de negocio 4.4.2.2 Integracion de datos La integracin de datos puede incluir la unin y eliminacin de datos de las diferentes fuentes. La remocin de datos redundantes puede ser realizada con la ayuda de las siguientes tcnicas: De-duplicacion (merge/purge) Matching (integracion por entidad) Householding (integracion por grupos)


Proyectos de Sistemas de Informacin Gerencial4.5 Transformacin de datosEl componente de transformacion del proceso de replicacion de datos se situa entre la captura y la aplicacion. Acepta datos en el formato de la fuente a traves de los componentes de captura y los transforma al formato que el apply usara en el destino.

4.5.1 Funciones de transformacinLa transformacin incluye un amplio y variado rango de funcionalidades. Para distinguir entre diferentes tipos de funcionalidad se requiere descender a niveles tcnicos de definicin de requerimientos. La clasificacion de esta funcionalidad y la determinacin de su complejidad tcnica depende de 2 factores: La relacin entre el numero de registros de entrada y de salida. Los tipos de clculos realizados con los campos dentro de un registro. De las consideraciones de esta mezcla de requerimientos tcnicos y de negocios, aparecen 6 funciones de transformacin: Seleccin Separacin / concatenacin Normalizacin / de normalizacin Agregacin Conversin Enriquecimiento - Enrichment Las primeras 4 funciones representan diferentes formas en las que las entradas y salidas se relacionan a nivel de registro, mientras que las 2 ultimas operan a nivel de campos. 4.5.1.1 Seleccion Seleccin (o subsetting) es el proceso de separacion de datos en base a criterios predefinidos. La seleccin es la forma mas simple de transformacin, operando en un registro de entrada y generando por lo menos un registro de salida por cada registro de entrada. La seleccin es frecuentemente incluida como parte del componente de captura. Sin embargo en algunas circunstancias la seleccin puede desarrollarse en pasos separados a la captura. Por ejemplo la estructura tcnica de la fuente de datos puede hacer difcil seleccionar la sub rea solicitada. Similarmente si una sub rea de la fuente de datos ha sido capturada y requiere posteriores sub divisiones para alimentar mltiples destinos con diferentes sub reas de datos, entonces es necesario posteriores selecciones como parte de la fase de transformacin, Entidad, atributo y ocurrencia son las distintas dimensiones de la seleccin. La definicin de estas dimensiones son: Dimensin Entidad la forma mas simple de subdividir los datos es por entidad. En este caso toda la informacin pertinente de un tema es seleccionada para la captura. La salida es una imagen de los contenidos totales de la entidad, frecuentemente en una estructura mas simple que la de la fuente.


Proyectos de Sistemas de Informacin GerencialEn DB2 SQL, la seleccin a travs de la dimensin entidad equivale a: SELECT * FROM CUSTOMER_FILE Dimensin atributo En esta dimensin algunos atributos son seleccionados de todas las ocurrencias de los datos para una entidad seleccionada. En DB2 SQL, seleccionando a travs de esta dimensin equivale a: SELECT NAME, CITY, STATE FROM CUSTOMER_FILE Dimensin Ocurrencia En general las ocurrencias son basadas en el contenido de uno o mas campos en cada registro. En DB2 SQL, la seleccin a travs de esta dimensin equivale a: SELECT * FROM CUSTOMER_FILE WHERE CITY = 'New York' 4.5.1.2 Separacin / concatenacin Separacin divide la informacin referida a un item de negocio en un numero de registros separados basados en la clave de negocios. La sub divisin es realizada para simplificar la vista del usuario final que mantiene distintos usos de los datos o por razones de seguridad. Concatenacin es lo inverso de la separacin, es decir la unin de informacin en base al mismo item. El proceso de concatenacin permite a un registro de entrada extenderse con mas detalle sobre un tema primario. Por ejemplo diferentes tipos de informacin de producto pueden ser almacenados y mantenidos en diferentes base de datos. Ejemplo: Distintos tipos de embalaje y tamaos para los productos son almacenados en el sistema de produccin mientras los precios son almacenados en el sistema de marketing. Estos son concatenados en base al codigo de producto como la clave en el data warehouse. 4.5.1.3 Normalizacin / denormalizacin Normalizacin implica la divisin de un registro simple de entrada en mltiple salidas. Un ejemplo de normalizacin es tomar un registro de inventario de un producto (indexado en base al cdigo de producto) que contiene una descripcin del producto y los detalles de donde son almacenados. La normalizacin divide el registro en 2 partes, una parte contiene los datos del producto y los ndices del cdigo de producto, La otra contiene datos de la ubicacin de los stocks y los ndices de los cdigos de ubicacin. Ahora para mantener la relacin entre el producto y las ubicaciones de stock uno de los registros de salida debe contener la clave del otro registro (como relacin de clave fornea), de otra forma un tercer registro de enlace es necesario. De normalizacin es lo opuesto a lo anterior. Por ejemplo, los nombres y direcciones de un archivo de clientes pueden agregarse a un registro de ventas cuyos datos de entrada solo contiene el cdigo del cliente. La informacin contenida en esta rea de datos no esta confinada a una simple rea de datos referenciada, sino que puede existir diversos grupos repetidos con estos datos. Este es un registro transformado muchos-a-uno, que toma los registros de 2 o mas tablas normalizadas y las une en base a sus claves en un registro para mejorar la performance del sistema.


Proyectos de Sistemas de Informacin Gerencial4.5.1.4 Agregacin La agregacin es el proceso de transformacin que toma datos de un nivel de detalle a un nivel consolidado sumariado. Matemticamente la agregacin consiste del agrupamiento de registros en base a criterios especficos de totalizacin, promedio o aplicacin de cualquier otra formula estadstica a un grupo de datos resultante. Ejemplos: Suma de ventas en periodos de tiempo (diario, seminal, mensual) Suma de gastos por rea geogrfica Promedio de productividad por unidad organizacional o otro agrupamiento La funcin de agregacin puede operar solo en registros con idnticas estructuras. La siguiente figura muestra un ejemplo de esquema de agregacin:


Proyectos de Sistemas de Informacin Gerencial4.5.1.5 Conversion at field level La conversin opera al nivel de campos opuesta a la agregacin mencionada anteriormente que opera al nivel de registro, Su funcin es cambiar los datos de una forma a la otra. El proceso se genera de un simple campo de datos y aplica una regla para transformarlo en otro contenido. Esta regla puede ser un algoritmo o una tabla repetitiva. Conversin algortmica: Todo los procedimientos lgicos en la conversin algortmica pueden ser incluidos en el proceso de conversin. Ejemplos de este tipo de conversin son: Conversin de textos con letras mezcladas a mayscula o minsculas Conversin entre sistemas de medidas, como por ejemplo del sistema imperial al sistema mtrico Conversin de cdigos a descripciones, cuando el rango de posibles valores es pequeo y no modificable, como por ejemplo m a masculino o f femenino Conversin por ciclo de repeticin: La conversion que no puede ser expresada por un algoritmo simple emplea en su lugar una tabla de repeticin (lookup table). Este metodo proporciona un alto grado de flexibilidad en la relacion entre las entradas y salidas sobre todo en la capacidad de extender la relacion a traves del tiempo. Ejemplos son: ASCII a EBCDIC y similares sistemas de conversion de paginas Conversion de codigos a descripciones con un gran rango de codigos open-ended, como los codigos de paises ISO (International Standardization Organization) equivalentes a sus nombres de paises. 4.5.1.6 Enriquecimiento - mejora El enriquecimiento en una funcion de transformacion que combina los datos de 2 o mas campos en uno o mas registros para crear un nuevo campo o campos en el registro de salida. El enriquecimiento se clasifica en: Enriquecimiento de simple registro: En un enriquecimiento de registro simple todo el requerimiento de entrada de informacin proviene de un registro. Esto es tcnicamente el mtodo mas simple de enriquecimiento ya que todos los campos de entrada provienen de la misma fuente y tienen la garanta de estar disponible para el componente de transformacin al mismo tiempo. El enriquecimiento de registro simple se divide en 2 casos: Enriquecimiento de campo simple: Emplea entradas de un campo simple dentro de un registro y crea uno o mas nuevos campos que representa una vista diferente de los datos. Enriquecimiento Multi-campo Permite una interaccin entre los campos dentro de un registro de entrada simple. El resultado puede ser la creacin de un nuevo campo en el registro de salida o la actualizacin de un campo existente. Ejemplos de este tipo son: Creacin de un campo conteniendo una categora demogrfica, donde la categora depende de una combinacin de edad, sexo e ingresos. Extensin del campo de descripcin de un producto para incluir atributos tales como peso, color o tamao las cuales se encuentran en campos de entrada separados.


Proyectos de Sistemas de Informacin GerencialEnriquecimiento Multi-registro En el enriquecimiento multi registro, los campos de entrada no son restringidos al mismo registro fuente sino que pueden provenir de mas de 1 registro. La salida del enriquecimiento multi registro es siempre la creacin de 1 o mas nuevos campos en las salidas. En algunos casos el nuevo campo representa informacin del negocio que previamente no exista. Un ejemplo es la creacin de un cdigo de anlisis de ventas que representa el xito en la venta de diferentes tipos de productos en diferentes segmentos de mercado, a travs de una combinacin lgica de cdigos de venta de productos y datos de segmentacin del mercado de clientes.

4.6 Apply una introduccinEl componente apply del proceso de replicacin toma las salidas del componente captura (tanto directamente como a travs de la transformacin y/o transferencia de datos) y aplica este dato al sistema destino, como se ve en la siguiente figura:

Apply opera en uno de los cuatro modos siguientes (ordenados de acuerdo a su complejidad tcnica): 1. Load apply carga y recarga el rea de datos destino, de modo que cualquier dato destino es completamente reemplazado por los datos capturados que ingresan. Load es la mas simple y amplia tipo de apply.


Proyectos de Sistemas de Informacin Gerencial2. Append En append, apply incondicional aade los datos capturados entrantes a los datos destinos existentes. Los datos existentes son preservados pero dependen de los contenidos de la data capturada y del DBMS del destino, nuevos registros pueden duplicar los existentes o pueden ser rechazados. 3. Destructive merge En este modo, apply une los datos capturados entrantes en la data destino existente. Donde las claves de los datos existentes y entrantes coinciden los datos son actualizados convenientemente, y donde las claves no coinciden entonces nuevos registros son agregados. 4. Constructive merge Es similar al destructive merge, pero con una diferencia importante. Donde las claves de los datos existentes e ingresantes coinciden apply marca los datos existentes como reemplazados pero no los sobrescribe. Los registros ingresantes son siempre de esta manera agregados al destino. La eleccin de cual modo usar en una particular circunstancia depende del tipo de dependencia de tiempo requerida en los datos destinos: Snapshot data Una foto, una vista esttica de los datos en un momento del tiempo es generada en el proceso de carga. Despus de la carga inicial, append puede ampliar la foto ingresando datos de diversas fuentes. Un snapshot permanece esttico y en algn momento (etapa) puedes ser eliminado o reemplazado por nuevos datos en otro momento en el tiempo. Esta sustitucin puede ser resultado de un segundo proceso de carga o nuevos datos pueden unidos (agregados) en otro momento en el tiempo. La unin destructive se da debido a que el snapshot no preserva las vistas de datos histricos. Datos temporales Tambin son creados a travs de una carga y adicin opcional y mantenidas a travs de la unin destructiva (destructive merge). Desde el punto de vista del componente apply, datos temporales y snapshot son virtualmente indistinguibles. La nica diferencia es la frecuencia de actualizacin: los datos temporales son actualizados durante la ejecucin mientras que los datos del snapshot son actualizados por intervalos. Datos peridicos Datos peridicos una vista histrica del negocio tambin es creada por el proceso de carga. Despus de la carga inicial, un append puede ampliar los datos usando datos ingresantes de una fuente diferente, bajo ciertas condiciones. La unin constructiva (constructive merge) es la mas efectiva manera para mantener datos peridicos, debido a que los registros nunca deben ser eliminados de los datos peridicos. Append tambin puede actualizar los datos peridicos pero solo si existe un mecanismo para marcar registros reemplazados despus que los datos capturados han sido aadidos.


Proyectos de Sistemas de Informacin Gerencial4.6.1 Metodos para cargaHay 2 utilitarios para poblar tables en una base de datos DB2: The LOAD utility The IMPORT utility El LOAD utility es empleado para carga y aadido de datos a una tabla donde hay enormes cantidades de datos que deben ser insertados. El LOAD utility puede mover datos entre las tablas, crear un ndice y generar estadsticas, 4.6.1.1 LOAD Utility Hay 3 fases en el proceso de carga (ver figura) 1. Load, Cuando los datos son escritos en la tabla 2. Build, Cuando los ndices son creados 3. Delete, Cuando las filas son eliminadas de la tabla debido a una violacin a las restricciones nicas.

Todas las fases del proceso de carga son parte de una sola operacin que es completada cuando las 3 fases del proceso son completadas exitosamente. El utilitario LOAD generara mensajes durante el desarrollo de cada fase. Podra ocurrir alguna falla en una de las fases, por lo que los mensajes ayudan a tomar decisiones sobre las acciones de recuperacin.


Proyectos de Sistemas de Informacin GerencialFase de carga En esta fase los datos son almacenados en una tabla y las claves son reunidas. Los mensajes le informan cuantas filas de datos estn siendo cargadas en la operacin. Fase de construccin En esta fase los ndices son creados en base a las claves reunidas en la fase anterior de carga. Las claves son ordenadas en la fase de carga. Si ocurre un problema se debe restaurar la configuracin tal como estuvo al inicio de la fase de construccin. Fase de cancelacin En esta fase son canceladas todas las filas que violan las restricciones nicas. Los datos de entrada en el proceso de carga debe estar en 1 de estos 2 formatos de archivo: Integrated Exchange Format (IXF): Mtodo preferido para intercambio entre los administradores de base de datos relacional. Ud puede exportar un archivo de datos de una base de datos host al servidor DB2 UDB. En general un archivo IXF consiste de una secuencia nica de registros de longitud variable. Un archivo IXF tiene una tabla de definicin almacenada dentro junto con los datos. Delimited ASCII (DEL): Empleado para una gran variedad de aplicaciones de la industria especialmente con otros fabricantes de base de datos. Esta forma de almacenar los datos es usualmente empleada usando un carcter especial de separacin de columnas. Non-delimited ASCII (ASC): Son usadas para cargar datos de otras aplicaciones que generan archivos planos de texto con columnas de datos alineadas tales como se producen en un procesador de textos. Cada archivo ASCII es un flujo de caracteres ASCII que consiste en valores organizados por filas y columnas. Las filas en el archivo de datos son separados por una linea en blanco. 4.6.1.2 Balanceo de carga DB2 con su cargador de datos paralelos permite que los procesadores puedan ser usados simultneamente para cargar una tabla de datos simple. Esta caracterstica puede ser efectiva en la carga de grandes volmenes de datos en un data warehouse. El archivo de entrada de datos es particionado (dividido en varios archivos pequeos), para procesar cada particin en paralelo reduciendo de esta manera el tiempo necesario para la carga de datos.


Proyectos de Sistemas de Informacin Gerencial4.7 Modelo de datosEl propsito del modelamiento es tener un registro exacto de algunos aspectos del mundo real en algn contexto particular. Esto proporciona al usuario del modelo un claro entendimiento del comportamiento de los objetos modelados, as como la capacidad de predecir las consecuencias de cualquier accin en el medio ambiente y el impacto de cualquier cambio. El modelamiento de datos del negocio proporciona una vista del negocio que se enfoca en los datos usados, facilitando el diseo de aplicaciones que soportan los procesos del negocio. El modelamiento de datos del negocio provee lo siguiente: Un registro de definiciones de datos del negocio exacto y relevante. Identificacin de estructuras de datos de negocios consistente y valido que contiene suficiente informacin para operar y administrar el negocio. un indicador de las diferencias y similitudes entre los datos de las distintas Fuentes y las relaciones entre ellas. El modelamiento de procesos de negocios se enfoca en las actividades del negocio proporcionando lo siguiente: Un registro de definiciones de procesos de negocios exacta y relevante. Identificacin de las relaciones entre los procesos de negocios. Entidades, atributos, relaciones: La forma mas habitual de modelar los datos del negocio es empleando el mtodo de relaciones de entidades (Chen 1976). En este mtodo (ver figura) una entidad es cualquier categora de un objeto in la que el negocio esta interesado. Cada entidad tiene una correspondiente definicin de negocios, la que es usada para definir los limites de la entidad, permitiendo a alguno decidir si un objeto particular pertenece a tal categora o entidad.


Proyectos de Sistemas de Informacin GerencialUn producto es definido como un item fsico que puede ser almacenado en uno o mas almacenes de la empresa. Esta definicin puede ser apropiada o no y depender de las condiciones en las que el modelo es desarrollado. En este sentido una entidad puede ser en un extremo excesivamente especifico o muy general en el otro extremo. Cada entidad tiene un numero de atributos asociados a el. Un atributo es una caracterstica de la entidad que la describe y que es de inters para el negocio. El segundo elemento mas importante en el modelo entidad relacin es precisamente la relacin. Una relacin existe entre las entidades de un modelo y describe como interactuan las entidades. Esta interaccin es usualmente expresada como un verbo. En la grafica superior la relacin entre el Producto y la tienda minorista es definida como Tienda minorista stock Producto.


Proyectos de Sistemas de Informacin Gerencial Chapter 5. BI solution architectureEn este capitulo se cubriran los siguientes aspectos: Approach by Industry Aplicaciones Herramientas

5.1 Business Intelligence reas de aplicacin por industriaPrimero se detallaran un conjunto de soluciones de BI especificas para las diferentes industrias

5.1.1 Aplicaciones BI para la industria minoristaLas siguientes son algunas aplicaciones BI relevantes para la industria minorista: Forecasting. Ordering and replenishment. Modelos de pedidos y reaprovisionamiento. Marketing. Quick response. Atencin rapida de pedidos. Merchandising. Marketing individual de productos. Distribution and logistics. Transportation management. Inventory planning. Planeamiento de ubicacion del stock. Administracin del espacio.

5.1.2 Insurance BI applicationsEstas aplicaciones estan orientadas fundamentalmente al analisis de riesgos de nuevos clients. Reclamos y analisis de productos estrella. Analisis de clientes. Analisis de riesgos.

5.1.3 Aplicaciones BI de banca, finanzas y seguros Analisis de rentabilidad de clients. Administracion de creditos. Ventas de la marcas.

5.1.4 Aplicaciones BI industria de Telecomunicaciones Segmentacion e historia del cliente Previsiones de la demanda del cliente.

5.1.5 Aplicaciones BI de la Industria de Manufactura Ventas/Marketing. Forecasting. Ordering and replenishment. Analisis de compras / proveedores Distribucion y logistica. Administracion del transporte Planeamiento de inventarios Planeamiento de ubicacion del stock.


Proyectos de Sistemas de Informacin Gerencial5.2 Productos de la solucion de Business IntelligenceVeremos la relacion de productos y herramintas de IBM (y de sus socios tecnologicos) para la BI. Estos productos se visualizan en la siguiente figura. Usaremos la estructura de Business Intelligence para categorizar y describir estos productos.

5.2.1 Aplicaciones de Business IntelligenceLas aplicaciones de business intelligence de IBM se conocen en el Mercado por el nombre de DecisionEdge. DecisionEdge es una solucin de Customer Relationship Management (CRM) que permite a las empresas analizar el comportamiento de sus clients con el objetivo de incrementar su participacin en el mercado y la rentabilidad de las operaciones con el cliente. A la fecha IBM ha anunciado soluciones de DecisionEdge para finanzas, seguros, telecomunicaciones y servicios. DecisionEdge igualmente se ve favorecida de la fuerte inversin de IBM en investigacin de minera de datos. Con el uso de el ambiente de desarrollo de Minera Inteligente, DecisionEdge proporciona la herramienta de Minera de Datos Inteligente para las aplicaciones de Relaciones de Marketing para ayudar a los usuarios a obtener un entendimiento claro de los temas empresariales claves tales como segmentacin de clientes, compras potenciales y fidelidad.



IBM esta dando mayor importancia al empleo de soluciones de inteligencia de negocios y esta generando soluciones de BI para las diferentes industrias.

5.2.2 Herramientas de Business IntelligenceLas herramientas de Business Intelligence pueden clasificarse en las siguientes categoras: Query and reporting Online analytical processing (OLAP) Information mining 5.2.2.1 Query and Reporting La principal familia de herramienta de consulta y reportes de IBM es la Query Management Facility (QMF). Recientemente IBM ha introducido en el Mercado la solucin QMF para windows que brinda soporte no solo a base de datos DB2 sino que tambin soporta cualquier fuente de datos relacional y no-relacional soportado por los productos middleware DB2 Data Joiner (ver descripcion abajo). QMF host objects son compatibles con QMF para windows, ampliando

Inteligencia de Negocios

Documents

Transcript of Inteligencia de Negocios