Implantación en una empresa de un sistema Business Intelligence SaaS/On Demand a través de la plataforma LITEBI

UNIVERSIDAD POLITÉCNICA DE VALENCIA ESCUELA TÉCNICA SUPERIOR DE INFORMÁTICA APLICADA 2009/2010 Implantación en una empresa de un sistema Business Intelligence SaaS / On Demand a través de la plataforma LITEBI PROYECTO FIN DE CARRERA Autor: Rafael Matamoros Zapata Director: Antonio Hervás Jorge Tutor Empresa: Javier Giménez Aznar Empresa: LITE INTERNET SOLUTIONS “LITEBI” S.L 2 3 AGRADECIMIENTOS A mis compañeros en LITEBI, en especial a Javier Giménez Aznar y Jorge López Mateo, fundadores de la empresa, quienes me brindaron la oportunidad de formar parte de este proyecto y ampliar mi experiencia profesional, además con sus conocimientos, paciencia, dedicación y apoyo hicieron posible que saliera adelante este trabajo. A mi director académico Antonio Hervás Jorge, por la ayuda y los consejos prestados en la realización de la presente documentación, siempre sacando lo mejor de mí mismo a través de una mirada crítica y dedicando todo el tiempo posible a responder todas mis cuestiones. A mis padres Rafael y María del Carmen, mis hermanos Gemma y Juan Pablo, y al resto de mi familia por apoyarme siempre en mis decisiones y esforzarse para ofrecerme la oportunidad de llegar hasta este punto de mi vida, sin ellos no habría llegado hasta aquí. A todos, gracias. 4 5 ÍNDICE DE CAPÍTULOS 1 INTRODUCCIÓN 7 2 LA INTELIGENCIA DE NEGOCIO 15 3 CLOUD COMPUTING 43 4 LA EMPRESA CLIENTE: CECAV 46 5 PROYECTO BI CECAV: MAPA SANITARIO 49 6 ANÁLISIS DE REQUERIMIENTOS 52 7 DISEÑO DE LA SOLUCIÓN 67 8 IMPLEMENTACIÓN DE LA SOLUCIÓN 82 9 RESULTADOS DE LA SOLUCIÓN 108 10 CONCLUSIONES 114 11 BIBLIOGRAFÍA 115 ANEXO 1: PLATAFORMA BI SAAS, LITEBI 118 ANEXO 2: USO DE IMAGEN CORPORATIVA 173 6 LISTA DE ABREVIATURAS BI SaaS PaaS IaaS ETL OLTP OLAP ERP CRM MDX SQL DW DSS EIS SIG CMI BPM CPM CIF GIF CECAV Business Intelligence Software as a Service Platform as a Service Infrastucture as a Service Extract, Transform and Load On-line Transaction Processing On-Line Analytical Processing Enterprise Resource Planning Customer Relationship Management MultiDimensional eXpressions Structured Query Language Data Warehouse Decision Support System Executive Information System Sistema de Información Geográfica Cuadro de Mando Integral Business Performance Management Corporate Performance Management Corporate Information Factory Government Information Factory CEntro de Calidad Avícola y alimentación animal de la comunidad Valenciana 7 1 INTRODUCCIÓN 1.1 Introducción y motivaciones Actualmente la mayoría de las organizaciones y empresas poseen y generan diariamente una enorme cantidad de datos imposibles de analizar a simple vista. La mayor parte de estos datos generados no aportan la información necesaria a la toma de decisiones empresarial, pues para poder usarlos es necesario que se transformen en conocimiento útil para quienes dispongan de ellos. Estos datos se transforman en información cuando se analizan para estructurarlos de forma inteligente. En la actualidad, poseer un conocimiento proveniente de información comprensible, detallada, relevante y útil es vital para lograr y sostener una ventaja competitiva en el mundo empresarial. Para transformar los datos y convertirlos en información, y ésta a su vez, ser aprovechada como conocimiento, se necesitan distintas técnicas y procesos. A todos estos procesos de tratamiento de datos se les atribuye el término de Business Intelligence (BI, en adelante) o Inteligencia de Negocio. En el mercado actual podemos encontrar muchas herramientas de BI que ofrecen al usuario la posibilidad de analizar sus datos realizando diferentes tratamientos sobre éstos, como pueden ser el análisis y la realización de informes. Figura 1: Extracción del conocimiento a partir de los datos 8 Desde la creación del Data Warehouse o Almacén de Datos en los años 80 el volumen de datos y el nivel de detalle almacenado han ido creciendo a pasos agigantados. Dos son al menos los factores que han provocado este aumento, por un lado el desarrollo de la tecnología y con éste, la automatización de los procesos en las organizaciones. A partir de este punto, surge la necesidad de controlar la información de cualquier movimiento de una organización evitando los inconvenientes de los sistemas de gestión de datos tradicionales y obsoletos, ya que día a día, aumentan los datos operacionales asociados a dichos sistemas y consecuentemente los datos que se pueden analizar y almacenar de forma organizada en estas inmensas bases de datos. Relacionando los diferentes conceptos expuestos sobre el BI y la situación actual en los sistemas de gestión de datos, se puede decir que, cualquier organización a día de hoy necesita disponer de estrategias y herramientas de inteligencia empresarial, y en definitiva, de la potencia de las tecnologías de la información para poder obtener la mayor cantidad de información útil en el menor tiempo posible a partir de todos los datos que se generan, y transformarlos de esta forma en un activo intelectual que preste beneficios y se pueda compartir, facilitando así la toma y la corrección de las decisiones del negocio. Además, esto supone un ahorro de tiempo y dinero en el análisis y el estudio de cualquiera de las actividades de la entidad, evitando de esta manera el costoso acceso a datos de diferentes procedencias o departamentos, la generación de informes a partir de complicadas herramientas o de forma manual, así como reducir el riesgo empresarial. Las plataformas tradicionales de inteligencia de negocio en el mercado actual aportan un sinfín de ventajas a la organización empresarial, pero suelen ser costosas, tanto a la hora de la implantación en el sistema informático de la empresa como en el mantenimiento de éste, haciendo que muchas organizaciones tengan que adaptar sus sistemas para poder obtener los beneficios de estas herramientas, por ello, muchos usuarios son reacios cuando se plantean la posibilidad de implantar estos sistemas en sus empresas. Con Litebi estos problemas desaparecen, ya que al tratarse de una plataforma de BI que utiliza el modelo de distribución de Software como Servicio (Software as a Service, SaaS) el usuario puede consultar los movimientos de su empresa, realizar informes, cuadros de mando...etc. desde cualquier lugar sólo disponiendo de un ordenador con conexión a la red, haciendo que la plataforma se 9 adapte perfectamente a su sistema y no al contrario, olvidándose además de esta manera de las tareas de mantenimiento. Esta potente herramienta se caracteriza por aportar a los desarrolladores de soluciones de BI la facilidad de implementar soluciones personalizadas y adaptadas a cada caso en particular, independientemente de las diferentes fuentes de datos, en un tiempo récord, reduciendo extensos proyectos que tradicionalmente durarían varios meses a unas pocas semanas. Una vez diseñada la solución, Litebi presenta al usuario la integración en una misma plataforma de un conjunto de potentes herramientas de Business Intelligence para que el análisis de los indicadores del negocio sea lo más detallado y sencillo posible. Todas estas cuestiones han motivado la realización del presente PFC en el que se pretende realizar una solución de Business Intelligence a la medida de las necesidades de un cliente concreto e implantarla en su sistema a través de la plataforma de Business Intelligence SaaS / On Demand Litebi , garantizando al cliente la toma de mejores decisiones para su negocio a un coste significativamente menor que otras alternativas de BI tradicionales y sin necesidad de hardware ni software especializado, únicamente accediendo a través de interfaces web. 1.2 Objetivos Este proyecto se realizó con el fin de dar soporte y solución en la gestión y análisis de datos a una determinada empresa apoyándose sobre todo en el conocimiento de las tecnologías de la información y en concreto en las técnicas y herramientas que aporta el Business Intelligence. Para ello, se propuso realizar el análisis, diseño e implementación de una solución de BI sobre la plataforma Business Intelligence SaaS / On Demand Litebi. Para alcanzar este objetivo se planteó la consecución de los siguientes objetivos parciales: 16 Este término ya se vislumbró brevemente al comienzo de este proyecto pero en este capítulo trataremos de ofrecer una visión más específica de qué es el BI y ahondaremos en las técnicas y las herramientas que integra. 2.1.1 ¿Qué es la Inteligencia de Negocio? En este capítulo trataremos de exponer o ilustrar mediante una serie de definiciones de qué trata la Inteligencia de negocio: “Las aplicaciones de Business Intelligence (BI) son herramientas de soporte de decisiones que permiten en tiempo real, acceso interactivo, análisis y manipulación de información crítica para la empresa. Estas aplicaciones proporcionan a los usuarios un mayor entendimiento que les permite identificar las oportunidades y los problemas de los negocios. Los usuarios son capaces de acceder y apalancar una vasta cantidad de información y analizar sus relaciones y entender las tendencias que últimamente están apoyando las decisiones de los negocios. Estas herramientas previenen una potencial pérdida de conocimiento dentro de la empresa que resulta de una acumulación masiva reinformación que no es fácil de leer o de usar. “ (CherryTree & Co., 2000) “Llamamos Business Intelligence (BI) al conjunto de estrategias y herramientas enfocadas a la administración y creación de conocimiento mediante el análisis de datos existentes en una organización o empresa.” (Wikipedia) “Conjunto de tecnologías, métricas, procesos y sistemas que una organización usa para controlar y gestionar su rendimiento empresarial.” (Bani Brandolini, Presidente Internacional de Tagetik) “Business Intelligence (BI) es un conjunto de conceptos y metodologías para mejorar la toma de decisiones a través del uso de hechos y sistemas basados en hechos.” (Gartner Group) 17 “La inteligencia de negocio es un proceso sistemático de recolección, análisis y gestión de información interna y externa y de conocimiento para mejorar el proceso de toma de decisiones de una empresa.” (Jay Liebowitz, Stategic Intelligence: Business Intelligence, Competitive Intelligence, and Knowledge Management, 2006) “Los sistemas de BI convierten los datos en bruto de una compañía en información usable que pueda ayudar a la dirección a identificar tendencias importantes, analizar el comportamiento de clientes y tomar decisiones de negocio inteligentes rápidamente ” (Sun MicroSystems 2005) “La inteligencia de negocio es una amplia categoría de aplicaciones y tecnologías para recoger, almacenar, analizar y proveer acceso a datos para ayudar a los usuarios de la empresas a tomar mejores decisiones de negocio. Las aplicaciones de BI incluyen las actividades de los sistema de soporte a las decisiones (DSS), consultas e informes, tecnologías OLAP, análisis estadístico y data mining.” (SearchCRM.com) En definitiva podemos afirmar que la inteligencia de negocio puede tener dos proyecciones diferentes según se mire desde el punto de vista del negocio o desde el punto de vista técnico, donde se tienen más en cuenta las herramientas y las tecnologías por encima de la metodología de uso de la información en la toma de decisiones del negocio. En la figura 3 podemos observar el esquema clásico de una solución de BI. 18 Figura 3: Esquema de una solución de BI 2.1.2 La Inteligencia de Negocio: Cifras y Beneficios El Business Intelligence ha evolucionado a lo largo de los años para dotar, sobre todo a los altos ejecutivos encargados de analizar la información estratégica, de la capacidad de garantizar mejores decisiones. Anteriormente las personas encargadas del análisis competitivo a nivel corporativo solamente mostraban superficialmente el potencial de la inteligencia de negocios dentro de la empresa involucrando quizá el 5% de los usuarios y el 10% de los datos disponibles (Information Builders, 2005). Con la llegada del concepto de BI se observaron una serie de ventajas destacables en la implantación de estas soluciones para el análisis de información en una organización: - Información fácil, potente y asequible: Sin necesidad de conocimientos técnicos cualquier usuario, como un director comercial, puede acceder a información útil, organizada e integrada (gracias al concepto de Data Warehouse) en una misma aplicación en pocos minutos. - Información segura: La información perteneciente a cada usuario queda distribuida y controlada por medio de un sistema securizado vía web, aunque esta información queda centralizada en un sólo lugar y siempre quedará allí (no desaparecerá jamás). 19 - Análisis más sencillo y fiable: Toma de mejores decisiones por parte de la directiva a partir de cómodas herramientas (Cubos OLAP, reporting systems, consultas ad-hoc). - Control de estrategia empresarial: Análisis de un cierto campo desde diferentes puntos de vista (Dashboards o Balanced ScoreCards). - Datos útiles, actualizados y flexibles: En el diseño del Data Warehouse sólo se seleccionan aquellos datos que vayan a ser relevantes en el análisis y se les dota de una presentación o un formato adecuado que puede cambiar según los requerimientos de la empresa. - Eliminación del error humano: Todos los informes se realizan a través de la plataforma evitando la generación de costosos documentos en Excel de forma manual. - Automatización de circulación de información: Planificación automática de envío de informes dentro de una periodicidad a las personas necesarias, esto permite una mejora en la comunicación (Sistemas de alarmas, reporting automático). - Previsión sobre hipotéticos escenarios: Análisis de ciertos indicadores clave a través de ciertas herramientas que, junto con alertas, indiquen el impacto a futuro de éstos (Análisis what-if). - Organización de gran cantidad de información: Gracias a herramientas como el Data Mining y la utilización de Data marts. - Sistemas de estructura escalable: Esto hace posible que los sistemas crezcan de forma regulada. - Ahorro de tiempo y dinero: Estas soluciones permiten que cada sujeto cumpla su función y dedique tiempo para tareas más importantes, por tanto permite un aumento de la productividad. El tiempo es dinero. 20 Una encuesta realizada por Gartner en 2005, situó la Inteligencia de Negocio en el número 2 en la lista de prioridades tecnológicas de los CIO, ya que el mercado de herramientas software de BI creció un 7.7 % en 2004. Este crecimiento se produjo a través de compañías como Cognos y Microsoft, los cuales fueron los máximos beneficiados de aquella época. Año tras año Gartner realiza previsiones de este tipo sobre la evolución del mercado de Business Intelligence ofreciendo cifras y predicciones a los interesados en este sector. La última encuesta reseñable es la de 2009, donde destaca como la crisis económica está afectando a la estrategia empresarial así como al mundo de la Inteligencia de Negocios: - Predicción 1: “ En el 2012 las unidades de negocio (no los departamentos de sistemas o tecnología) serán responsables del más del 40% de presupuesto de los proyectos de BI.” En la actualidad la decisión de implantar una solución de BI suele delegarse sobre el departamento técnico cuando deberían ser los responsables de analizar la información, y por tanto de tomar decisiones corporativas, quienes deberían optar por estas opciones apostando por una visión de negocio más que por una herramienta. - Predicción 2: “Aún en el 2012, más del 35% de las principales 5,000 empresas mundiales (TOP 5,000) tomarán decisiones de manera desinformada debido a la insuficiente inversión en infraestructura de la información y herramientas de negocio para los usuarios.” Esto es debido a causa de la crisis económica, las empresas deberían invertir en información para superar el bache donde nos encontramos pero desgraciadamente no es así, cuando lo más aconsejable sería utilizar este recurso para garantizarse estrategias de mercado fiables. - Predicción 3: Para el 2010, el 20% de las empresas usará una aplicación de análisis relativa a su industria a través del esquema de SaaS (Software as a Service). 21 Esta filosofía se ha impuesto en los últimos años como compañera inseparable de la Inteligencia de Negocio por su simplicidad, bajo coste y eficacia en la implantación de estas herramientas, aunque todavía se encuentra en perfeccionamiento. - Predicción 4. En el 2009, la toma de decisiones en un medio colaborativo creará un nuevo título en el BI que combinará el software social con la plataforma de BI. Se ha comprobado que la toma de decisiones suele ser mucho más fructífera cuando se cuenta con una serie de opiniones para ello. Las redes sociales hoy en día han abierto un abanico de posibilidades de estrategias de negocio y por tanto en un futuro se prevé que se puedan utilizar conjuntamente con las herramientas de BI. - Predicción 5. En el 2012, una tercera parte de las aplicaciones analíticas aplicadas a los procesos de negocio serán entregadas a través de mashups. Los mashups son un tipo de aplicaciones web formadas por diferentes contenidos de otros sitios web. Se apuesta que este modelo sirva para completar con mayor información las aplicaciones de BI. 2.1.3 Tipos de usuarios BI La gran mayoría de las organizaciones se encuentra organizada jerárquicamente en una forma piramidal. En cada escalón de esta pirámide podemos situar a los diferentes tipos de usuario a la hora de tratar las herramientas que ofrece la Inteligencia de Negocio, así como determinar las decisiones de las que se harán cargo como podemos ver en la figura 4. Dirección General: Aquí se sitúan los altos cargos de la empresa, quienes cargan con la mayor responsabilidad en la organización y, por tanto, no disponen de tiempo suficiente para dedicarlo al análisis de información. Es por esto que utilizan herramientas como scorecards o dashboards, donde obtienen una visión rápida y global de los movimientos del negocio, que además puede contener enlaces a informes más concretos. 22 Cargos Medios: A esta altura encontramos el perfil típico de la rama Administrativa de la empresa. Estos cargos disponen de herramientas para el análisis de ciertos indicadores del negocio a mayor detalle que sus jefes inmediatos, ya que deben responder con resultados e informes ante ellos. Las herramientas de OLAP y consultas ad-hoc permiten que este tipo de usuarios pueda representar de forma visual diferentes tipos de análisis tanto en informes de tablas como en gráficos, partiendo de una gran cantidad de datos distribuida en cubos multidimensionales para realizar consultas. Operarios: Son los cargos más bajos de la empresa, pero aún así las herramientas de Inteligencia de Negocio les aportan cantidad de beneficios en su labor. Son usuarios de lo que se conoce como Informes Predefinidos, es un tipo estándar de informe con posibilidad de compartirlos con un formato típico corporativo, donde se incluyen gráficas y tablas de información obtenidas directamente de los procesos ETL. Figura 4: Toma de decisiones de acuerdo a un tipo de usuario Todas estas herramientas se describirán detalladamente en el siguiente apartado. 23 2.2 Herramientas y técnicas Como se ha mostrado a lo largo del presente capítulo, la Inteligencia de Negocio integra una serie de herramientas, tecnologías, metodologías y técnicas orientadas a aportar beneficios frente al tratamiento de la información en el negocio. En este capítulo se enumeran y se detallan los diferentes conceptos que forman la inteligencia de negocios, tanto técnicas referidas más al negocio como herramientas obtenidas con la informática. 2.2.1 OLTP (On-line Transaction Processing) Tecnología que se utiliza para administrar aplicaciones que utilizan operaciones transaccionales, es decir, sistemas donde se realizan una gran cantidad de modificaciones y entradas de datos y pocas lecturas masivas de los mismos. En estos sistemas es necesario tener un tiempo de respuesta aceptable a la hora de realizar las modificaciones de los datos. 2.2.2 OLAP (On-line Analitycal Processing) Estas herramientas manejan una serie de consultas de forma interactiva sobre estructuras multidimensionales (Cubos OLAP) cargadas previamente con los datos almacenados en las bases de datos corporativas tradicionales. Permiten realizar informes y obtener grandes cantidades de información a partir de lo que resultaría ser a modo rutinario una serie de complejas consultas sobre una base de datos de forma sencilla. Al estar los datos precompilados sobre una estructura intermedia, el tiempo de respuesta de las consultas es menor, posee una enorme potencia de cálculo y técnicas de indexación especializadas. Esta tecnología es favorable en un sistema OLTP pero suele ser lenta si se realizan complejas consultas. Con estos sistemas es posible analizar la información almacenada en un data warehouse, pero no es estrictamente necesario, ya que la información puede provenir de diferentes bases de datos. El objetivo de estas herramientas es obtener una mejor comprensión de lo almacenado en las bases de datos. 24 Figura 5: Ejemplo de Cubo OLAP Existe una categorización para estas herramientas según su arquitectura: - M-OLAP (Multidimensional OLAP): Sistema OLAP que posee los datos almacenados en una base de datos multidimensional. Esta implementación mejora los tiempos de acceso a los datos ya que están precalculados a costa de necesitar mayor espacio de almacenamiento, aunque algunos sistemas utilizan la compresión. Es un sistema OLAP compuesto por Cubos. Figura 6: Sistema M-OLAP 25 - R-OLAP (Relational OLAP): Sistema OLAP que mantiene los datos almacenados en una base de datos relacional. Para esta implementación se realiza un Cubo virtual o tablas en forma de estrella con lo que se consigue una mayor capacidad de almacenamiento sacrificando tiempo de respuesta. Figura 7: Sistema R-OLAP - H-OLAP (Hybrid OLAP): Combinación de los dos sistemas anteriores donde los datos se almacenan repartidos en implementaciones M-OLAP y R-OLAP. Esta combinación permite obtener ventajas de ambas implementaciones según donde se almacene el dato y las operaciones que se vayan a realizar sobre él. Figura 8: Sistema H-OLAP 32 visión global instantánea del estado actual de la empresa para definir posteriormente las estrategias necesarias. Se podría decir que estaríamos ante la cumbre de los sistemas de inteligencia de negocios. 2.2.6 Data Mining La minería de datos consiste en extraer conocimiento útil a partir de los datos en bruto de una organización. Las empresas almacenan grandes cantidades de información oculta en sus datos y gracias a estas técnicas y herramientas informáticas y estadísticas es posible que esta información vea la luz aportando conocimiento beneficioso para el usuario por medio de clasificaciones y predicciones. El objetivo de estas técnicas no es otro que encontrar patrones ocultos de comportamiento, tendencias y correlaciones entre los datos para disponer de suficiente información como para realizar modelos estadísticos que pueden servir para prever ciertas situaciones de la organización. Esta serie de patrones y tendencias se suelen agrupar en lo que se denomina como “Modelo de minería”, los cuales se pueden utilizar posteriormente en diferentes escenarios hipotéticos o simulados de negocio. Data mining se apoya en una serie de técnicas de adquisición de conocimiento y aprendizaje basadas en: - Redes neuronales: modelos de aprendizaje de conocimiento semejantes a una red neuronal biológica. - Árboles de decisión: Modelos en forma de árbol los cuales representan caminos de decisiones a tomar. Gracias a estas decisiones se obtienen clasificaciones para conjuntos de datos. - Algoritmos genéticos: Diseño basado en conceptos de evolución tales como mutaciones y combinaciones genéticas para la optimización de procesos. - Método del vecino más cercano: Técnica utilizada para la clasificación de registros en una serie de conjuntos basándose en similitudes con una serie de datos históricos. - Reglas de inducción: Partiendo de una premisa verdadera es posible llegar a una conclusión que quizás también lo sea. Se basa en técnicas estadísticas y lógicas. 33 - Análisis de series temporales: Técnicas de análisis de las relaciones subyacentes de un conjunto de datos ordenados cronológicamente con el fin de predecir su comportamiento futuro. Cabe destacar que, a diferencia de otras herramientas de BI, con la minería de datos no sólo se traslada y se presenta la información sino que se presentan datos al usuario que antes no eran visibles a simple vista. 2.2.7 CRM Customer Relationship Management en inglés. Es un concepto que trata de romper con el marketing tradicional, más centrado en el producto, y centrarse en el cliente, en establecer buenas relaciones con él y satisfacer sus necesidades. Hay que tratar al cliente de tal manera que se tenga como objetivo a cumplir el obtener su lealtad y confianza en el servicio o el producto que le estemos ofreciendo. Esta manera de gestionar la empresa orientándola hacia el cliente no sólo se puede conseguir por medio de una herramienta informática sino que cabe inculcar una cultura en la organización y cambiar algunos aspectos tradicionales. Estas herramientas cubren en la actualidad aspectos como: automatización de la fuerza de ventas, seguimiento de oportunidades, control de agenda y contactos, control de campañas de marketing, análisis de la información obtenida de los clientes…etc. En definitiva son herramientas que potencian la generación y la obtención de información sobre los diferentes perfiles de clientes para anticiparse a su demanda. En la actualidad podemos encontrar soluciones CRM On Demand (On-line), que parecen ser las que mejor aceptación están teniendo entre los usuarios y los departamentos de RRHH que manejan estas aplicaciones. Algunos ejemplos que podemos encontrar son Salesforce o como alternativa open source, SugarCRM. 34 2.2.8 BPM y CPM BPM y CPM son conceptos que se consideran sinónimos, Business Performance Management y Corporate Performance Management. Este concepto viene a considerar el análisis y el control de los indicadores clave del rendimiento del negocio con el objetivo de mejorar la eficiencia de la organización, tal como se vio en los Cuadros de Mando Integral pero de un modo más amplio. Se podría decir que el BPM, también coincidente con Business Process Management, va más allá del Business Intelligence, ya que se podría controlar y mejorar la empresa a través de una serie de aplicaciones informáticas que gestionen los procesos del negocio, apoyándose en las herramientas anteriormente expuestas. Por tanto, se puede observar que el BI y el BPM están claramente ligados en cuanto nos referimos a técnicas de mejora empresarial y a la monitorización de los indicadores clave del negocio, aunque el BPM se podría considerar una progresión del BI. 2.2.9 CIF y GIF Las siglas CIF y GIF vienen de Corporate Information Factory y Government Information Factory respectivamente, presentados por el iniciador de la teoría del data warehousing Bill Inmon. Estos términos se refieren en si a una solución integral de inteligencia de negocios teniendo en cuenta además el data warehouse propuesto por Inmon y, añadiendo para completar el concepto, cualquier herramienta o técnicas fuera del apartado informático que aporten beneficios a la compañía. Se podría decir que estos términos agrupan cualquier sistema informático y de información presente en la compañía para el análisis y la explotación de los datos. 35 2.2.10 Gestión del conocimiento El término gestión del conocimiento agrupa una serie de técnicas para gestionar, controlar y transmitir toda la información acumulada en la compañía a lo largo de su historia para que este conocimiento no quede restringido solo en ciertos sectores o a ciertos empleados de la empresa o que caiga en el olvido sin darle el uso apropiado. Este concepto ha tomado más forma en cuanto se empezaron a incorporar herramientas informáticas en las organizaciones, basadas en tecnologías de la información con el fin de almacenarla, gestionarla y compartirla (Intranets, Sites, Data warehouses, Wikis…). Hay autores que afirman que no es posible la implantación de un sistema de BI sin la existencia previa de un sistema o una serie de técnicas para la gestión del conocimiento. Esta afirmación no es una ley, pero de esta manera se puede observar la relación entre los sistemas de gestión del conocimiento y los sistemas de BI a la hora del manejo y el transporte de información en una compañía, en la cual la combinación y el apoyo mutuo de ambas facilitaría enormemente la transformación de los datos en conocimiento y la utilización de éste en la toma de mejores decisiones. 2.3 El Data warehouse 2.3.1 Introducción El término Data warehouse o Almacén de datos fue acuñado por Bill Inmon en 1990. Esta idea surgió debido a las necesidades informacionales de las empresas, entendiéndose como la necesidad de tener acceso a la información necesaria que sirva de base para la toma de decisiones tanto a escala estratégica como táctica. Años atrás se pusieron en práctica una serie de medidas para satisfacer estas necesidades pero no fueron suficientes debido a innumerables problemas como: consultas masivas y complejas de información que interferían en el rendimiento de otros procesos, limitada flexibilidad de navegación a través de la información, tiempo de respuesta elevado debido al acceso a múltiples lugares al mismo tiempo…etc. Inmon fue capaz de solventar esta serie de problemas gracias a la teoría del Data warehouse. Este sistema supone la centralización y almacenamiento de todas las fuentes de datos de la 36 empresa en un solo lugar y de manera organizada e integrada. El objetivo era disponer de toda la información histórica de la empresa centralizada facilitando de esta manera el análisis, además de mantener la información con una estructura organizada unívoca y acorde a las necesidades de consulta, y alimentando el almacén con la información contenida en las aplicaciones de manera periódica para no dejar escapar ningún tipo de información. Utilizando las herramientas expuestas en el capítulo anterior sobre el contenido de un data warehouse es cuando obtenemos una solución completa de inteligencia de negocios. Por tanto, se puede afirmar que el data warehouse es imprescindible en cualquier solución de BI. 2.3.2 Definiciones La teoría del data warehouse (DW) fue un gran impacto para el mundo corporativo. Este concepto fue introducido además de por Bill Inmon, por Ralph Kimball. Ambos autores coincidían en la base del concepto, pero discrepaban en una serie de diferencias según el punto de vista de cada uno en relación al concepto y el uso del data mart (subconjunto de información del data warehouse que hace referencia a un departamento o sector concreto de la empresa). A partir de estas diferencias cada uno de los autores definió el data warehouse según su punto de vista: “Un data warehouse es una colección de datos orientada a un dominio, integrado, no volátil y variable en el tiempo que ayuda en la toma de decisiones en una organización” (Bill Inmon, 1992) Para este autor el data warehouse es una parte del sistema de la inteligencia de negocios. Los data marts se crean después de diseñar el DW y obtienen la información de éste, no siendo posible la consulta directa de información (se dice que la información no está almacenada de forma dimensional). Esta aproximación es conocida como “Top-down”. 37 “Un data warehouse es una copia de los datos de transaccionales especialmente estructurada para la consulta y el análisis” (Ralph Kimball, 1992) Para Kimball el data warehouse es el conjunto de todos los data marts existentes en la empresa, aunque normalmente se almacenen de forma separada. Bajo esta concepción la información está almacenada en un modelo dimensional y por tanto está lista para ser consultada. Esta aproximación se conoce como “Bottom-up”, una metodología ascendente a la hora de diseñar un almacén de datos. En la actualidad estas diferencias carecen de importancia aunque se han dado casos en grandes empresas que la concepción de Inmon es mucho más efectiva que la de Kimball, ya que tener un data warehouse centralizado resuelve muchos problemas. Por el contrario, la aproximación multidimensonal de Kimball ha terminado imponiéndose como estándar a la hora del diseño de data warehouses. Para un concepto tan extenso y revolucionario, las definiciones dadas por Inmon y Kimball en su dia parecen escasas e incompletas. A lo largo de los años se han ido obteniendo definiciones más completas y detalladas: “Un data warehouse es un conjunto integrado de bases de datos que se diseña y utiliza para apoyar en la toma de decisiones y en él cada unidad de datos es relevante en algún instante de tiempo, además, contiene información no sólo de bases de datos relacionales, sino de otras fuentes relacionadas con la actividad de la organización y cuya finalidad no sólo se centra en el almacenamiento de esos datos, sino en su análisis y procesamiento mediante los procesos encargados de su gestión para la obtención de información estructurada y en definitiva útil para la toma de decisiones” (Delgado, 1999) Como se puede apreciar el concepto ha evolucionado y ha tomado un rumbo más orientado hacia su uso que hacia las metodologías de diseño. 38 2.3.3 Modelos de tablas A la hora de diseñar un data warehouse, uno de los elementos esenciales para su diseño es el modelo de tablas a escoger. Actualmente el modelo de tablas que normalmente se sigue en el diseño de un data warehouse suele ser el modelo multidimensional propuesto por Kimball, ya que se ha impuesto con el tiempo al modelo relacional de Inmon, salvo algunas excepciones. El modelo a seguir se denomina esquema en estrella. Figura 13: Ejemplo de modelo en estrella Este modelo permite el análisis de información a partir de una base de datos relacional, estructurando los datos y organizándolos de forma multidimensional. Este modelo está compuesto de una serie de tablas que se clasifican en: - Tablas de hechos: Es la tabla central o nuclear de un esquema multidimensional. Esta tabla contiene los datos a medir, aquello que es cuantificable, datos que suelen ser las mediciones numéricas del negocio. Todo dato a medir es un hecho donde la 39 granularidad de éste hecho viene condicionada según el nivel de detalle con el que se almacene en la tabla, ya que cada medida es tomada según la intersección de las dimensiones que la definen. Se distinguen por tanto dos tipos de columnas en una tabla de hechos: columnas hecho y columnas clave, donde las columnas de hechos son aquellas donde se almacenan las medidas y las columnas clave donde se almacena la clave primaria referente a las dimensiones. - Tablas de dimensiones: Estas tablas se sitúan alrededor de la tabla de hechos, relacionándose con ella. Contienen información dimensional que permite filtrar, organizar y alimentar la información almacenada en la tabla de hechos. Cada una de las tablas de dimensiones relacionadas con la tabla de hechos contiene una única dimensión, la cual se reparte en jerarquías compuesta por una serie de niveles, las cuales se encuentran de forma denormalizada. Al producirse una serie de hechos estos varían según la relación obtenida con el resto de tablas dimensionales que envuelven a los hechos. A partir de un hecho “Cantidad Compra” y una relación con la dimensión “Producto” se podría filtrar la cantidad por algún producto en concreto y además se podría observar de manera jerárquica a qué grupo de productos pertenece, de que compañía…etc. Como se puede observar, esta manera de organizar la información en un data warehouse favorece a técnicas como el análisis OLAP, las consultas de información y la generación de informes. Existen otros esquemas como el del modelo de copo de nieve, donde la principal diferencia es que las jerarquías se encuentran normalizadas, esto es, los niveles de las jerarquías en las dimensiones se encuentran en tablas separadas y se estructuran y se relacionan entre sí de forma jerarquizada. 2.3.4 Procesos ETL Extract, Transform and Load (Extraer, Transformar y Cargar). Los procesos ETL son los encargados de extraer datos de múltiples fuentes, darles formato y presentación, convertirlos en información útil y organizada, y cargarlos y almacenarlos en un almacén de datos o data mart para su posterior análisis a través de las herramientas expuestas anteriormente. 40 Figura 14: Etapas de una solución de BI 1Extraer: Este paso se basa en extraer e integrar la información de diferentes fuentes (ERP, CRM, Excel) en el data warehouse. En este proceso de extracción se estandariza un formato para todos los datos que poblarán el data warehouse, ya que provienen de diferentes fuentes y cada una originalmente poseerá un formato propio. 2Transformar: En esta fase se ponen en práctica una serie de reglas de negocio para seleccionar únicamente la información necesaria para el data warehouse. Utilizando técnicas de filtrado, manipulación de datos y cálculos evitaremos almacenar información no necesaria, redundante o errónea. 3Cargar: En esta última fase los datos ya formateados, integrados y seleccionados se almacenan en el data warehouse. Cabe destacar que esta carga no siempre se realiza de la misma manera, ya que hay organizaciones que optan por borrar todo el contenido del data warehouse y cargarlo de nuevo, y otras que optan por actualizar el data warehouse únicamente con la información que ha llegado nueva. Los procesos ETL adaptarán la información original en función del perfil del usuario final en distintos formatos de presentación, como pueden ser aplicaciones de análisis, informes, scorecards o cuadros de mando. 41 Un mal diseño de procesos ETL puede ocasionar graves problemas operativos a la compañía. Actualmente el procesamiento de grandes cantidades de datos está siendo mucho más ligero gracias al procesamiento en paralelo. Una potente herramienta ETL de procesamiento en paralelo, y además open source, es Kettle™ Pentaho Data Integration, la cual se utilizó a lo largo de la realización del presente proyecto. 2.4 El Sistema informacional Un sistema informacional está formado por aquellas herramientas y elementos orientados al tratamiento de datos e información y que son capaces de acercarla al usuario mientras esté almacenada en un data warehouse. El sistema informacional viene a englobar todas las herramientas de consulta y análisis de datos anteriormente expuestas y que además forman el concepto de Business Intelligence. En un sistema informacional puede darse el caso que encontremos estas herramientas separadas o por el contrario que interactúen entre sí, dando mayor versatilidad al usuario (con Litebi esto es posible además de otras plataformas de BI como Cognos o Business Objects). Además de esta interacción entre las herramientas, los sistemas se apoyan en herramientas extras para obtener una facilidad al usuario en el acceso y el uso compartido de éstas (seguridad, portales…). Podemos decir que el sistema informacional es la capa de interacción entre el usuario y el data warehouse (lo que el usuario percibe del sistema es únicamente la capa de aplicación). A este tipo de sistemas también se les suele conocer como aplicaciones o plataformas de inteligencia de negocios. 48 4.4 Actividades de la empresa El fin de este Centro de Calidad Avícola y Alimentación Animal (CECAV) es el de realizar actividades que contribuyan a la mejora del sector avícola, y de la alimentación, potenciando la adecuada aplicación de la legislación en materia sanitaria, tanto de engorde y puesta, como en mataderos avícolas y fábricas de piensos, incrementando de esta forma la calidad de la producción, fomentando además la exportación y realizando todas aquellas actividades que de una forma directa e indirecta contribuyan al progreso y a la mejora del sector. La actividad a desarrollar por el CECAV es la de analizar, detectar y diagnosticar anomalías y enfermedades avícolas, de aquellas muestras que traen entidades privadas o públicas, además de formar a personal que esté trabajando o esté directamente relacionado con el sector avícola, para conseguir una mayor profesionalización y un incremento de la calidad en el sector. 49 5 PROYECTO BI CECAV: MAPA SANITARIO 5.1 Introducción Esta sección tiene como objeto presentar la propuesta de desarrollo por parte de Litebi de una solución de Business Intelligence para CECAV (Centro de Calidad Avícola y alimentación animal de la Comunidad Valenciana). El objetivo del proyecto fue proporcionar una herramienta informática (Business Intelligence) que posibilite la explotación on-line, a través de Internet, de la información de resultados analíticos realizados por el CECAV en la Comunidad Valenciana. Para ello se planteó el uso de la aplicación de Business Intelligence SaaS Litebi. 5.2 Situación previa a la solución Escenario Cómo parte de su actividad, el CECAV, realiza análisis continuos del estado de determinadas enfermedades avícolas en la Comunidad Valenciana. Anteriormente se disponía de diferentes sistemas y herramientas informáticas que dan soporte a esta actividad, sin embargo no se disponía de ninguna herramienta que permitiera integrar la información de las diferentes aplicaciones y ofreciera un análisis sencillo y potente de los resultados. Además, anteriormente a la implantación de este sistema se estaban realizando de forma manual y anual mapas sanitarios dinámicos del sector avícola de la Comunidad Valenciana donde se muestran los resultados analíticos por comarca y por municipio para toda la comunidad. Objetivos del piloto 5.3 Objetivos de la solución Los objetivos a cumplir con el desarrollo de esta solución fueron los siguientes: - Integrar la información analítica existente para su análisis. - Reducir el tiempo necesario para preparar informes sobre los resultados de análisis (Mapas dinámicos o de otro tipo). 50 - Disponer de una herramienta de exploración y análisis OLAP de la información potente para uso interno del CECAV. - Disponer de una herramienta de visualización geográfica de los resultados por comarcas y municipios (Esta herramienta se desarrolló expresamente para este proyecto en colaboración con el departamento de sistemas). 5.4 Solución propuesta Existen en CECAV tres aplicaciones que se utilizan para diversos tipos de análisis (estos sistemas se detallarán más adelante). Algunas de estas aplicaciones cuentan con herramientas de reporting básico y exportación, pero no se disponía de la posibilidad de analizar la información de los tres orígenes sobre una misma plataforma ni se disponía de una herramienta para la realización de mapas a partir de los datos contenidos en las aplicaciones. Por tanto, se propuso construir utilizando la aplicación de Business Intelligence Litebi una solución analítica que integrara la información de los tres sistemas existentes y posibilitara su análisis temporal, geográfico y desde múltiples puntos de vista (ej. enfermedad) de la forma más sencilla posible. Se planteó para el presente proyecto integrar únicamente la información de resultados analíticos, quedando fuera del alcance otros conjuntos de información (gestión, contable, recursos, etc...). El proyecto incluía por lo tanto: - Desarrollo de los procesos de Integración de la Información (ETL) para las tres aplicaciones. - Configuración del espacio privado securizado de Litebi para CECAV, con un cubo analítico por cada aplicación. - Desarrollo de la funcionalidad de análisis geográfico. - Formación en el manejo de Litebi a los usuarios finales. - 12 meses de cuota de subscripción de Litebi para un proyecto con el alcance mencionado. 51 Todo el proyecto se enfocó además teniendo en cuenta las posibles ampliaciones del sistema a otras áreas de información como por ejemplo contabilidad. 5.5 Planificación Se estimó una duración del proyecto de desarrollo e implantación de 3 meses, incluyendo tareas de análisis, diseño e implementación de la solución. Las tareas asociadas al proyecto dieron comienzo a partir de la firma del contrato, además, en dicho contrato, se agregó a la valoración el coste de la subscripción a la plataforma Litebi durante un año (12 meses), comenzando en Mayo del 2010, tarifa que incluye hardware, software y mantenimiento básico. Se aplicó para la subscripción mensual la tarifa BASIC (95 € / mes), en caso de ser necesario se dispone de la posibilidad de contratar espacio, usuarios o cubos adicionales. A lo largo de las siguientes secciones se presentara de forma detallada la realización de esta solución una vez obtenidos los suficientes conocimientos relacionados con el BI y habiendo adquirido la suficiente experiencia en proyectos más pequeños como para afrontar uno de semejante magnitud. 52 6 ANÁLISIS DE REQUERIMIENTOS Cuando la empresa cliente decidió formalizar su proyecto de Business Intelligence con Litebi, se inició el procedimiento rudimentario de toma de requerimientos de las áreas o departamentos implicados en el proyecto. Esta fase es la más importante dentro de la implantación de una solución de BI, ya que, si se falla en este proceso, las posteriores fases no tendrán sentido y obtendremos una solución errónea que supondrá un fracaso para la empresa que lo implanta así como para el cliente. Esta fase es la que establece el rumbo que tomará dicha solución en la empresa. Se trata de una tarea meticulosa donde hay que actuar como consultor de estrategia de negocio además de como desarrollador, ya que hay que atender al detalle, a través de sucesivas reuniones con el cliente y/o los departamentos involucrados, sobre las necesidades del cliente, así como analizar los sistemas y métodos de obtención de información que se están utilizando previamente a la implantación de la solución. A partir de esta serie de análisis se diseñará y se implantará una solución acorde a las necesidades del cliente, que muestre toda la información necesaria de manera rápida y sencilla, y en definitiva, que la solución suponga un beneficio en tiempo y dinero para la empresa solicitante. Para la toma de requerimientos se determinan diferentes formas de hacerlo. Aunque el objetivo parece similar, el resultado de cada escenario puede ser totalmente diferente. Por ello, nos basaremos en establecer los escenarios comunes a cualquier solución de BI para dicha toma de requerimientos, y tras esto, centrarnos en los puntos específicos del caso concreto que se plantea. Cuando se formalizó el proyecto con CECAV, a través de la firma de un contrato, se incluyó una cláusula de confidencialidad, la cual se cita a continuación. Por esta razón, no se presentará ningún dato numérico real que comprometa a la empresa cliente o a Litebi a lo largo del presente documento. La presentación a lo largo del proyecto del resto de datos asociados tanto a las empresas como a la información parcial presentada en la plataforma (se puede considerar la plataforma como tal) queda autorizada tanto por la empresa donde se desarrolló el proyecto como por la empresa cliente (Ver Anexo 2). 53 COMPROMISO DE CONFIDENCIALIDAD “LITEBI” se compromete a mantener la información introducida en la Plataforma Litebi reservadamente, otorgándole a la misma el carácter de estrictamente confidencial, y mantenerla protegida del acceso de terceros no autorizados. “LITEBI” se compromete a no permitir la copia o reproducción total o parcial de la información que se encuentre en la Plataforma Litebi. “LITEBI” se compromete a guardar estricta confidencialidad, discreción y cuidado respecto a la información que se encuentran en la Plataforma Litebi. “LITEBI” se compromete a entregar una copia de seguridad de los datos que se encuentran en la Plataforma Litebi mediante pedido expreso de la empresa contratante. “LITEBI” se compromete a la destrucción total de los datos introducidos en la plataforma Litebi transcurridos 3 meses de la baja del contrato de servicio “EL CLIENTE” cede en este acto información y secretos comerciales a “LITEBI”, con el fin de que ésta pueda desarrollar el proyecto encomendado. Asimismo, “EL CLIENTE” autoriza a “LITEBI” para que pueda ceder a su vez la información y secretos facilitados a empresas con quienes tenga acuerdos comerciales, exclusivamente para la ejecución y desarrollo del proyecto contratado. 54 6.1 Toma de requerimientos A la hora de iniciar la fase de la toma de requerimientos es necesario plantearse como punto de partida los objetivos a conseguir con cualquier solución de BI y tener en cuenta los diferentes fallos que se han presentado a lo largo del tiempo a la hora de llevar a cabo un proyecto de BI para no caer en ellos. 6.1.1 Requerimientos genéricos En cualquier solución de BI existen una serie de requerimientos genéricos, donde deberíamos plantearnos esta serie de puntos: - Proveer de un sistema intuitivo y orientado hacia un usuario final con pocos conocimientos técnicos donde éste sea capaz de generar sus propios reportes y análisis: Litebi es una plataforma que cumple estos requisitos, ya que se ha desarrollado siempre pensando en el uso por un usuario (Interfaz Windows) que sea capaz de generar sus análisis de forma sencilla con unos simples clicks de ratón. - Tener una sola versión de la información: A través de los procesos ETL, la información queda formateada a gusto del usuario final y se presenta siempre actualizada de la misma manera en cualquier ocasión. - Proveer información de toda la compañía en un solo sistema: En el punto siguiente se presenta el objetivo de integrar tres fuentes diferentes de información dentro de la misma plataforma. - Que los usuarios puedan acceder a la información desde cualquier lugar y en cualquier momento: Gracias al modelo SaaS de la plataforma esto es posible accediendo a través de Internet. Cumpliendo dichos objetivos base de cualquier solución podemos plantearnos otra serie de requerimientos a cumplir. 55 6.1.2 Requerimientos funcionales Los requerimientos funcionales son aquellos que marcan la base para tomar decisiones en las posteriores etapas de algunos proyectos de BI. Es muy común que muchas empresas decidan su proyecto de BI en base a las herramientas disponibles. Algunos requerimientos funcionales que deben cumplir las plataformas de BI son los siguientes: - El sistema deberá proveer la facilidad de drill down, slice and dice, fórmulas avanzadas…etc.: Litebi presenta estas funcionalidades a través de su interfaz y el lenguaje MDX (Ver Anexo 1). - El sistema deberá tener los mecanismos para controlar la seguridad de los datos por departamento, área o gerencia así como una distribución organizacional jerárquica de la información: Litebi es una plataforma securizada y por medio de los roles se tiene la posibilidad de distribuir la información contenida en la plataforma de forma jerárquica según el cargo y departamento del usuario. - El sistema proveerá un mecanismo de notificaciones y alertas, con criterios y reglas configurables: Este sistema está por desarrollar (Ver Anexo 1). - El sistema permitirá la integración de diferentes fuentes de datos: Como se explicará más adelante este es uno de los mayores problemas que arrastra la empresa cliente y con la solución fue posible integrar tres fuentes diferentes de datos en un solo lugar. Analizando de forma objetiva estos requerimientos podemos observar que la mayoría de plataformas de Business Intelligence en el mercado actual cumplen esta serie de objetivos, aunque esto no es suficiente para que la solución desarrollada cumpla con el objetivo principal que es la de aportar valor al negocio. 56 6.1.3 Requerimientos de Datos Otra vía de toma de requerimientos es la de solicitar al cliente un listado de los datos que requieren sus reportes, o reportes que están sacando actualmente con sus herramientas para conseguir incluir todo lo necesario en la solución para que los usuarios finales puedan realizar los reportes sin problemas. Los usuarios finales son los que conocen de primera mano su departamento y su área de trabajo, así como los reportes que se andan realizando, por lo tanto, es muy común y entendible que dichos usuarios marquen la pauta de los datos que se requieren y en el formato que los quieren. Estos datos concretos y ejemplos de informes sobre la empresa cliente se presentan en el apartado 6.3. Aunque este escenario es importante para que los usuarios dispongan de toda la información necesaria, por sí sola no es una estrategia de toma de requerimientos completa, debido a que el resultado final no sería el aportar un valor de negocio sino una manera de automatizar las tareas de reporting. 6.1.4 Requerimientos de Negocio Una manera de poder dar valor al negocio es hacer requerimientos que dependan del mismo. Para ello es necesario definir requerimientos donde se establezcan los objetivos de la solución que sean medibles, controlables y confiables. La toma de requerimientos sobre este escenario puede resultar más compleja que en los casos anteriores, ya que cada decisión debe aportar valor al negocio de manera directa o indirecta según una serie de objetivos: - Definir la estrategia de negocio en procesos que sean medibles y controlables. - Identificar la información necesaria para cada proceso de negocio, detallando su forma de análisis, seguimiento, técnicas de análisis, así como requerimientos tecnológicos para su cumplimiento. 57 - Priorizar los objetivos de la solución en función de su impacto en las metas del negocio. - Diseñar una administración flexible que permita la adaptación de las estrategias del negocio a corto y medio plazo basado en el aprendizaje continuo de la operación y seguimiento del negocio. Esta serie de objetivos se cumplieron finalmente estudiando la actividad de la empresa y teniendo como objetivo cubrir una serie de necesidades demandadas, dejando las cuestiones tecnológicas a un lado, ya que gracias al modelo SaaS no fue necesario considerarlas. 6.1.5 Fallos comunes en las soluciones de Business Intelligence Además de tener en cuenta los diferentes requerimientos que se deben tomar a la hora de comenzar la implantación de una solución de inteligencia de negocios, debemos tener presente una serie de fallos en los que se suele caer a la hora de llevar a cabo un proyecto de BI. Aquí presentamos algunos de estos fallos según la experiencia en otros proyectos: - Los data warehouses crecen en gran tamaño porque los técnicos acceden a cualquier exigencia que los usuarios demandan. - Se confía demasiado en la gente de la empresa cliente para realizar el proyecto, cuando estos no tienen ni tiempo ni los conocimientos necesarios para apoyarnos en la toma de requisitos. - Se suelen producir retrasos en la entrada a producción del sistema debido a una mala planificación. - Presupuesto erróneo, el precio presupuestado es escaso en comparación con la complejidad de lo que se quiere desarrollar. - Mala elección de software y hardware sin tener en cuenta los criterios técnicos. - No se realizan pruebas de concepto para determinar si el proyecto es viable. 64 Otra de las ventajas que Litebi proporcionaba además de la rapidez y la sencillez a la hora de generar estos informes, era la posibilidad de que estos informes fuesen dinámicos, es decir, fácilmente editables y consultables por el usuario para componer nuevos informes a partir de otros. 6.4 Necesidades de información A la hora de diseñar la capa de metadatos que compondrá la solución, había que hacer hincapié e identificar aquellos conceptos y elementos utilizados en los informes que previamente se extraían de las diferentes aplicaciones, además de las indicaciones dadas por el centro a lo largo de sucesivas reuniones. Estos factores había que adaptarlos a la estructura de cubo que utiliza Litebi para que el usuario final fuera capaz de, por lo menos, generar los mismos informes que se estaban generando anteriormente. Aquí presentamos los diferentes conceptos de información necesarios para el cliente, su distribución y presentación en estructura de cubo se verá en el apartado de diseño de la solución de manera detallada: − Tiempo : Poder observar los datos desde el punto de vista Año->Trimestre->Mes->Día. También había que contemplar la posibilidad de observar los datos desde la perspectiva de un curso por demanda de CECAV (de septiembre a septiembre). Se identificaron diferentes conceptos que hacían referencia al tiempo: fecha de entrada de la muestra, fecha de toma, fecha oficial, fecha de inicio de análisis, fecha de fin de análisis…etc. − Geografía: Tratar los datos desde un punto de vista geográfico de la siguiente manera: Comunidad->Provincia->Comarca->Municipio->Explotación. Las explotaciones vienen identificadas por un código de explotación alfanumérico asignado por el REGA (registro general de explotaciones ganaderas). Estos códigos se componen de las letras ES más doce dígitos, donde ES identifica el país, en nuestro caso España; los dos primeros dígitos identifican la provincia, tres dígitos que identifican al municipio y 7 dígitos que identifican la explotación dentro del municipio. Los códigos para las provincias y los municipios son impuestos por el INE (Instituto Nacional de Estadística). 65 − Enfermedad o Determinación: Es el factor de análisis de CECAV. Siempre se tienen en cuenta diferentes tipos de resultados según la enfermedad que se esté analizando. En unos casos son resultados numéricos y en otros resultados de positivo o negativo. Nos interesa tener en cuenta cualquier información referente a las enfermedades. − Muestra: Cada muestra se identifica con un código de muestra. Podemos decir que las muestras se clasifican en registros, donde un registro con un mismo código posee una serie de muestras con diferente código (Ejemplo: Si nos llega una placa, la placa completa se trata como un registro, pero cada una de sus celdas es una muestra que se analiza de manera independiente). Las muestras son el objeto de análisis y se pueden ver desde diferentes perspectivas como el producto que hace referencia la muestra (heces, alimento, animal, etc.) o el departamento donde se analiza (necropsias, química, serología, etc.). Está sujeta a diversas características que la identifican. − Origen: Nos indica el origen del análisis para una muestra determinada (Mapa Sanitario, Control, Plan Anual Zoosanitario, etc.). − Tipo de Ave: Característica indispensable que necesitaba el centro para clasificar sus análisis. Existen diferentes muestras asignadas cada una a un tipo de ave en particular (ponedoras, broilers…etc.). − Cliente: Otro dato a tener en cuenta era saber de qué cliente provenían cada una de las muestras a analizar. Se estableció en identificar al cliente mediante el NIF asociado. − Dueño Explotación: Al centro le interesaba saber no solo de que explotación provenían las muestras, sino que persona llevaba la explotación. En muchos casos el cliente era diferente al dueño de la explotación. • Indicadores o métricas: Tras analizar los diferentes factores a tener en cuenta según los puntos de vista de los diferentes informes, el análisis se centró en las cantidades numéricas que se estaban analizando. Se observó que dependiendo la 66 enfermedad, los resultados asociados eran diferentes (en unas enfermedades se medía el número de anticuerpos y en otros la densidad óptica) y por tanto no existía un patrón común de medida para todos los casos. Esta cuestión dificultaba el diseño y se planteó seguir adelante e identificar estos factores en concreto una vez el diseño fuese claro. Los únicos indicadores claros y comunes a todas las enfermedades eran: Número de muestras analizadas o número de registros analizados (o ambos) y número de explotaciones analizadas. 67 7 DISEÑO DE LA SOLUCIÓN Una vez hecha la toma de requerimientos y teniendo identificada toda la información necesaria para el cliente y acceso a los lugares donde se encontraba, pasamos a la fase de definición y diseño de los data marts en Litebi. En esta fase el departamento de sistemas definió el espacio de solución para CECAV dentro de la base de datos de Litebi, creando en primer lugar un usuario administrador que pudiera desarrollar la solución sobre el espacio asignado. Cuando se define un espacio de solución, se define automáticamente la estructura del data warehouse para el cliente, que es común a todas las soluciones y se asigna un espacio de almacenamiento base, pudiéndose cambiar más adelante si el espacio de almacenamiento no es suficiente. Cabe destacar que Litebi utiliza una tecnología ROLAP para su herramienta de análisis. A continuación se presenta el diseño y la definición de los cubos OLAP que representan los data marts en los que se divide el data warehouse de esta solución. 7.1 Objetivos y beneficios Como se ha presentado a lo largo del documento, el principal objetivo a cumplir en la arquitectura de la solución era que el CECAV dispusiera de toda la información relativa a cualquier tipo de análisis sobre las muestras de diversos tipos de aves integrada en una misma aplicación y que fuera accesible desde cualquier lugar. Esta información se utilizaría para realizar informes de manera más rápida y sencilla que con las aplicaciones que utilizaban anteriormente; y sobre todo, como objetivo principal a cumplir, la generación de mapas sanitarios de diversas enfermedades codificados por colores, algo muy importante para el centro y que resultaba demasiado costoso. La inexistencia de un sistema que proporcionara todas estas ventajas fue el factor principal que impulsó el desarrollo de esta solución. Todos estos beneficios tendrían que tenerse en cuenta a la hora de diseñar la solución, ya que eran los principales objetivos a cumplir. Estos objetivos ya fueron marcados y expuestos brevemente en el 68 apartado 5 donde se explicaban las condiciones del proyecto, pero fue necesario detallarlos a la hora de establecer un diseño que los satisficiera: • Estandarización: Al utilizarse diferentes sistemas de análisis, la presentación de informes dependía del formato de exportación de cada uno, presentando gran heterogeneidad en el tratamiento de la información. Esto dificultaba claramente el desarrollo de aplicaciones estándar para todos los departamentos de análisis de enfermedades, ya que cada uno trataba los análisis de maneras diferentes. Con la existencia de un data warehouse integrado y una sola aplicación de inteligencia de negocio para todos los departamentos se pretendía homogeneizar estos conceptos de negocio, sustituyéndolos por los definidos en el data warehouse. Las ventajas de esta estandarización son muchas: un informe desarrollado sobre una enfermedad es válido para toda la organización; los diferentes departamentos ven facilitada su comunicación entre sí al usar todos los mismos informes y conceptos de negocio; se facilita el acceso de la información a niveles más elevados dentro de la jerarquía empresarial con necesidad de mayor nivel de consolidación. La estandarización es de una importancia enorme para conseguir el objetivo: Inteligencia. • Capacidad de análisis: La herramienta de Inteligencia de negocio Litebi posibilita múltiples métodos de análisis de información: Cubos con tecnología OLAP, DrillTrough, Slice and Dice, y desarrollo de informes simples en un tiempo muy escaso. Todo esto sin necesidad de conocimientos informáticos por parte del usuario. La existencia de estas posibilidades fue muy útil para los usuarios operativos que tienen que tratar con información de cada día al momento y tienen necesidad de analizarla en profundidad para la toma de decisiones operativas. Estas herramientas de análisis también resultaban útiles para el caso en que una persona en un puesto más elevado dentro de la empresa quisiese “investigar” un suceso concreto más detalladamente. • Generación de Informes: La aplicación por la que se optó posibilita la creación de informes sencillos (por cualquier usuario) o complejos (por un desarrollador especialista). Los informes pueden constar de tablas, gráficos, mapas. Pueden filtrar información dependiendo de quién sea el usuario. Pueden exportarse a otros 69 formatos además de tenerlo accesible desde el navegador (PDF, Excel,…etc.). Existe la posibilidad de planificar la ejecución de un informe de manera periódica y de ser enviados por mail a un usuario especificado. En definitiva la aplicación cuenta con la posibilidad de generar unos informes potentes y dinámicos que bien podían sustituir la gran mayoría de los informes usados hasta el momento en cada una de las aplicaciones. Lo que se pretendía era la generación de informes estandarizados que fuesen usados desde todos los departamentos. • Centralización: Uno de los aspectos atractivos de la tecnología es que está totalmente basada en web. Existe un portal desde el que se realizan todos los accesos a la información, donde se encuentran los informes y cubos desde donde se puede consultar la información en el momento. Esto permite guardar todos los desarrollos de la empresa en un mismo lugar, abaratando costes de mantenimiento y de desarrollo. La conclusión que se obtuvo a través de este análisis en detalle de los objetivos es que era fácil satisfacer estos objetivos gracias a las características de Litebi, donde el más importante y que menos dependía de la plataforma para el apartado de diseño era el de la estandarización, ya que habría que adaptar los tres sistemas a un formato estándar que los agrupara. 7.2 Primer diseño Una vez realizados todos los pasos de creación del espacio de solución por parte del departamento de sistemas, ya se disponía de un espacio de almacenamiento donde volcar los datos necesarios de la solución. Cuando identificamos la información necesaria y los orígenes de datos, se trabajó en el desarrollo de una capa de metadatos capaz de albergar las estructuras (cubos y dimensiones) que albergaran y permitieran el análisis de la información integrada. En la fase de diseño las tareas a realizar eran: 70 • Estructurar la información necesaria en un modelo estrella compuesto de tablas de hechos y tablas de dimensiones que marcarán la pauta para definir los cubos y las dimensiones. • A partir de los modelos en estrella, crear tantos cubos como modelos haya, crear dimensiones compartidas si existe al menos una dimensión repetida en dos modelos y el resto de dimensiones no comunes definirlas como embebidas. A través de esta reglas básicas se inició la fase de diseño de los data marts de la solución, partiendo sobretodo de que los objetivos a cumplir más importantes en cuanto al almacenamiento de los datos eran los de integración y estandarización. Con esta idea se propuso como primera alternativa el siguiente diseño de modelo en estrella. Como se observa este diseño contaba con un único cubo OLAP (ya que solamente existe un esquema de modelo en estrella) el cual debería contener datos provenientes de cualquier origen (las 3 aplicaciones mencionadas). Al cubo se le llamo “Resultados” y estaba formado por los siguientes indicadores y dimensiones: • Indicadores o métricas: Número de registros, Títer (Número de anticuerpos en la muestra), Resultado. • Dimensiones: Fecha oficial, Fecha toma, Fecha entrada, Fecha inicio análisis, Fecha fin análisis (Todas estas se sacan a partir de una dimensión compartida Tiempo, ya que todas hacen referencias a fechas y la dimensión Tiempo contendrá una serie de fechas tomadas desde una fecha inicial hasta una fecha final, por tanto sólo habría que establecer una asociación), Determinación (dimensión embebida) y Registro (o Muestra, también dimensión compartida). • Cabe destacar que a partir de una dimensión compartida es posible extraer dimensiones nuevas o separadas a partir de sus diferentes jerarquías (Ver Anexo 1). Por ejemplo, como vemos la dimensión Registro está formada por una serie de niveles, y podría darse el caso que yo quisiera filtrar por tipo de ave y también por origen, y como en este caso, existir los dos niveles en diferentes jerarquías (a la 71 hora del análisis solo es posible seleccionar una jerarquía de una dimensión y cambiarla por otra, pero nunca dos a la vez), por tanto, a la hora de explorar si no las tratamos como dimensiones separadas no seremos capaces de hacer este filtrado y se descartarían posibilidades infinitas de análisis. Así que, la dimensión Registro se separó en otras dimensiones lo que afectaba beneficiosamente a nivel de creación de informes, pero no afectaba de manera perjudicial a nivel de diseño. Figura 23: Modelo estrella de la primera solución Se eligió como primera alternativa este diseño, no por ello el mejor, pero a primera vista conseguía satisfacer los objetivos principales de integración (un cubo albergaba todos los datos de cualquier análisis existente en el centro) y estandarización (los datos provenientes de diferentes fuentes tendrían el mismo formato). Finalmente este diseño preliminar se desechó una vez nos pusimos a alimentar de datos las estructuras diseñadas (ya se sabe que cualquier proceso que conlleve una serie de fases siempre nos hace retroceder sobre nuestros errores). El caso era que al realizarse diferentes tipos de análisis en cada uno de los orígenes de datos, los resultados a medir eran diferentes factores en cada caso y esto era imposible de 72 representar únicamente con un indicador “Resultado”. Por otra parte, la dimensión “Determinación” que originalmente se alimentaba del origen de datos 1, no contenía algunas enfermedades presentes en los otros dos sistemas y resultaba bastante complicado unir las enfermedades de los tres lugares sin alterar de arriba abajo la solución. 7.3 Diseño definitivo Tras detectar los diferentes errores expuestos anteriormente, se planteó la idea de definir un cubo por cada uno de los orígenes de datos y uno global (que se alimentaría de los resultados de las placas analizadas en el origen de datos 1, donde en este proceso, se analizaban una serie de enfermedades determinadas pero no sobre unas muestras o registros determinados sino sobre todos los registros que llegaban al centro, ver punto 6.2.1). Por tanto el diseño definitivo de la solución quedó de la siguiente manera: • Cubo Resultados Origen 1 • Cubo Resultados Origen 2 • Cubo Resultados Origen 3 • Cubo Resultados Origen 1 Global • Además de los cubos se diseñaron las dimensiones compartidas: Tiempo, Determinación y Reg (explicadas en el diseño de los cubos que las utilizan). De esta manera se seguían conservando los criterios de integración y estandarización, ya que los datos se presentarían en el mismo formato en todos los cubos y seguíamos teniendo presentes todos los datos referentes a los análisis en una misma aplicación. Tras una breve comunicación con el cliente, éste nos resolvió la única desventaja que creíamos que se daba en este diseño: Nunca se comparan enfermedades entre sí. Por tanto esta solución se adaptaba a las necesidades del cliente ya que podrían analizar datos de los análisis pero esta vez además distinguidos por las características que cada una de las aplicaciones ofrecía, como por ejemplo los resultados característicos de cada tipo de análisis. Con esto se consiguió una solución más acorde y más personalizada con cada uno de los sistemas. El diseño de cada uno de los data marts 73 se expondrá con detalle a continuación (si se desea conocer al detalle la creación de los data marts y cada uno de sus elementos, ver Anexo 1). 7.3.1 Resultados Origen 1 A partir de los informes y datos obtenidos de la base de datos de la primera aplicación, se confeccionó la siguiente estructura de esquema en estrella para elaborar posteriormente este cubo. Figura 24: Modelo estrella del diseño del cubo para Resultados Origen 1 A partir de aquí este cubo contaría con los siguientes elementos: • Indicadores: Títer y Número de muestras de la placa. • Dimensión Número Columna (Embebida): Al tratarse de unas placas con una serie de muestras nos interesa ver resultados por columna de la placa. • Dimensión Número Fila (Embebida): Mismo caso que el anterior pero para las filas. • Dimensión Orden Determinación (Embebida): Número de enfermedades que se analizan para una muestra. 80 7.3.4 Resultados Origen 1 Global En este cubo se muestran datos de pruebas específicas realizadas sobre todas las muestras que llegan al centro, de ahí su nombre “global”. Este cubo se basa sobre el siguiente diseño de esquema en estrella: Figura 30: Modelo estrella del diseño del cubo para Resultados Origen 1 Global El cubo se compone de los siguientes elementos: • Indicadores: Número de registros, Positivos (cuantas muestras tienen resultado positivo), Totales, Valor Numérico. • Dimensión Orden Determinación (embebida): Número de enfermedades analizadas sobre una muestra. • Resultado textual: Un resultado en forma de texto que se añade cuando se realiza el análisis. Estos datos son de la forma: <10, 1’0E1…etc. son unos resultados bastante curiosos pero que son de utilidad para el centro. 81 • Además se tienen las mismas dimensiones compartidas que para el caso de Origen 1. Figura 31: Estructura del cubo para Resultados Origen 1 Global 82 8 IMPLEMENTACIÓN DE LA SOLUCIÓN 8.1 Pentaho™ Data Integration (Kettle) Kettle es un proyecto belga open source adquirido por Pentaho que incluye un conjunto de herramientas para la realización de ETL. Uno de sus objetivos es que el proyecto ETL sea fácil de generar, mantener y desplegar. Kettle se compone de 4 herramientas: SPOON: permite diseñar de forma gráfica transformaciones ETL. PAN: ejecuta las transformaciones diseñadas con SPOON. CHEF: permite, mediante una interfaz gráfica, diseñar la carga de datos incluyendo un control de estado de los trabajos. KITCHEN: permite ejecutar los trabajos batch diseñados con Chef. Es utilizado como base para la versión de LiteIntegrator por sus características: • Producto sólido con un largo recorrido. • Multiplataforma (java). • Ampliamente conocido en el sector del Business Inteligence. • Adaptable a las necesidades de Litebi (Open Source). • Ampliamente usado en software empresarial. • Basado en estándares (WSDL, SOAP, etc.). La combinación de Kettle y el paso de Output a Litebi (Ver Anexo 1) conforman el módulo liteIntegrator de Litebi, gracias al cual, la definición y carga de procesos ETL se simplifica de gran manera respecto a otros sistemas de BI. 8.2 Procesos ETL 8.2.1 ETLs Dimensiones Compartidas Las dimensiones compartidas son utilizadas en diferentes cubos de esta solución. Estas dimensiones contienen una serie de valores (a priori todos los posibles), los 83 cuales se asocian a los valores del cubo en el campo que especifiquemos como una dimensión compartida a través de su identificador. Por tanto, es lógico que para producirse esa asociación tengamos que almacenar los valores previamente en algún lugar. De esta manera conseguimos una estandarización de la información, ya que, si se utiliza una variable, por ejemplo Tiempo, en diferentes cubos, cuando los analicemos ambos presentaran esa variable en el mismo formato, independientemente de cómo estuviese representada en el origen de datos. Aquí se muestran los procesos ETL que alimentan las dimensiones compartidas. • Dimensión Tiempo: Utilizada en todos los cubos para diferentes tipos de fechas. Su ETL consiste, lógicamente, en generar una serie de fechas (tipo Date) y otros campos que se asocien con los diferentes niveles de las jerarquías (Año, Trimestre, Mes…etc.). Figura 32: Proceso ETL de la Dimensión Tiempo A continuación detallaremos la función de cada uno de los pasos que componen su ETL: 84 - Parámetros Dimensión: Se inician una serie de parámetros identificativos del tiempo a partir de una fecha inicial, en este caso 01-01-2005. - Secuencia Dias: Añade una columna DaySequence que nos servirá para sumarla a la fecha inicial y así obtener fechas correlativas. - Calcular Atributos: Proceso Java Script que calcula todos los atributos de una fecha, es decir, los niveles de las jerarquías definidos en la dimensión. Para ver el código ver Anexo 3. - Filtrar Filas: Este paso hace que solamente pasen aquellas fechas menores que la fecha actual, por tanto, no existirán fechas seleccionables en el análisis que todavía no hayan ocurrido. - Dummy: A este paso llegan aquellas filas que no cumplen la condición impuesta en el filtro. - Selecciona/Renombra Valores: Con este paso desechamos aquellos valores que ya no son importantes en el resultado final. Así rebajamos la lectura de datos en este punto. - Secuencia Dias 2: Este paso calcula horas para cada día (para este caso no es relevante ya que no miramos a nivel de horas, pero se suele reutilizar el código de la dimensión tiempo en varias soluciones diferentes). - Selecciona/Renombra Valores 2: Cambiamos el nombre a los parámetros para que tengan un nombre más identificativo. - Output a Litebi: En este paso realizamos la asociación de los campos generados para las fechas con los niveles diseñados en Litebi para esta dimensión (tanto identificadores de nivel, como sus descripciones). Al tratarse de la primera carga, elegimos como modo de carga “Standard”. A continuación podemos observar la asociación de campos entre Kettle y la dimensión Tiempo. 85 Figura 33: Carga a Litebi de la Dimensión Tiempo • Dimensión Determinación: Esta dimensión compartida se utiliza en los cubos de Origen 1 y Origen 1 Global, ya que ambos comparten la misma fuente de origen y por tanto las enfermedades serán las mismas y estarán contenidas en el mismo lugar. Figura 34: Proceso ETL de la Dimensión Determinación Mostremos en detalle qué función realiza cada uno de los pasos: - Obtener enfermedades: En este caso leemos los datos de una tabla a través de una consulta SQL para obtener las enfermedades (los datos no se generan de la nada como en el caso anterior). Para ver el código SQL asociado ver Anexo 3. - Enfermedad Des Null: Comprobar si la enfermedad posee un nombre y si no lo tiene ponerle un valor por defecto. - Obtener Métodos: Lectura de todos los métodos que se realizan para obtener las enfermedades. 86 - Añadir Método: Asociamos a cada una de las enfermedades el método de análisis que le corresponde. - Concatenar códigonombre: Se crea una nueva variable para obtener la enfermedad como “código-nombre” (demandado este formato por el cliente). Para ver el código ir al Anexo 3. - Método Des Null: Si no existe un método asociado a una enfermedad le ponemos como método “Desconocido”. - Selecciona Valores: Seleccionamos los valores que finalmente nos interesan para la dimensión. - Tipado: Le damos un tipo de datos a los valores o se lo cambiamos, le damos una longitud, un nuevo nombre…etc. - Output a Litebi: Asociamos los valores obtenidos con los niveles de la dimensión Determinación, teniendo en cuenta que los valores a asociar deben tener el mismo tipo que se le puso a los niveles en el diseño. Aquí podemos observar cómo queda la asociación de los campos. Figura 35: Carga a Litebi de la Dimensión Determinación • Dimensión Reg: Esta dimensión compartida se considera la más importante de todas, ya que deberá contener los registros de muestras y todos sus atributos o características. Esta dimensión será utilizada en todos los cubos. Se trata de un proceso ETL complejo que trataremos de exponer de la forma más sencilla posible: 87 Figura 36: Proceso ETL de la Dimensión Registros Detallemos sus pasos brevemente: - Obtener Muestras: Lectura de la tabla “Muestras” de los datos asociados a cada una de las muestras, así como los datos del cliente que solicita el análisis y los datos de la explotación de donde proviene. - Obtener Tipo de Ave: Lectura de todos los tipos de aves existentes. - Agregar Tipo de Ave: Asociación del tipo de ave correspondiente a cada muestra. - Obtener cod municipio: Código Java Script donde se extrae el código del municipio de donde proviene la muestra a partir del código de la explotación según el formato REGA. Además al código de la explotación se le concatena el nombre de su dueño. Código en Anexo 3. - Filtrar: Dejar pasar sólo aquellos registros que cumplen con el formato REGA del código de explotación. - Dummy: Desecho de los registros que no cumplen el formato REGA. 88 - Tipo Ave Des: Si el tipo de ave no se asocia con ninguno de los existentes en la base de datos lo trataremos como “Desconocido”. - Origen Des: Mismo caso que el anterior pero para el campo Origen. - Tipado 1: Se formaliza el tipo de dato y la longitud para cada uno de los campos seleccionados. - Obtener Municipio: Lectura del fichero de Access que contiene la codificación geográfica a través de una conexión ODBC (se intentó primero utilizando el paso de Input Access que viene el Kettle pero ocurrían errores de lectura). En este paso obtenemos los datos necesarios para relacionar los municipios. La consulta la podemos observar en el Anexo 3. - Obtener Comarca: Mismo caso que el anterior pero obtenemos los datos de las comarcas. - Obtener Provincia: Obtenemos los datos de las provincias del fichero Access para los mapas. - Obtener Comunidad: Lectura de los datos de comunidades autónomas. - Añadir Municipio: Relacionar el código de municipio obtenido a través del código d explotación con el código de municipio que se tiene en los mapas para asignarle a cada muestra su nombre. - Añadir Comarca: A partir del municipio obtenemos la comarca asociada a él (cabe destacar que solamente se desarrollaron los mapas a nivel de comarca para la Comunidad Valenciana). - Añadir Provincia: Añadimos la provincia de cada muestra a partir de su municipio. - Añadir Comunidad: De la misma manera se obtiene la comunidad asociada al municipio. - Municipio Des, Comarca Des, Provincia Des, Comunidad Des: Si alguno de estos campos no existe lo trataremos como “Desconocido” - Formato: Renombramos los campos con nombres más significativos. - Tipado 2: Volvemos a dar formato únicamente a los campos que hemos ido añadiendo nuevos. 89 - Profesional Des: Si el campo “Profesional” es nulo lo tratamos como “Desconocido”. - Obtener Profesional: Obtenemos los datos de los profesionales que analizan las muestras. - Añadir Nombre Profesional: Se relaciona el código de profesional (NIF) para obtener el nombre completo de la persona. - Output a Litebi: Igual que en los casos anteriores, relacionamos todos los campos obtenidos con los niveles de la Dimensión. Cabe apuntar que los niveles asociados a municipio, comarca, provincia y comunidad tienen lo que se llama un identificador geográfico que es necesario para la generación de los mapas (esto se definió a la hora de definir la dimensión en Litebi). Figura 37: Carga a Litebi de la Dimensión Registros 96 - Ver si tiene e, Ver si tiene e 2: Comprobar si el resultado está en formato científico (Ej. 6e2). - Con /: Paso intermedio. - Separar e: Separar el número en base y exponente. - Separar /: Por delante de la barra son los positivos, por detrás los totales. - Multiplicar base: Obtener el resultado numérico en coma flotante. Ver código en Anexo 3. - Numérico puro, Numérico puro 2: Juntamos todos los registros que tienen un resultado transformado ya como un número. - Es textual: Guardar el resultado si es un texto en una variable. var RESULTADO_TEXTUAL = RESUL_VALOR.getString(); - Selecciona valores, Selecciona valores 2,…, Selecciona valores 5, Ordenar: Renombrar, seleccionar, dar formato y seleccionar el tipo de los campos que sean necesarios. - Añadir constante, Añadir constante 2,…, Añadir constante 4: Añadir constantes como si los resultados son positivos o totales. Esto se hace porque hora de unir todas las ramas de flujo de información en un mismo punto estamos obligados a que por todas las ramas vengan los mismos campos. En el paso 4 es donde se añade la variable contador para llevar el número de muestras. - Obtener muestras: Leer los datos asociados a las muestras. - Añadir datos muestras: Completar los registros añadiendo más datos relacionados con las muestras. - Tipado: Seleccionar los valores necesarios para la carga. - Output a Litebi: Asociamos los datos con las dimensiones y los indicadores del cubo. 97 Figura 45: Carga a Litebi del Cubo Resultados Origen 1 Global 8.3 Codificación geográfica Para la generación de mapas con Litebi se generó una base de datos en Access siguiendo las indicaciones del departamento de sistemas. Como podemos ver el en Anexo 1, Litebi se comunica con una aplicación SIG open source llamada Geoserver, la cual proporciona los servicios de generación de mapas a Litebi. Se acordó llevar una codificación para los mapas basada en los códigos impuestos para cada municipio, provincia y comunidad autónoma por el Instituto Nacional de Estadística (INE). De esta manera la composición de la base de datos que daría soporte a los mapas sería mucho más sencilla de construir a partir de ficheros Excel obtenidos desde la web del INE (http://www.ine.es/). Vamos a describir los diferentes elementos de la base de datos para que quede claro como Litebi utiliza estos ficheros para comunicarse con Geoserver. Existen tres tablas las cuales se describirán a continuación: 98 - Tabla Layers: Posee las diferentes capas en las que se puede dividir un mapa geográfico así como el código que identifica a cada capa. Figura 46: Tabla Layers de la base de datos de Litebi-Geoserver - Tabla Polygons: Tabla maestra donde se recogen diferentes lugares geográficos distinguidos según la capa. Están identificados por un Litebiid que es el campo que se asocia con el nivel geográfico en Litebi y poseen un campo Polygonid que es aquel que identifica el polígono que Geoserver deberá mostrar por pantalla. El campo LitebiParentId identifica al padre inmediatamente anterior del elemento, por ejemplo si estuviésemos en una provincia el LitebiParentId identificaría la comunidad asociada a esa provincia. Figura 47: Tabla Polygons de la base de datos de Litebi-Geoserver 99 - Tabla Padre_Hijo: Esta tabla se realizó para sacar con una simple consulta todas las capas padre que posee un elemento concreto. Por ejemplo buscando un municipio en concreto puedo obtener cuál es su comarca, su provincia y su comunidad en una misma consulta utilizando esta tabla y la de Polygons. Figura 48: Tabla Padre_Hijo de la base de datos de Litebi-Geoserver Por tanto queda claro que para alimentar de datos los niveles geográficos de las dimensiones y generar los mapas sólo basta con realizar la asociación a estas tablas, con los datos que estemos trabajando, a través de unas simples consultas donde obtengamos el LitebiId, que se comunicará con Geoserver haciendo la correspondencia internamente con el PolygonId asociado y mostrando el polígono por pantalla de la zona deseada. 8.4 Procesos ETL Incrementales Una vez construidos todos los procesos de extracción, transformación y carga de información sólo queda ejecutarlos para que tengamos los cubos y las dimensiones cargados con los datos que se poseen actualmente en el centro. Para ello cabe destacar que, al ser la primera vez que se cargan datos, es recomendable seleccionar 100 en todos los pasos de “Output a Litebi” la opción de carga “Standard”. La ejecución de cada uno de los procesos se realiza pulsando sobre el botón “Play”, situado en la parte superior de la ventana de diseño de Kettle. La carga se debe realizar en este orden obligatoriamente, primero cargaremos las dimensiones y luego los cubos, ya que estos últimos dependen de las dimensiones. Por fin tenemos nuestras estructuras de datos rellenadas con información. Este proceso de carga de datos suele durar bastante tiempo, y de momento, sólo se había conseguido cargar datos una vez, cosa que no es suficiente. ¿Cómo podríamos mantener los datos actualizados constantemente sin necesidad de recargar todos los datos cada vez? Esta pregunta es bien sencilla de responder, utilizando cargas incrementales. Las cargas incrementales vienen a ser pequeñas modificaciones sobre los procesos ETL que únicamente permitan cargar datos de los últimos 15 días, del último mes, del último año…etc. De esta manera con la primera carga poseemos los datos que ya existen en la actualidad y con las cargas incrementales podríamos actualizar los datos añadiendo aquellos que día a día se vayan generando, en cuestión de pocos minutos. Explicaremos brevemente las pequeñas modificaciones que se realizaron en cada uno de los procesos ETL para conseguir las cargas incrementales que mejoraron el rendimiento de la actualización de datos. - En las dimensiones compartidas “Determinación” y “Tiempo” se optó por dejarlas como cargas estándar, ya que se realizaban en un corto plazo de tiempo y se observaron una serie de problemas en los datos si estas dimensiones se cargaban de manera incremental. - Dimensión Reg: En el paso de “Obtener Muestras” se añadió una condición en la consulta SQL que limitará los datos obtenidos a los del último mes según la fecha oficial. Esta expresión era: WHERE add_months(SYSDATE,-1)<=FECHA_OFICIAL. - Cubo Resultados Origen 1: En el paso de “Obtener Resultados Origen 1” se añadió una expresión a la consulta SQL para obtener la fecha de hace un mes y se le llamo como HOY ( add_months(SYSDATE,-1) as HOY). Como todavía no se tenía 101 ninguna fecha con la que comparar en el primer paso, tuvimos que realizar este filtrado de información justo un paso antes de cargar los datos en Litebi por medio de un paso de filtrado y una condición FECHA_OFICIAL => HOY. - Cubo Resultados Origen 2: Este caso fue el más complicado de tratar. A partir del nombre que tenía cada hoja de Excel, según el formato indicado al cliente para cada archivo, se obtuvo un nuevo campo con el nombre del fichero o de la hoja (era el mismo en ambos casos) llamado FECHA_HOJA. A partir de este campo se generó un paso de Java Script donde obtener campos para el año y el mes actual, y el año y el mes del fichero Excel. Una vez obtenidos estos campos, se realizaba un paso de filtrado dejando pasar aquellos ficheros de Excel que fuesen como mucho de hace un mes. Podemos observar el código y las condiciones en el Anexo 3. - Cubo Resultados Origen 3: Se utilizó el mismo recurso que para el caso del Cubo de Resultados Origen 1. - Cubo Resultados Origen 1 Global: Se utilizó la misma condición que para la dimensión Reg pero en el paso “Obtener Resultados Origen 1” WHERE ( add_months(SYSDATE,-1)<=FECHA ). Gracias a esto, las cargas de datos se realizaban en tiempos mucho menores, ya que únicamente se cargaban los datos del último mes en todos los cubos. El último paso a tener en cuenta era que para todos los pasos de “Output a Litebi” esta vez la opción de carga a escoger debería ser “Actualizar datos”, de esta manera los datos antiguos se mantienen en los data marts, los que ya estaban se sobreescriben y los nuevos se añaden. 8.5 Cargas periódicas Al realizarse los procesos de transformación de datos de manera incremental se solventó el problema del coste computacional que suponía trabajar con una gran cantidad de datos día tras día para mantenerlos actualizados. El próximo objetivo a conseguir era que la actualización se realizara de manera automática sin necesidad de 102 acción humana y sobretodo que se realizara fuera de horas de trabajo para no sobrecargar el sistema. Para conseguir este objetivo se diseñaron los Jobs, procesos que automatizaban las cargas periódicas de datos y que ejecutaban de manera secuencial cada una de las transformaciones de datos anteriormente diseñadas. Este paso se compone de tres jobs: uno para cargar todas las dimensiones compartidas, otro para cargar los cubos y otro que ejecutará a estos dos de manera secuencial, es decir, un job general. A continuación se muestra el diseño de estos tres procesos: Figura 49: Job de carga de dimensiones compartidas Figura 50: Job de carga de cubos OLAP Figura 51: Job de carga de información general Como se puede observar en los diagramas, cada uno se comunica y ejecuta los procesos ETL que se han diseñado (pasos con un aspa verde) ya sean cubos o dimensiones. El último diagrama es el job general, el cual se comunica con los dos anteriores (pasos en naranja llaman a otros jobs). De esta manera tenemos comunicación con todos los procesos que engloban la solución en un solo fichero o diagrama de flujo. 103 Como se puede observar en el diagrama del job general, existen dos líneas de flujo de información, una activa y otra inactiva. La inactiva se refiere a las cargas estándar de datos (cargados los datos una vez, se eligió la opción de carga “Borrar datos primero” para estos casos en los “Output a Litebi”) la cual se dejó como recurso de emergencia por si en las cargas incrementales ocurría algún error. La línea de flujo activa hace referencia a las cargas incrementales realizadas en el apartado anterior y será la línea de flujo principal para cada carga diaria que se ejecute. Estos procesos se pueden ejecutar de manera manual o de manera automática preferiblemente, utilizando la herramienta KITCHEN de Kettle en un pequeño script y ejecutando este script como tarea programada del sistema con la periodicidad que nosotros le asignemos. Este fichero llamado li_run.bat se componía de la siguiente línea de script: kitchen /file/:ETL/GENERAL.kjb /level:basic > li_run.log Con este simple script se conseguía ejecutar el job general sin necesidad de abrir Kettle y además podíamos observar los fallos que se produjeran durante la carga de datos en un archivo log donde aparece toda la información de la ejecución del proceso. Una vez realizado este script solamente nos quedaba darle una periodicidad de ejecución a través de una sencilla tarea programada de Windows. Para realizar una tarea programada vamos a Inicio>Programas>Accesorios>Herramientas del Sistema>Tareas Programadas y agregamos una tarea nueva diciéndole el archivo a ejecutar, la hora y los días que queremos que se ejecute. En este caso se definió a las 2:00 diariamente para tener así los datos actualizados de manera que se recargaran cuando nadie estuviese utilizando el sistema. 104 Figura 52: Tarea programada automática li_run 8.6 Miembros calculados y conjuntos El último paso en la composición de esta solución de BI, fue definir en Litebi los miembros calculados y los conjuntos necesarios para la realización de los informes del centro. Como se explica en el Anexo 1, los miembros calculados y los conjuntos son datos que se pueden calcular a partir de los datos existentes en los cubos a través de fórmulas multidimensionales en lenguaje MDX. Litebi posee una forma muy sencilla de generar estos elementos a través de un editor de fórmulas. De esta manera el usuario no necesita conocer todos aquellos aspectos técnicos del lenguaje, sino que gracias al editor podemos hacernos una idea de la construcción de las fórmulas y las operaciones que realizan cada una de sus funciones. Para el caso de CECAV se definieron dos miembros calculados y dos conjuntos que explicaremos a continuación: Figura 53: Miembros calculados de la solución en Litebi - Número Explotaciones Analizadas: Como se había definido al identificar las necesidades de información del cliente, este factor era uno de los importantes, pero no teníamos la posibilidad de obtenerlo a nivel de ETL dada su complejidad. 105 Esta fórmula se aplicó a todos los cubos, ya que era necesario obtener este dato para cualquier fuente de análisis de muestras. A continuación se muestra la fórmula generada en lenguaje MDX puro (los números hacen referencia a los identificadores en base de datos de Litebi para las dimensiones) para el cálculo de este elemento (cabe destacar que el nivel Explotación estaba presente en varias jerarquías y por tanto era necesario evaluarlas todas en la fórmula): IIF( NOT ( ( [123557892_123636908_47.123636908].CurrentMember IS [123557892_123636908_47.123636908].[Total] ) ) , COUNT( Filter(Descendants([123557892_123636908_47.123636908].CurrentMember,[1235 57892_123636908_47.123636908].[123634104]), NOT ( IsEmpty ( [Measures].[123601004_Sum] ) ) ) ) , IIF( NOT ( ( [123557892_123635163_47.123635163].CurrentMember IS [123557892_123635163_47.123635163].[Total] ) ) , COUNT( Filter(Descendants([123557892_123635163_47.123635163].CurrentMember,[1235 57892_123635163_47.123635163].[123634104]), NOT ( IsEmpty ( [Measures].[123601004_Sum] ) ) ) ) , IIF( NOT ( ( [123557892_123636907_47.123636907].CurrentMember IS [123557892_123636907_47.123636907].[Total] ) ) , COUNT( Filter(Descendants([123557892_123636907_47.123636907].CurrentMember,[1235 57892_123636907_47.123636907].[123634104]), NOT ( IsEmpty ( [Measures].[123601004_Sum] ) ) ) ) , IIF( NOT ( ( [123557892_123634103_47.123634103].CurrentMember IS [123557892_123634103_47.123634103].[Total] ) ) , COUNT( Filter(Descendants([123557892_123634103_47.123634103].CurrentMember,[1235 57892_123634103_47.123634103].[123634104]), NOT ( IsEmpty ( [Measures].[123601004_Sum] ) ) ) ) , COUNT( Filter(Descendants([123557892_123636908_47.123636908].CurrentMember,[1235 57892_123636908_47.123636908].[123634104]), NOT ( IsEmpty ( [Measures].[123601004_Sum] ) ) ) ) ) ) ) ) - Número Registros Analizados: Para los casos en los que los registros se dividen en muestras, a nivel de ETL era posible calcular el número de muestras pero no 112 cuales utilizarían la aplicación como una herramienta únicamente de consulta de información para obtener de un simple golpe de vista información sobre los análisis que se realizan en el centro. Desde la pestaña de configuración de Litebi se crearon dos roles: - Usuario: Este rol de usuario se agregó a todos los cubos generados con permisos de lectura sobre ellos. No se dotó de permisos en escritura y eliminación para evitar problemas. - Agroalimed: Rol especial para ciertos usuarios que solo tendrían acceso a una serie de carpetas de la aplicación con el fin de observar los informes que se ubicaran en ellas. Una vez creados los roles se les proporcionó acceso a las personas que iban a ocupar esos roles. A cada usuario se le proporcionó un nombre de usuario (coincidente con su dirección de correo electrónico, normalmente para hacerlo de manera estandarizada) y una contraseña de acceso a su elección. Las personas ubicadas en el centro (investigadores y dirección) se agregaron al rol de “Usuario” y personas ajenas a la organización a las cuales se les creó un usuario se ubicaron en el rol de “Agroalimed” (aquí se situaban clientes y dueños de explotaciones sobre todo). Figura 59: Usuarios y Roles de la solución 113 9.3 Planificación de Informes Otorgando a los usuarios permisos de acceso y habiéndoles proporcionado una formación sobre la aplicación fueron capaces de explotar sus funcionalidades, como la planificación del envío de informes. Gracias a esta funcionalidad se les proporcionó mayor independencia para la consulta de información, no siendo necesario acceder continuamente a la aplicación. La planificación de informes es bien sencilla (como se puede ver el en Anexo 1) consiste en enviar aquellos informes que planifiquemos a una serie de personas en un periodo concreto. Estos informes pueden llegar al correo electrónico del destinatario en los diferentes formatos de exportación que la aplicación ofrece: Excel, PDF o una url con el enlace directo al informe sobre la aplicación por si se desea realizar modificaciones o explorarlo en detalle (este tipo de envío requiere que el usuario destinatario posea permisos de acceso a la aplicación). En primera instancia se planificaron una serie de informes en los días de formación que sirvieran como ejemplo y de utilidad para el cliente. 114 10 CONCLUSIONES Aún a falta de observar la evolución en el tiempo de la solución implantada, se puede asegurar que se cumplieron los objetivos propuestos y además se dotó a la empresa de un sistema de inteligencia de negocio fácil, potente y asequible. Esta implantación ha servido para observar y corroborar de primera mano la gran utilidad de estos sistemas en las organizaciones así como mostrarlo como escaparate para posibles futuras implantaciones, ya que se trata de un caso de éxito claro. En la solución se han aprovechado todas las capacidades y las herramientas de las que dispone Litebi en la actualidad, siendo posible mayor funcionalidad en un futuro, aumentando así la inteligencia de negocio de la organización. Se ha demostrado la potencia de acceso a la información, al acceso a los cubos y al diseño de informes, y lo más importante, las posibilidades de acceso vía portal web a toda la información. CECAV quedó totalmente satisfecha de la usabilidad, fiabilidad y robustez que ha ofrecido esta tecnología. Los usuarios destacaron sobre todo la rapidez y la calidad de los informes generados (destacando enormemente los informes a nivel geográfico), así como un aumento de la comunicación por parte de los diferentes laboratorios con la dirección del centro. Gracias a esta solución se eliminó completamente la dependencia de los anteriores sistemas heterogéneos de reporte, integrando toda la información de los análisis de los laboratorios de la organización en un único lugar, más potente, rápido, sencillo y fiable. Además cabe destacar la escalabilidad de la solución, que permitirá en un futuro de una forma sencilla, disfrutar del sistema a otros departamentos, si se diera el caso, así como a otras áreas de la empresa (finanzas, producción, administración…etc.). A nivel personal y profesional debo decir que este proyecto me ha aportado muchos conocimientos y muchas ganas de seguir por el camino de la inteligencia de negocios, ya que me ha parecido realmente apasionante. Este proyecto me ha permitido jugar diferentes roles a lo largo de su desarrollo, tanto técnicos como empresariales, adquiriendo una experiencia que pienso que me será realmente útil en mi futuro profesional. 115 11 BIBLIOGRAFÍA [1] Análisis Business Intelligence “Varios artículos” (Mayo – Junio 2010) http://analisisbi.blogspot.com/ [2] Emilio Arias “Éxito en la implantación de un sistema Business Intelligence” (Mayo 2010) http://www.monografias.com/trabajos29/sistema-business-intelligence/sistemabusiness-intelligence.shtml [3] Bi-Spain.com “¿Qué es el Corporate Performance Management? Scoreboards, Business Intelligence y Enterprise Planning” (Junio 2010) http://www.bi-spain.com/ [4] Carlos Borrás “Business Intelligence” (Mayo 2010) http://firmas.lasprovincias.es/carlosborras/business-intelligence/ [5] Business Intelligence.com: The Resource for Business Intelligence (Mayo – Junio 2010) http://www.businessintelligence.com/ [6] CECAV Centro de calidad avícola y alimentación animal de la Comunidad Valenciana (Junio 2010) http://www.cecav.es [7] Corporate Information Factory (CIF) Resources by Bill Inmon (Junio 2010) http://www.inmoncif.com/home/ [8] CRM, BI, Call Center, Customer Data: News, Experts & Learning Guides (Junio 2010) http://www.searchcrm.com [9] Luz María Duarte Barroso “Importancia del ERP en las corporaciones” (Mayo 2010) http://www.gestiopolis.com/canales3/ger/impoerporg.htm [10] Garnett, Jody y Pumphrey, Mike “Geoserver” (Junio 2010) http://geoserver.org/display/GEOS/Welcome [11] Santiago Gracía Esteban (Valencia, 1996) “Proyecto de final de carrera: Análisis de la implantación de una sistema de información, en una empresa del sector de la automoción” Editado por la UPV [12] Ibermática “Business Intelligence. El conocimiento compartido” (Mayo 2010) http://lam.e-gim.net/gimmaster/ftp_lam/docs/articulobusinessintelligence.pdf 116 [13] Bill Inmon vs. Ralph Kimball (Mayo 2010) http://www.1keydata.com/datawarehousing/inmon-kimball.html [14] Instituto Nacional de Estadística (Marzo 2010) http://www.ine.es/ [15] Lite Internet Solutions S.L. Litebi. “Litebi” (Enero -Julio 2010) http://www.litebi.com [16] Lite Internet Solutions S.L. Litebi. “Plan de negocio” (Documentación interna) [17] Lite Internet Solutions S.L. Litebi. “Manual de usuario” (Documentación interna) [18] Alfonso López “Balanced Scorecard” (Junio 2010) http://www.ciberconta.unizar.es/LECCION/bsc/INICIO.HTML [19] Ministerio de administraciones públicas “El Data warehouse” (Mayo 2010) http://www.csi.map.es/csi/silice/DW1.html [20] Monografias.com “Data mining” (Junio 2010) http://www.monografias.com/trabajos/datamining/datamining.shtml [21] Nase, Inteligencia de Negocios “5 pasos para lograr un proyecto de Business Intelligence exitoso” (Junio 2010) http://www.nase-it.com/pdf/PasosparaBI.pdf [22] Pentaho Data Integration “Kettle Documentation” (Enero – Mayo 2010) http://wiki.pentaho.com/display/EAI/Latest+Pentaho+Data+Integration+(aka+Kettle)+D ocumentation [23] J.E.Pereira “Cuadro de Mando Integral, CMI” (Junio 2010) http://www.mercadeo.com/41_scorecard.htm [24] Javier Racca “La hora del BPM” (Junio 2010) http://www.tynmagazine.com/641-La-hora-del-BPM.note.aspx [25] Dolors Reig “¿Qué es el Cloud Computing?” (Junio 2010) http://www.dreig.eu/caparazon/2008/10/30/¿que-es-el-cloud-computing-definiciontendencias-y-precauciones/ [26] Sales force (Junio 2010) http://www.salesforce.com 117 [27] Sinnexus “Business Intelligence” (Mayo 2010) http://www.sinnexus.com/business_intelligence/index.aspx [28] TodoBI <business intelligence> “Los 10 factores clave de un sistema BPM” (Junio 2010) http://todobi.blogspot.com/2005/09/los-10-factores-clave-de-un-sistema.html [29] Elizabeth Vitt, Michael Luckevich, Stacia Mismer (2003 – McGraw-Hill) “Business Intelligence. Técnicas de análisis para la toma de decisiones estratégicas” [30] Wikipedia (Mayo - Junio 2010) http://es.wikipedia.org 118 ANEXO 1: PLATAFORMA BI SAAS, LITEBI 1 MÓDULOS Y CARACTERÍSTICAS BÁSICAS Litebi es una aplicación Web que permite integrar datos de cualquier origen de datos, relacionarlos entre ellos y disponer de potentes posibilidades de análisis más allá de las posibilidades actuales de la inteligencia de negocios. Se trata de una completa plataforma SaaS de Inteligencia de negocios basada en cubos OLAP, Reportes, Cuadros de Mando y una Herramienta ETL de integración de datos. Esta plataforma BI permite definir un data warehouse completo, o simplemente cargar y analizar datos de un excel en pocos minutos. La funcionalidad de Litebi está dividida en módulos y varía desde funcionalidades de comprobada eficacia como sistemas OLAP y Cuadros de Mando, hasta tecnologías innovadoras y propias que hacen de Litebi una herramienta de Inteligencia de negocios de nueva generación, cómo el uso de técnicas de integración de información, inteligencia artificial o web semántica aplicadas a la toma decisiones empresariales. 1.1 liteSpace Es el diccionario de datos de Litebi, contiene datos y estructuras de metadatos que serán utilizadas en los procesos de análisis de información por el usuario, divididos en dos familias: • Estructurados: Cubos y dimensiones para el análisis OLAP y la minería de datos (todavía no disponible). Enfocados al análisis cuantitativo. • No estructurados: Para análisis semánticos, textuales y de contenido. Enfocado al análisis conceptual. Una característica fundamental de liteSpace es la posibilidad de que el usuario, de forma sencilla y visual defina su propio diccionario de datos, creándose 119 automáticamente las estructuras físicas y lógicas necesarias para albergar la información. Esta innovación supone un gran salto respecto al modo tradicional de desarrollar sistemas de BI (en concreto las tareas relativas al diseño e implementación de Data Warehouse) y supone una gran diferencia respecto a sus competidores. Algunas de las características principales de este módulo son las siguientes: - Cada cliente dispone de su propio liteSpace (espacio) con sus datos analíticos (Cubos) e informes (Vistas de análisis). - Editor de Cubos y Dimensiones: Permite definir los modelos analíticos en los que se cargaran los datos. - Seguridad basada en roles. - Sistema de gestión de contenidos que permite organizar los elementos de análisis en carpetas. Cada usuario posee unas carpetas privadas de uso personal y existe un espacio compartido de carpetas públicas. 120 Figura 60: liteSpace (Sistema de archivos y carpetas) Figura 61: liteSpace (Editor de cubos) 121 1.2 liteIntegrator Herramienta de integración de datos basada en la popular y potente herramienta de ETL Open Source Kettle de Pentaho, que pretende llevar la integración de información en organizaciones al entorno actual, en el que cada vez hay más información distribuida en múltiples formatos y fuentes en Internet, que una organización bien informada ha de tener en cuenta junto con los orígenes de datos existentes en sus sistemas. Este módulo permite: - Definir procesos para integrar, transformar y preparar la información para ser analizada en liteSpace, capaces de ejecutarse de forma periódica en la plataforma de Litebi. - Integrar datos provenientes de la infraestructura del cliente, situados “detrás del firewall”. Por ejemplo: BBDD corporativas, CRM, ERP, ficheros excel, texto plano…etc. - Integrar datos provenientes de origenes situados en internet: Por ejemplo: Otras aplicaciones SaaS, Plataformas de Cloud Computing, Feeds RSS, servicios web…etc. - Integrar datos estructurados (Orígenes relacionales, XML, RSS) y no estructurados (Webs, PDFs, Texto…etc.). liteIntegrator está compuesto de tres componentes fundamentales: 1. Capa Servicios Web: Desarrollados usando la tecnología AXIS2, permiten carga a través de canales securizados de datos en liteSpace desde cualquier lugar a través de Internet. Suponen la base para la construcción de una API de Servicios Web que permita embeber con facilidad la funcionalidad de Litebi en productos de terceros, apoyando la línea de negocio de OEM partners. 128 que permite construir de forma sencilla procesos de integración de datos muy potentes. A este conjunto, que nos permite integrar la información que se desea analizar, se le denomina liteIntegrator. 3. Analizar una vez los datos residen en liteSpace, se cuenta con una herramienta de reporting avanzado (OLAP) con la que el usuario final puede, de forma muy sencilla y potente analizar desde cualquier punto de vista la información y generar sus propios informes que pueden ser compartidos a lo largo de toda la organización. Es el fin de los informes hecho a medida o el caos semi-gestionado a base de excels. Para almacenar la información necesaria para el funcionamiento de Litebi, se tiene actualmente por un lado en la base de datos lo referente a la configuración de cada espacio y la estructura de los diferentes modelos analíticos y por otro lado los datos cargados de fuentes externas mapeados para cada modelo analíticos diseñado en Litebi. 129 2 DESARROLLO DE SOLUCIONES CON LITEBI En esta sección trataremos de ilustrar de qué manera se diseña e implementa una solución de BI con Litebi siguiendo los tres pasos fundamentales a través de sus diferentes módulos: - Definir modelos analíticos con Litebi: Diseño de cubos y dimensiones. - Cargar datos en esos modelos analíticos. - Cómo utilizar las herramientas de análisis. Cabe destacar que la información contenida en este apartado estará destinada a consultores y partners encargados de desarrollar soluciones de BI con Litebi. En el siguiente apartado se mostrara la aplicación desde la perspectiva del uso a cargo del cliente. 2.1 Definir: liteSpace Internamente Litebi utiliza los conceptos tradicionales del modelado dimensional en Business Intelligence, veamos algunas definiciones: - Cubo: Elemento fundamental de liteSpace. Conjunto de datos organizado orientado al análisis, estructurado de forma dimensional. Los cubos están formados por métricas (measures) y dimensiones. Ej. Cubo de ventas, Cubo de contabilidad…etc. - Métrica: Cantidades numéricas que deseamos controlar en un cubo. Es lo que aparece en las celdas al analizar un cubo. Ej. Cantidad vendida, Cantidad facturada, Precio unitario…etc. - Dimensión: Punto de vista de la información que deseamos en el análisis. Ej. Dimensión geográfica (¿dónde sucedió la venta?), Dimensión Cliente (¿a quién le vendí?), Dimensión Producto (¿Qué vendí?). Las dimensión pueden ser compartidas (entre varios cubos) o embebidas (pertenecientes a un sólo cubo). 130 - Jerarquías: Una dimensión puede tener una o varias jerarquías, una jerarquía es un conjunto de niveles cada uno expresando un nivel de profundidad en la información. Permiten analizar la información de forma agrupada (ventas por año) o al detalle (ventas diarias). Ej. La dimensión tiempo está formada por la jerarquía “Por Trimestre”, que tiene los niveles “Año > Trimestre > Mes > Día”. Es posible separar cada una de las jerarquías definidas en una dimensión compartida como dimensiones compartidas nuevas y así ganar potencia y flexibilidad a la hora de analizar los datos. En el centro de Litebi se encuentra liteSpace, que es como un "espacio analítico" o un "Data Warehouse gestionado". La idea es bien sencilla, ser capaz de ofrecer las ventajas de un Data Warehouse clásico (responder a las necesidades analíticas del cliente, integrar información de cualquier origen, dar cobertura a toda la organización, etc.) pero sin la complejidad, el riesgo y el coste qué este tipo de proyectos suelen conllevar. Gracias al modelo SaaS se elimina la necesidad de gestionar el Data Warehouse por el cliente (y el hardware, y el despliegue...), y en parte gracias a que se tiene una tecnología capaz de permitir a cualquiera definir el "qué" quiere analizar a través de interfaces web (modelos dimensionales) y dejar que sea Litebi el que haga todo el trabajo duro entre bastidores (construcción de modelos, optimización de los mismos, diseño de metadatos…etc.). 131 Figura 67: Explorando un cubo con liteExplorer 2.1.1 Definiendo un cubo Para definir cubos en Litebi, debemos situarnos sobre la pestaña Datos de nuestro LiteSpace y utilizar el editor de cubo. Un cubo coincide a grandes rasgos con el concepto de “tabla de hechos” en un modelo en estrella tradicional. Figura 68: Creando un nuevo cubo en liteSpace 132 Una vez creado el nuevo cubo, el funcionamiento es muy sencillo: - A la izquierda tenemos un árbol con la estructura del cubo, a la derecha las propiedades del elemento seleccionado. - Podemos cambiar el nombre del cubo y su definición. - Podemos crear nuevas métricas y definir para cada métrica: o Nombre y descripción o Formato: Sigue el estándar de Java (#,###,###.0) o Agregador: Las formas de agregación que deseamos para la métrica al totalizarla (que se sume, que se haga la media de los hijos, que se escoja el máximo o el mínimo de los hijos) o El tipo de datos (habitualmente Integer o Number para una métrica). - Podemos crear dos tipos de dimensiones: o Compartidas: Indicamos que el cubo utilizará una dimensión compartida (definida aparte en la carpeta Dimensiones, ap. 3.1.2) y fijamos un alias para el uso. Es posible utilizar una misma dimensión en un cubo más de una vez (ej: Fecha de venta, Fecha de entrega utilizando la dimensión compartida Tiempo). o Embebidas: Son dimensiones que sólo existen para un cubo en concreto. Es habitual utilizarlas para definir propiedades (Ej. Estado de una factura) o simplemente para simplificar el modelado. Al crear una dimensión embebida podemos:  Definir su nombre y descripción  Especificar si tiene “Total” es decir un elemento superior que totalice toda la estructura actuando cómo cúspide de la jerarquía  Una serie de niveles de detalle que forman una única jerarquía. Para cada nivel podemos definir • Nombre y descripción 133 • Tipo de datos del nivel (de la columna código) • Si tiene columna descripción (siempre es de tipo String). Para más información sobre las columnas código y las columnas descripción de un nivel ver edición de dimensiones compartidas. • Además cada nivel puede tener una serie de propiedades asociadas (Ver edición de dimensiones compartidas) Figura 69: Editando un cubo - Miembros calculados y Sets: Permiten realizar cálculos avanzados y cálculo de conjuntos sobre los objetos del cubo, utilizan el lenguaje MDX (Multidimensional Expressions) y es posible definir desde cálculos sencillos (Facturación = Precio unitario * Cantidad vendida) hasta fórmulas complejas (Incrementos entre periodos 134 de tiempo, porcentajes del total, y un amplio etc.). La edición de miembros calculados requiere de un conocimiento del lenguaje MDX a priori (aunque con la ayuda del editor de fórmulas se simplifica) y queda fuera del ámbito del presente manual. Aquí el manual sobre el lenguaje: MDX Language Reference http://msdn.microsoft.com/en-us/library/ms145595.aspx 2.1.2 Definiendo una dimensión compartida Desde el Diccionario de Datos de Litebi es posible definir dimensiones compartidas que serán utilizadas por diferentes cubos. Típicamente en los proyectos hay dimensiones (Estructuras jerárquicas) que son utilizadas en varios cubos (sets de datos) cómo por ejemplo la dimensión temporal. Es recomendable siempre que sea posible crear dimensiones compartidas para los cubos, ya que incrementa la facilidad de trabajo en el análisis de éstos. 135 Figura 70: Creando una dimensión Para crear una dimensión hay que seguir tres pasos: 1. Definir cuál es el nivel base de la dimensión. o El nivel base es el nivel de máximo detalle de la dimensión, el que posteriormente se utilizará para relacionar la dimensión con el cubo. o Ej. En una dimensión temporal el nivel base podría ser el día, si en el cubo tenemos la información a nivel de día. 2. Crear los niveles que van a ser usados (independientemente de las jerarquías que posteriormente los agrupen). o Ej. Año, Trimestre, Mes, Día de la semana, Semana del año, Quincena...etc. 136 o Al definir estos niveles hay que tener en cuenta que un nivel tiene dos tipos de campos o Campo Id:  Es obligatorio.  Puede ser de cualquier tipo de datos.  Define al nivel.  Ej. En el nivel “Producto” sería el “Código de producto” en el nivel “año” sería el número del año “2007”. o Campos Descripción:  Es opcional.  Siempre es de tipo String.  Si existe es utilizado para mostrar el elemento al usuario.  Si no existe se utiliza el campo Id para mostrar el elemento al usuario.  Ej. En el nivel “producto” sería el “Nombre del producto”, pero en un nivel “año” no sería necesario. Es importante tener claros estos conceptos de cara a cargar datos en liteSpace a través de liteIntegrator. 3. Definir las jerarquías: Una vez creados los niveles que van a utilizarse en la dimensión, se definen las jerarquía que los van a agrupar. o Una dimensión puede tener tantas jerarquías como se desee, para dar más alternativas de análisis al usuario. o Toda dimensión ha de tener al menos una jerarquía. o Todas las jerarquías incluyen el nivel base cómo máximo nivel de detale. o Ej. Jerarquía “Por Trimestre” formada por los niveles “Año > Trimestre > Mes > Nivel base día” 137 Figura 71: Creando niveles de una dimensión 2.2 Cargar: liteIntegrator Litebi cuenta con una potente herramienta de ETL a la que llamamos liteIntegrator, que consta de una parte que se ejecuta en el lado del cliente, la cual se apoya en la fantástica herramienta open source Kettle, y una capa de servicios web en el lado de Litebi. Es una herramienta que sirve para tomar datos de cualquier origen, mapearlos y cargarlos en los diferentes modelos analíticos definidos en Litebi para un espacio privado del usuario, además permite configurarlo de tal manera que los datos sean cargados diariamente, para siempre tener datos actualizados en los modelos analíticos. Con Litebi el objetivo es construir los procesos que obtengan la información de los orígenes deseados y los organicen de la forma deseada de manera que éstos puedan ser cargados en los cubos y dimensiones de liteSpace. 144 3 TECNOLOGÍAS UTILIZADAS EN LITEBI 3.1 Servidor de mapas Los servidores de mapas permiten la interacción con la información espacial almacenada en servidores de datos espaciales accesibles vía web. El usuario accede a la información de manera que puede visualizarla, consultarla y, en función de las características de los servidores y de los servicios prestados, descargarla o realizar análisis espaciales. El usuario se conecta a los servicios prestados por estos servidores de mapas a través de cliente tanto ligeros, aplicaciones web que permiten la consulta de estos servidores de mapas desde el navegador, como pesados, aplicaciones SIG de escritorio con módulos que permiten la conexión a servidores de mapas. Figura 76: Infraestructura servidores de mapas Para Litebi se utiliza el servidor GeoServer para el manejo de mapas dinámicos en el Visor Olap de la aplicación. 145 Geoserver es un servidor de código abierto desarrollado en Java, lo que le hace ser multiplataforma, que permite a los usuarios compartir y editar datos geoespaciales. Diseñado para la interoperabilidad, publica datos de cualquier fuente de datos espaciales con estándares abiertos. Geoserver está desarrollado sobre la base Geotools, una biblioteca de sistemas de información geográfica. Geoserver lee una variedad de formatos de datos, incluyendo PostGIS, Oracle Spatial, ArcSDE, DB2, MySQL, Shapefiles, GeoTIFF, GTOPO30, ECW, MrSID y JPEG2000. A través de protocolos estándares es capaz de generar KML, GML, Shapefile, GeoRSS, PDF, GeoJSON, JPEG, GIF, SVG, PNG y otros. Además, se puede editar datos a través de WFS transaccionales (WFS-T). Geoserver incluye un cliente integrado OpenLayers capaz de visualizar datos para obtener una vista previa. Geoserver permite la publicación eficiente de datos geoespaciales de Google Earth a través de la utilización de enlaces de red, utilizando KML. Permite utilizar las funciones avanzadas de Google Earth para incluir plantillas de salida, pop-ups, el tiempo, altura de visualizaciones, y "super-overlays". Geoserver es la implementación de referencia del Open Geospatial Consortium (OGC) para las normas Web Feature Service (WFS) y Web Coverage Service (WCS), además está certificado como servidor de alto rendimiento para Web Map Service (WMS). Geoserver es un componente básico de la Web Geoespacial. GeoServer le permite mostrar la información espacial del mundo. Implementando el estándar de la Web Map Service (WMS), GeoServer puede crear mapas en una variedad de formatos de salida. OpenLayers, una biblioteca de cartografía gratuita, está integrada en GeoServer, lo que hace la generación de mapas rápidos y fáciles. GeoServer se basa en Geotools, un conjunto de herramientas de código abierto de Java SIG. GeoServer también se ajusta al estándar Web Feature Services (WFS), que permite la participación real y edición de los datos que se utiliza para generar los mapas. 146 GeoServer es software libre. Esto reduce significativamente las barreras económicas en comparación con los productos tradicionales de los SIG. Además, no sólo está disponible de forma gratuita, también es de código abierto. Las correcciones de errores y mejoras de características en el software de código abierto están más aceleradas en comparación con las soluciones de software tradicional. GeoServer puede mostrar los datos en cualquiera de las aplicaciones de mapas populares, tales como Google Maps, Google Earth, Yahoo Maps y Microsoft Virtual Earth. Además, GeoServer puede contactar con las arquitecturas tradicionales de los SIG como ESRI ArcGIS. 3.2 Mondrian Mondrian, ahora rebautizado como Pentaho Analysis Services, es el motor OLAP integrado en la suite de Business Intelligence Open Source Pentaho. Mondrian es un proyecto Open Source, licenciado bajo la Mozilla Public License (MPL). Esta licencia es una de las “Business Friendly” lo cual implica que es de las menos restrictivas para su uso desde la mayor parte de los puntos de vista (al igual que la resto de la suite de Pentaho), permitiendo Modificar, Embeber, Modularizar, el software sin restricciones; dejando al parecer de la organización el aporte o no de los cambios realizados al proyecto. El esquema de Mondrian es el utilizado para la exploración de cubos Olap en LiteExplorer 147 Figura 77: Funcionamiento de Mondrian Mondrian se encarga de recibir consultas dimensionales (lenguaje MDX) y devolver los datos de un cubo, sólo que este cubo no es algo físico sino un conjunto de metadatos que definen como se han de “mapear” estas consultas que tratan conceptos dimensionales a sentencias SQL ya tratando con conceptos relacionales que obtengan de la base de datos la información necesario para satisfacer la consulta dimensional. Es utilizado como gestor de metadatos dimensionales para liteSpace. • Potente, rico en características. • Utilizado ampliamente por organizaciones y también, de forma embebida, en productos comerciales, incluso otras alternativas SaaS BI. • Producto sólido y altamente testado (7 años de historia) • Independiente del SGDB • Adaptable a las necesidades concretas de Litebi (Open Source) • Basado en estándares del sector (MDX, XMLA, etc.), posibilidades de interoperación con otros sistemas. 148 Figura 78: Ejemplo fichero XML con el esquema de Mondrian en Litebi 149 4 MANUAL DE USUARIO LITEBI En el presente capítulo se presentan las funcionalidades de Litebi de cara al cliente. Su objetivo es capacitar a usuarios finales para que sean capaces de utilizar y aprovechar todas las funcionalidades que Litebi otorga. En la presente sección se muestra cómo: - Manejar los menús y ventanas de la aplicación. - Crear informes multidimensionales con liteExplorer personalizados de forma sencilla incluyendo gráficas y exportaciones. - Crear cuadros de mando con liteMonitor para componer representaciones visuales integrales con diferentes puntos de vista. Ayuda a controlar el funcionamiento de la organización. 4.1 El espacio de solución: liteSpace Figura 79: liteSpace, gestión de archivos y carpetas 150 Cada usuario dispondrá de dos carpetas. Una carpeta privada y una pública. La carpeta privada será un lugar dónde podrá almacenar sus informes y cuadros de mando personales, que únicamente tendrá acceso el usuario que los haya creado. Será su espacio personal. La carpeta pública será el lugar dónde se crearán aquellos informes y cuadros de mando que se quieran compartir con el resto de usuarios. 4.1.1 Interacciones La aplicación de Litebi ha sido diseñada con un estilo Windows. Se podrá interactuar con los elementos de tu espacio con el botón derecho del ratón sobre los elementos. Al pulsar sobre el espacio vacío podremos crear: - Nueva vista: Para crear nuevos informes. - Nueva carpeta: Para crear una nueva carpeta dónde almacenar informes y cuadros de mando. - Nuevo dashboard (Cuadro de mando): Para crear nuevos cuadros de mando. Si pulsamos sobre cualquiera de los elementos ya creados se añadirán las siguientes opciones: - Explorar: En el caso de que el elemento se trate de un informe o de un cuadro de mando, con esa opción pasaremos a explorarlo. Es la misma acción que pulsando con el botón izquierdo sobre el elemento. 151 - Copiar: Copiará el elemento por si queremos tener una copia en otro lugar. - Cortar: Cortará el elemento por si queremos mover el elemento a otro lugar. - Pegar: Pegará el elemento que haya sido previamente copiado o cortado a lugar indicado. - Eliminar: Eliminará el elemento. - Propiedades: Abrirá las opciones del elemento, dónde podremos cambiar el nombre y la descripción. - Planificación: Este es un elemento muy interesante, nos servirá para planificar envíos de los informes a un correo electrónico. Lo explicaremos a continuación. 4.1.2 Planificación de correos Cómo hemos comentado en el apartado anterior, al pulsar con el botón derecho sobre un informe podremos planificar su envío programado al correo electrónico. La primera pantalla que nos aparece, que la vemos a continuación, es dónde configuraremos la programación. Primero deberemos Añadir una nueva planificación, le pondremos el nombre y descripción deseada. En el desplegable Tarea elegiremos el tipo de periodicidad que vamos a tratar. - El caso de Diariamente lo vemos en la imagen. Deberemos seleccionar cada cuantos días queremos que se ejecute. 152 Figura 80: Planificación de informes en Litebi (Planificación) - En el caso Semanalmente nos aparecerá unas nuevas opciones para elegir qué días de la semana queremos que se ejecute y cada cuántas semanas. - En el caso Mensualmente nos aparecerá también un nuevo cuadro de selección dónde podremos seleccionar los meses que se ejecutará y en qué días del mes. - También podremos hacer una selección de días más avanzada, personalizando por ejemplo el segundo domingo de los meses seleccionados. 153 En todos los casos deberemos seleccionar el día de inicio mediante el calendario, seleccionando el día, o escribiendo el día de inicio de forma manual. La siguiente pestaña de configuración es la del Correo electrónico. En ella seleccionaremos la dirección de correo destino, el asunto del mensaje que se enviará, el cuerpo del mensaje y si queremos el informe en Excel o Pdf. Figura 81: Planificación de informes en Litebi (Envío)