Unidad 5: Aplicaciones de negocio

Transcripción

1 Unidad 5: Aplicaciones de negocio Business Intelligence / Data warehouse Tecnología aplicada a la toma de decisiones o malas decisiones en tecnología? Autor: Ernesto Chinkes, 2006 Profesor TI FCE/UBA 1. Introducción En la denominada sociedad del conocimiento, la información ha pasado a ser uno de los activos más preciados de los que disponen las organizaciones. En muchas instituciones, sobre todo las de servicios, es el principal activo; inclusive por encima de los de capital, y en las que no lo es, igualmente tiene una relevancia mayúscula. Para tomar mejores decisiones es fundamental contar con la información adecuada en el momento y lugar preciso. Esto no es nuevo, pero el impacto de no disponer de dicha información cada vez tiene un efecto más nocivo. Esto se debe a que el mundo que nos rodea es cada vez más complejo, cambia más rápidamente y el resto de los actores con los que se convive cada vez cuentan con más y mejor información. Los términos data warehouse y business intelligence se usan desde hace varios años en la industria de las Tecnologías de la Información (TI), y enmarcan soluciones tecnológicas que a las organizaciones pueden proveerles importantes beneficios alineados con mejorar el proceso de toma de decisiones. Es tecnología aplicada a dar soporte a la toma de decisiones, pero muchas veces los proyectos para su incorporación terminan reflejando simplemente malas decisiones en tecnología. En las secciones que siguen se intenta dar algunos lineamientos para que esto último no ocurra. 2. La información en la toma de decisiones. En el transcurrir cotidiano de las organizaciones, las personas que trabajan en ellas deben enfrentarse a decisiones en forma frecuente y recurrente durante el día, ya sean grandes o pequeños problemas los que deban afrontar y solucionar. Algunas de ellas son decisiones de rutina o intrascendentes mientras que otras tienen una repercusión significativa en las operaciones de la organización y pueden incidir inclusive en la supervivencia. 1

2 Toda acción que se realiza, o deja de hacer, en una organización es fruto de las decisiones que han tomado las personas que la componen. Por lo tanto, es en función de la calidad de dichas decisiones el futuro de éxitos o fracasos que le deparará. Para tomar decisiones las personas pueden basarse en información, así como en muchos otros aspectos menos racionales como la emoción, la percepción, el prejuicio, la intuición, etc. Gran parte del esfuerzo del proceso decisorio estará destinado a comprender el futuro, ya que es el terreno en el que transcurrirán finalmente sus acciones. Es por ello que un gran soporte en este sentido es la posibilidad de analizar los hechos ocurridos, para construir de esta forma el escenario futuro apoyándose en las experiencias vividas. Las decisiones deben tomarse sobre una realidad altamente compleja, en la que confluyen un enorme número de variables que entran en juego, que a la vez tienen una infinidad de posibilidades. Por otro lado se puede observar que para muchas de las decisiones que se toman se dedica muy poco tiempo, y ello implica tener en cuenta solamente lo que se siente y vislumbra en ese momento, no considerando aspectos del pasado donde la rica historia de la organización pueden dar un panorama que, de ser analizados, llevarían la decisión a un resultado distinto. Es interesante mencionar las cuatro etapas del proceso decisorio que describe Herbert A. Simon: a) inteligencia, b) diseño, c) selección y d) implementación; ya que ello permite comprender la significatividad que puede tener en su resultado la disponibilidad de herramientas adecuadas por parte de los decisores. a) Inteligencia: es en esta etapa donde se detectan los problemas. El proceso de toma de decisiones comienza con el reconocimiento de la necesidad de tomar una decisión, ya sea por que se detecta un problema o el deseo de accionar o cambiar algún aspecto. b) Diseño: es la base de la toma de decisiones y no es más que desplegar las alternativas. El tomador de la decisión confecciona una lista de las alternativas posibles que se le ocurren como viables para resolver el problema. c) Selección: una vez identificadas las alternativas, se evalúa de manera crítica cada una de ellas. Se comparan distinguiendo sus consecuencias, ventajas y desventajas, y en particular sus costos 1. El tomador de decisiones tiene que elegir una de ellas. d) Implementación: finalmente se pone en práctica la decisión elegida, se lleva la decisión a la acción, y es a partir de ese momento, en donde se monitorean sus progresos y resultados obtenidos. Los sistemas informáticos en general, y las soluciones de business intelligence en particular, son herramientas imprescindibles para dar soporte a este proceso. En la actualidad, en la mayoría de las organizaciones, prácticamente no existe aspecto sobre el cual haya que tomar decisiones, del que no se estén guardando datos. Existe gran cantidad de datos que se almacenan como fruto de la gestión diaria de las operaciones de rutina. Sin embargo, 1 El concepto costo no se limita al aspecto monetario, pura y exclusivamente, sino que se lo referencia con un criterio amplio. 2

3 muchas veces esos datos no están disponibles, accesibles, en el formato y el momento oportuno para permitir su uso como información que ayude de manera significativa en las decisiones. Es decir, no se valora y usufructúa el gran potencial de información que existe. Las soluciones de inteligencia de negocio pueden ser vitales para mejorar el proceso de toma de decisiones; ya que brindarán información que permita detectar los problemas sobre los cuales habrá que decidir, desarrollar alternativas, evaluar las posibles consecuencias de las mismas y su posterior monitoreo cuando se traduzcan en acciones. En la medida que las decisiones son propias del nivel operativo (por lo general con efectos a corto plazo, fáciles de revertir y con impacto único) es más fácil que estas sean programadas y que puedan por lo tanto estar incorporadas en los sistemas de información de nivel operativo (que se suelen denominar sistemas OLTP). En cambio las de alto nivel (táctico y estratégico) no son fácilmente programables, y es allí donde es necesario proveerles a los responsables de realizarlas la mejor infraestructura posible para encararlas. 3. Los problemas de los sistemas operacionales. Antes de analizar en detalle una solución es conveniente comprender adecuadamente los problemas que la misma debe solucionar. Cuando ello no es así, lo que se implanta no cubre necesidades reales, y en lugar de acercar soluciones genera nuevos problemas, a veces inclusive mayores que los originarios. Es por ello que hace tiempo me ha interesado estudiar y clasificar estos problemas, que finalmente bauticé con el rótulo de Los tres problemas del OLTP. Si bien existen en las organizaciones distintas estructuras administrativas y procesos de negocio, es posible generalizar su organización en lo que se denomina la pirámide organizacional. El nivel operativo es donde se agrupan la mayoría de los trabajadores y donde los procedimientos están más estructurados y definidos. Los niveles superiores (nivel táctico y estratégico) realizan actividades más relacionadas con el control y la toma de decisiones. Los trabajadores del nivel operativo también necesitan información para el control y la toma de decisiones, pero están más ligados a aspectos puntuales y específicos, como el control si un cliente está pagando su deuda en forma correcta o la decisión de si debe cobrarle o no un recargo. En cambio los niveles superiores necesitan información para un control más global y abarcativo y para decisiones tácticas y estratégicas, como el lanzamiento de nuevos productos y servicios, la reubicación de recursos, nuevas políticas de motivación del personal, la inversión o eliminación de una planta de producción, etc. 3

4 Los sistemas operacionales son sistemas de información que dan soporte a los procesos del nivel operativo de la estructura organizacional. El nivel operativo es donde se realizan las actividades de rutina del negocio que permiten su funcionamiento, es donde se atiende y vende, donde se cobra y paga, donde se produce, donde se liquidan los haberes de los empleados, etc. Cada una de estas funciones que necesita realizar una organización para cumplir con sus objetivos, se encuentran apoyadas por sistemas informáticos. A estos se los denomina sistemas transaccionales, operacionales u OLTP (On Line Transactional Processing). Estos sistemas necesitan guardar y consultar datos. Las bases de datos que dan soporte a los sistemas de nivel operativo, se denominan bases de datos OLTP. Estas bases de datos soportan procesos con las siguientes características: Transacciones que actualizan un conjunto de pocos registros. Ejemplo: Las facturas que un cliente está pagando. Transacciones que consultan un conjunto de pocos registros. Ejemplo: El precio de un producto que está por comprar un cliente. Puede existir alto nivel de concurrencia de las transacciones que consultan y actualizan. Ejemplo: muchos cajeros de una línea de caja, facturando al mismo tiempo. Son operaciones de actualización y consultas en línea ( on line ), que deben tener una respuesta instantánea para no trabar las operaciones de la organización. Ejemplo: el cobro de un servicio en un banco, que le debe decir al cajero cuanto cobrar, y debe quedar registrado el pago antes de que el cliente abandone la ventanilla. Cuando se necesita información para usar en la toma de decisiones tácticas y estratégicas, las bases de datos OLTP, pueden presentar una serie de deficiencias que no permitan satisfacer las necesidades que presentan estos niveles de decisión. Estas deficiencias, como ya se comentó al principio de la sección, las he clasificado mediante Los tres problemas del OLTP. a) Problema 1: Descentralización de la base de datos. Los datos que representan la realidad de la organización se encuentran muchas veces dispersos. Es decir, existen distintas bases de datos (o en algunos casos archivos), que tienen diseños conceptuales y físicos independientes entre sí, que guardan situaciones parciales no relacionadas ni integradas. Esta descentralización de la base de datos dentro de una organización tiene, por lo general, un origen pluricausal, que se encuentra relacionado con las particularidades que ha asumido el 4

5 desarrollo y la administración de los sistemas informáticos. En la medida que mayor sea la complejidad de las instituciones, mayor será la probabilidad de que existan más causas para esta descentralización de los datos. Es por ejemplo muy común encontrar que el sistema de ventas actualiza una base de datos, el de abastecimiento otra y el de liquidación de haberes una distinta, así mismo podría suceder que distintas sucursales de una empresa se manejen con sistemas independientes que actualicen sus propias bases de datos. Surgen, entonces, los siguientes problemas: Existen diferentes visiones de una misma realidad entre los decisores de la organización. Imposibilidad de obtener información integrada que permita comparar, clasificar y consolidar la información de las distintas áreas, sectores, procesos, unidades, etc., para analizar a la organización como un todo. b) Problema 2: Inadecuados tiempos de respuesta. Existe en las instituciones la necesidad de realizar consultas de grandes porciones de la base de datos en forma interactiva. Es decir, gran parte de la información que necesitan los niveles tácticos y estratégicos para la toma de decisiones, es información que se construye a partir del acceso y procesamiento de importantes volúmenes de datos. Por ejemplo, si necesitara comparar los 10 productos más vendidos durante el primer semestre de este año contra los del semestre del año anterior, debería recorrer los datos correspondientes a todas las ventas de los seis primeros meses del año anterior y del actual, que podrían ser cientos de miles (o millones) de registros. Pero esta respuesta debería volver en pocos segundos, ya que posiblemente en base a dicho resultado el usuario necesite realizar otra consulta, como ampliarlo a 20 productos, o comparar sólo el primer trimestre, o desagregar la información por zona geográfica de venta, etc. En la medida que las bases tienen grandes cantidades de datos, se hace muy difícil, obtener adecuados tiempos de respuesta de las bases de datos OLTP para este tipo de consultas. Por otro lado este tipo de consultas trae un problema adicional, y es que hace más lento al resto de las operaciones transaccionales que deben realizarse en esa base de datos, ya que los recursos de la computadora (principalmente procesador y disco) estarán ocupados con dichas consultas que hacen un uso muy intensivo de estos recursos. Surgen, entonces, los siguientes problemas: Inadecuados tiempos de respuesta para las consultas que se necesitan para la toma de 5

6 decisiones. Se entorpece el nivel de respuesta de los sistemas de nivel operativo, debido al uso intensivo de los recursos que genera el procesamiento de las consultas para la toma de decisiones. c) Exploración amigable para consultas ad-hoc. Los tomadores de decisiones necesitan alternativas amigables de acceso a los datos. Es decir, que puedan acceder sin necesitar conocimientos profundos sobre el uso de la tecnología, siendo ésta lo más transparente posible. Esta amigabilidad se ha logrado muchas veces con consultas pre-planeadas (reportes). Estas son consultas de rutina, que como los usuarios ya previeron que las iban a necesitar fueron especificadas, diseñadas y programadas en opciones de un software aplicativo de usuario final, donde el usuario podrá acceder simplemente seleccionando una opción del software, y a lo sumo ingresando algunos parámetros claramente identificados (como fechas, ordenamiento, etc.). El inconveniente surge cuando los decisores necesitan realizar consultas ad-hoc en forma amigable, ya que si bien existen lenguajes para acceder a los datos y realizar consultas ad-hoc, como es el caso de SQL (Standard Query Language) o QBE (Query By Example), su uso implica el conocimiento por parte del usuario del lenguaje y de complejos modelos de datos. Estas capacidades no son acordes con el perfil de los usuarios que necesitan este tipo de información. El problema, entonces, es: Los usuarios no cuentan con herramientas para explorar los datos y obtener información ad-hoc para la toma de decisiones en forma amigable. Puede que los problemas enunciados se presenten todos juntos, o que sólo se presente uno o dos de ellos. Inclusive que no exista ninguno. Sólo en el último de los casos no es necesaria una solución de business intelligence / data warehouse. Si existen los problemas 1 y 2 (descentralización de la base de datos e inadecuados tiempos de respuesta) el data warehouse es el que le acerca los principales beneficios. Si existe el problema 3 (no disponer de herramientas para obtener información ad-hoc en forma amigable), entonces debe explorar las tecnologías encuadradas bajo el paraguas del business intelligence 6

7 N ivel Estratégico N ivel Táctico INFO R M A CIO N P A RA LA TO M A D E DECISIO NES H erram ientas de B I Datam ining O LAP Tableros R eporting... N ivel O perativo V entas Sucursal Córdoba... P roducción D A TA W A R E H O U S E Com pras Ventas S ucursal Bs.As. V entas Sucursal Córdoba M arketing 4. Conceptos y lineamientos de una solución de DW / BI 4.1. El Data Warehouse El data warehouse (almacén de datos) es una base de datos concebida y administrada para dar soporte a la toma de decisiones. En forma sintética se puede decir que, cuando se piensa en un data warehouse se debe considerar una base de datos que debe poseer datos que representen la realidad integrada de toda la organización y que en ella se desea optimizar el desempeño de las consultas que impliquen el procesamiento de un gran número de registros. Una solución de data warehouse debe dejar como resultado una base de datos integrada, con datos que permitan responder a las necesidades de información para la toma de decisiones, principalmente de los niveles tácticos y estratégicos. Si bien por lo general, el motivo principal es brindar información para los niveles superiores de la organización, eso no quita que se use también para responder consultas de niveles operativos, como podría ser el caso de vendedores que accedan para obtener información integrada sobre el historial de ventas de los clientes, y de esta forma poder focalizar mejor su estrategia de relación con los mismos El Business Intelligence El business intelligence (inteligencia de negocio) define una solución donde se usan los datos para la administración inteligente de la organización. Si bien este concepto puede tratarse como un tema de management, que denote la importancia del uso de la información para guiar una organización, desde el punto de vista de la tecnología es 7

8 posible enfocarlo para describir las herramientas de exploración y explotación de datos para dar soporte a la toma de decisiones. Cuando se analiza a las organizaciones en función de su organigrama se detecta que las necesidades con respecto a la información no son iguales para todos los niveles jerárquicos, ni tampoco para las diferentes áreas funcionales. Un gerente general necesita evaluar la situación global de la compañía mediante la medición de una serie de indicadores definidos como estratégicos a nivel directivo, para lo que lo ayudará la utilización de unos pocos indicadores integrales de rápida detección (como pueden ser semáforos, tacómetros, etc.) sobre la salud de la organización. En cambio un analista de producto de una región particular seguramente no necesite visualizar el desempeño de esos indicadores globales y esté mucho más interesado en ver la evolución diaria de las ventas de un producto en la región que él tiene a cargo. Asimismo, no serán las mismas necesidades las que tiene un analista contable que necesitará crear reportes sobre el balance, con el formato corporativo, para enviar a la casa matriz o para presentar ante organismos regulatorios, que las que tiene un analista de marketing cuando quiera saber cuáles son las combinaciones de productos que más adquieren las personas que tienen entre 20 y 30 años y viven en zona norte de la Ciudad de Buenos Aires. Este amplio espectro de necesidades es el que debe ser abarcado por las herramientas de business intelligence. Existe entonces una clasificación de diversos tipos o estilos que puede asumir el acceso a la información mediante el software de business intelligence. Un usuario particular puede utilizar uno o más de estos tipos, pero seguramente estará más cerca de uno u otro, de acuerdo a sus funciones y responsabilidades en la institución y a su forma personal de relacionarse con la información disponible. Las categorías de business intelligence son: 1. Reportes (Reporting). 2. Análisis multidimensional (exploración OLAP). 3. Tableros de Control / Balance Scorecard. 4. Minería de datos (Data Mining). 5. Distribución pro activa. Estas herramientas se conciben para tomadores de decisiones que sean autosuficientes a la hora de obtener la información que necesitan. Si bien algunas herramientas de las categorías mencionadas no lo necesitan con tanta fuerza, implantar estas herramientas plantea un cambio cultural difícil para organizaciones donde los decisores prefieren contar con un área que les provea información, en lugar una infraestructura tecnológica preparada para acceder a ella por su cuenta. 8

9 Cuando se encara una solución de business intelligence, ella incluye la existencia de una base de datos (por lo general un data warehouse) y la implantación de una o varias de estas herramientas La arquitectura de la solución Es importante describir los componentes que integran la arquitectura de una solución de data warehouse / business intelligence. La que se plantea es un arquitectura bastante particular, que a criterio de este autor tiene importantes beneficios, pero con esto no se desea expresar que ésta es la única arquitectura viable, ni tildar de erróneas otras que puedan ser consideradas. En esta arquitectura se plantean tres grandes áreas o componentes: 1) Fuentes de datos, 2) área del data warehouse y 3) herramientas de acceso y exploración. 1. Fuentes de Datos: incluye a todos los datos en su lugar de origen (bases de datos o archivos planos) que se extraerán mediante los correspondientes ETL 2 que permitirán incorporar el contenido del data warehouse. Esta área se compone principalmente de los datos que almacenan los sistemas operacionales, pero también pueden existir datos externos, así como datos internos no sistematizados. Fuentes de datos Sistema operacional A Sistema operacional B Sistema operacional N Datos Externos Extracción Datos Internos no Sistematizados Área del Data warehouse Transformación Area de trabajo Carga (Load) Data warehouse detallado u objetivo T, L Data warehouse agregado o subjetivo A B Herramientas de acceso y exploración Análisis Multidimensional Datamining Tablero de comando. Balance scorecard Alertas Reporting Etc. Arquitectura de una solución de Data warehouse / C Business Intelligence Datamart A Datamart B Datamart N 2 ETL (Extract, Transformation, Load) es la forma a que se denominan los procesos de extracción, transformación y carga que se usan para nutrir a un data warehouse. 9

10 2. Área del data warehouse: incluye a todos los datos que se integran para brindar información para la toma de decisiones en forma eficaz y eficiente. Este área puede ser dividida en tres sub áreas para su mejor análisis: o Área de trabajo: aquí se realizan las principales transformaciones de datos, que incluyen su limpieza, combinación, homogeneización de unidades de medida, equivalencias de códigos, agregaciones de consistencia, etc. o Data warehouse objetivo o detallado: es una base de datos que contiene los datos integrados de toda la organización, con el mayor nivel de desagregación posible. Es decir, que es una base de datos que representa la realidad de la organización desde una mirada puesta en los datos de origen, intentando reproducir con la mayor objetividad las transacciones como fueron capturadas. o Data warehouse subjetivo o agregado: podrá estar compuesto por una única base de datos o por múltiples (data marts), o por ambas. Esta o estas bases de datos están construidas según las necesidades de la información para la toma de decisiones de los usuarios y de las herramientas de exploración. Se nutre del data warehouse objetivo. El data warehouse subjetivo, a diferencia del objetivo, es una representación integrada de la realidad desde la perspectiva de la exploración de la información que podrán hacer los tomadores de decisiones (subjetiva). 3. Las herramientas de acceso y exploración de datos: Es el componente que usufructúa los beneficios de la solución. Es lo que ven los usuarios. Se compone de las distintas herramientas que se implanten para explorar los datos, permitiendo cubrir diversos criterios y estilos de análisis de la información: como el análisis multidimensional, datamining, reporting, alertas, tablero de comando, balance scorecard, etc. Los datos del data warehouse se obtienen del área de fuentes de datos, a través de procesos informáticos que se encargan de la extracción de datos. Todos estos datos por lo general tienen como destino una base de datos (o el área de una base de datos) que se denominó Área de trabajo. Es allí donde se correrán procesos informáticos que realicen la transformación de datos. Es un área que contendrá datos que todavía no están listos para ser consultados por los usuarios. Es un espacio de almacenamiento donde se estarán preparando los datos. 10

11 Una vez que los datos estén listos se pasarán a los sectores A, B, y/o C (según la figura de página 9) del área del data warehouse. El sector dependerá de la arquitectura que la organización elija. En caso de existir una arquitectura completa, como la que aquí se plantea, entonces en primer lugar se correrían procesos de carga que permitan dejar listo el data warehouse objetivo (sector A), luego a partir de allí cargar el data warehouse subjetivo (sectores B y/o C), realizando principalmente transformaciones de agregación según los criterios de exploración que se definan para los usuarios. En caso de co-existir los sectores B y C, en B se dispondrá de una base de datos integrada, mientras que en C los datamarts que se corresponden con visiones parciales de la organización y serán el resultado de particionar B. Su principal objetivo es lograr mejor performance o explotar una visión parcial con mayor detalle que el que se encuentra en B. En este último caso el contenido de C se generaría directamente desde A. También es posible definir una arquitectura donde sólo exista B o C (sin que exista A). Este esquema es bastante común, y se da cuando los datos en el data warehouse se guardan directamente en forma agregada bajo los criterios de las dimensiones de explotación. El ETL El ETL, que significa Extraction, Transformation and Load (extracción, transformación y carga), es la forma en que se denomina al conjunto de procesos mediante los cuales se genera y actualiza el contenido del data warehouse. Estos procesos deben resolver el mayor problema con el que suele toparse la construcción de un data warehouse: la homogeneización de los datos provenientes de fuentes diversas. Estos procesos deben: acceder y tomar datos de las distintas fuentes (Extract), realizar las transformaciones que sean necesarias para dejar los datos en el formato, con la codificación, niveles de agregación, de calidad y criterios de integración que se definan (Transform), y actualizar el data warehouse con dichos datos ya transformados (Load) Los procesos que componen el ETL necesitan ser ejecutados en base a una programación temporal. Esta debe ser definida en función de las necesidades de actualización que amerite el data warehouse. La programación incluye periodicidad (cada cuanto tiempo se ejecuta), el horario, 11

12 y la secuencia. Hay que determinar la secuencia en que se ejecutarán los n proceso que integren el ETL, ya que de lo contrario correría riesgo la integridad de la base de datos. El datamart El datamart (mercado de datos), es el nombre que se le asigna a una base de datos que asume las características que se definieron para un data warehouse, pero en lugar de representar la realidad de toda una organización sólo lo hace respecto de un área o función de ella. De esta forma, por ejemplo, podrán existir datamarts para el área de ventas, de finanzas, para el departamento de recursos humanos, etc. Es un concepto que ha tomado bastante relevancia principalmente debido a la complejidad que implica la implantación de un data warehouse. Es por ello que muchas veces se avanza sobre proyectos que consideran la implantación de datamarts. 5. Los factores críticos. En este apartado se explican algunos criterios que deben considerar quienes construyan e implementen este tipo de soluciones, principalmente en lo referente a consideraciones o enfoques acerca de su diseño, construcción e implantación Se trata de un desarrollo a medida. Un primer punto que vale la pena destacar es que una solución de business Intelligence / data warehouse necesita un proyecto que se desarrolle a la medida de cada organización. Es necesario diseñarla considerando las necesidades de la información, el tipo de decisiones que se deben soportar y la realidad de datos que tiene cada institución en particular. Esto no quiere decir que el software que integre este tipo de soluciones hay que desarrollarlo a medida, ya que sería poco inteligente no aprovechar la existencia de una variedad de productos de software que proveen herramientas para soportar estas soluciones. Lo que debe entenderse es que habrá un conjunto importante de necesidades particulares que implicarán soluciones propias no replicables de otras experiencias. Sin lugar a dudas, dentro del proceso de construcción, el desarrollo del data warehouse es el que más características de individualidad tendrá. No sólo se debe construir una base de datos que satisfaga las necesidades de información propias de cada institución, sino que también debe adaptarse a la realidad de los datos existentes. 12

13 Este segundo punto es el que más diferencia a cada solución del resto, ya que si bien las necesidades de información en cada organización podrían definirse también como únicas, es muy probable que una organización pueda beneficiarse en gran medida de imitar determinados modelos que ya se usaron en otras empresas de su misma industria. Sin embargo la compleja realidad de los datos existentes en una organización muy difícilmente se repita en otra (sobre todo en la medida que sean instituciones de mediana o gran envergadura) Partir desde la información o desde los datos Como se expresó en el punto 5.1. para desarrollar una solución de estas características es necesario considerar tanto las necesidades de información que tiene la organización, así como entender cabalmente cual es la realidad de las fuentes de datos a partir de las cuales se podrá nutrir el data warehouse. A partir de ello es posible considerar dos criterios opuestos para guiar el desarrollo: a) Partir desde las necesidades: este criterio considera que debe comenzarse por definir claramente las necesidades de la información (que deberá proveer la solución) y a partir de allí diseñar el data warehouse deseado. b) Partir desde las fuentes de datos: éste considera que debe comenzarse por entender que datos existen y a partir de allí diseñar el data warehouse posible. Si bien a) sería lo que se impone como más criterioso, alineándose con las buenas prácticas en sistemas, donde primero es necesario entender la necesidad a satisfacer y recién allí construir la mejor solución, quienes defienden b) plantean que de nada sirve que los usuarios fantaseen sobre que información les gustaría obtener, si luego no existen los datos necesarios para lograrlo. Como ambos criterios tienen una verdad a considerar, se plantea como recomendación, una tercera alternativa: c) Equilibrio entre necesidades y datos existentes: se plantea comenzar el análisis a partir de las necesidades de la información, que permitan fijar el alcance que determine la dirección hacia la cual avanzar. Luego trabajar en un proceso iterativo entre la formalización de los datos existentes, las necesidades de información y el diseño del data warehouse. 13

14 Análisis de las necesidades de información Alcance Formalizar datos existentes Necesidades de información Diseño del data warehouse 5.3. Redundancia. La redundancia en las bases de datos, no debe ser considerada como una mala palabra que debe ser eliminada de la faz de la tierra. No sólo trae perjuicios, que son los que por lo general se mencionan cuando se estudian o pregonan los conceptos referidos a la normalización (con las formas normales), sino que también puede traer beneficios. Es por ello que es necesario analizar ventajas contra desventajas y decidir cuál conviene priorizar. La redundancia es una de las principales herramientas con que se cuenta para acelerar las consultas y la implementación de controles. El primer aspecto, que es el que interesa principalmente al data warehouse, tiene como explicación que la redundancia posibilita almacenar precalculados los resultados totales o parciales de las consultas. Entre las desventajas de la redundancia, se pueden mencionar, la mayor probabilidad de que existan inconsistencias y los mayores tiempos de actualización (ya que es ese el momento en que se realizaría por ejemplo el precalculo que se mencionaba en el párrafo anterior). En las bases de datos OLTP tiene mayor impacto las desventajas de la redundancia que las ventajas que puede proveer. Es por ello que no es aconsejable su aplicación, salvo en casos muy controlados y en la medida que sea la mejor entre otras alternativas que se hayan evaluado. En el caso del data warehouse pasa lo contrario. Es una excelente solución para lograr importantes mejoras de desempeño en las consultas. Por otra parte por lo general no es un costo significativo el tiempo extra en la actualización que es necesario pagar por ello. En el siguiente cuadro se detallan pros y contras de la redundancia en los dos tipos de bases de datos. 14

15 Características de la redundancia en las bases de datos a. Acelerar consultas con datos precalculados b. Demora la actualización de los datos, al guardar en forma redundante datos calculables (datos precalculados). c. Existe mayor probabilidad de generar inconsistencias. d. Redundancia para controles. Efecto que causa en las bases de datos. Base de datos OLTP En la mayoría de los sistemas no es un beneficio significativo, debido a que la mayoría de las consultas, son sobre una cantidad de registros pequeña. Es un perjuicio significativo, ya que en la mayoría de los sistemas la actualización es en línea, conllevando demoras en la misma. Por lo que está íntimamente relacionado con la eficiencia de las operaciones (como por ejemplo la línea de caja). Es un perjuicio significativo, ya que existe la posibilidad de que se actualicen los datos correspondientes a una transacción en forma incompleta. Pude ser un beneficio y un perjuicio significativo a la vez. Puede ser una herramienta muy importante para insertar controles que mejoren la confiabilidad de los datos almacenados (digito verificador, totales de control, registros duplicados en distintos servidores, etc), pero por el otro lado tiene los mismos perjuicios que los vistos en el retraso de la actualización. Data warehouse Es un beneficio significativo por que el objetivo es realizar consultas a grandes porciones de la base de datos, que en caso de estar precalculados, permite evitar recorrer todos los registros desagregados. No es un perjuicio significativo, ya que en la mayoría de los casos la actualización es batch y no trae mayores problemas una demora en dicho proceso. No es un perjuicio significativo, dado que los datos son una copia de otra base de datos, que contiene a los originales, y debido a que el proceso de actualización es más controlado. No obstante habrá que controlar que el ETL actualice en forma consistente todos los datos. No es significativo, ya que la actualización está controlada desde el ETL y se está realizando una copia de los sistemas transaccionales donde deberían estar dichos controles. Observación: En el punto b es necesario realizar la siguiente salvedad: existen procesos de ETL donde el volumen de datos y la complejidad de los procesos hacen que los periodos de inactividad de los sistemas de nivel operativo no alcancen para su ejecución. En estos casos mayor redundancia puede transformarse en un perjuicio significativo El costo de la integración de datos y el nivel de desagregación. Como se explicó en forma precedente la construcción de un data warehouse implica diseñar e implantar una base de datos integrada. Es por ello, que salvo rarísimas excepciones, ello implica una ardua tarea que permita integrar en una única base, datos que se vienen almacenando (y seguramente se seguirán almacenando) en forma descentralizada. Esta actividad de integración tiene dos componentes principales, uno el del diseño y generación de una base de datos que pueda contemplar las distintas realidades parciales que se deben conjugar, y el otro el del diseño y desarrollo de los procesos ETL que deberán mapear el contenido de las fuentes de datos con el data warehouse. Esta actividad probablemente sea una de las que más tiempo y recursos insuma en la construcción 15

16 de una solución de este tipo, ya que implica conocer adecuadamente los modelos de cada una de las fuentes de datos, conocer las necesidades de información para la toma de decisiones, y comenzar a trabajar en forma conjunta entre el diseño del data warehouse y de los ETL necesarios para llenarlo con datos homogéneos y de calidad aceptable. Ya que los cambios en la solución que se implemente serán inevitables, sobre todo por que es normal que las necesidades de los tomadores de decisiones deban adaptarse constantemente, tener que encarar este proceso de integración cada vez que haya que implementar modificaciones conlleva una solución no sustentable en el tiempo. Por este motivo es que el diseño de la solución debe ser fácilmente adaptable a los cambios y no estático a las necesidades específicas del momento de su construcción. En línea con este análisis se planteó en la sección anterior la arquitectura con un data warehouse desagregado ( objetivo ) que fuera el que tratara por única vez esta problemática, y otro subjetivo (más orientado al software de business intelligence y el análisis del negocio) que trabajará con las agregaciones necesarias según las necesidades de información que surjan en cada momento. Este esquema permite que cuando surjan cambios no haya que trabajar nuevamente, o solo en forma mínima, con la integración; porque dichos datos ya existirán en el data warehouse objetivo. Solamente habrá que adaptar el data warehouse subjetivo, que es una tarea más fácil de implementar Del data warehouse al datamart o a la inversa? El uso de datamart en el proceso de construcción, es otro aspecto que divide posturas opuestas. Una de ellas recomienda construir el data warehouse desde los datamats, por lo tanto pregona que primero se vayan realizando proyectos de construcción de datamarts que cubran distintas necesidades parciales de la organización, como sería el caso del datamarts para el departamento de ventas, de recursos humanos, de compras, de finanzas, de producción, etc. y luego desde estas soluciones avanzar hacia la construcción del data warehouse que integre estas soluciones. La otra postura plantea la construcción del data warehouse primero, y recién luego avanzar hacia los datamarts en la medida que los mismos sean necesarios. Es decir, el camino exactamente inverso. Los patrocinadores del segundo camino expresan con razón que encarar una solución bajo la 16

17 primera postura, conserva el problema de las visiones parciales desintegradas, y hasta las agrava por que las consolida mediante el datamart. En cambio los que propician lo contrario, plantean también con razón, que es imposible encarar un data warehouse en forma integral, sobre todo en organizaciones medianamente complejas, y que por ello la única solución es comenzar con soluciones más pequeñas como son los datamarts. Como se desprende del párrafo anterior, ambas posturas tienen causas razonables, y es por ello que mi recomendación es comenzar con soluciones chicas, como es un datamart, que permita mostrar un resultado en el mediano plazo y de esta forma conseguir mayor apoyo para la continuación del proyecto, pero a la hora de continuar sumando otras áreas de la organización, no hacerlo construyendo otro datamarts, sino integrando las mismas a un único data warehouse. Luego si es necesario se podrán subdividir datamarts El recupero de la inversión. Los proyectos de tecnologías de la información (TI) en general, y los de data warehouse / business intelligence en particular, son inversiones de capital que, como tales, deben competir con otras inversiones de la organización. Es por ello que es frecuente la solicitud de justificación de un proyecto de esta naturaleza desde una perspectiva que demuestre por qué usar el dinero en éste, en lugar de usarlo en otro proyecto de inversión ya sea de TI o no. Para calcular el recupero de una inversión de capital se suelen utilizar algunos de los métodos más conocidos, como el ROI, TIR, VAN, etc. Estos métodos son de utilidad tanto en la fase inicial, para justificar la factibilidad económica de realizar el proyecto, como luego de su implementación, para evaluar el desempeño de la solución lograda. Para usar cualquiera de estos métodos se necesita especificar los flujos de ingresos y egresos del proyecto que permitirán realizar el calculo numérico que arroje finalmente el resultado. Obtener el flujo de egresos al finalizar el proyecto no tiene mayores problemas, ya que los costos son fácilmente calculables (si se registraron adecuadamente). Para obtenerlo al inicio de un proyecto hará falta una estimación de los mismos, en los que tendrá fundamental importancia la utilización de determinadas técnicas de estimación así como la experiencia del administrador de proyectos. Pero el principal problema para el cálculo del recupero de la inversión está dado en la 17

18 determinación de los ingresos a los que se arribará como resultado de la implementación de la solución (que podrán ser ingresos reales o disminución de costos). Los ingresos que se generen por la implementación de una solución de este tipo dependerán muy fuertemente del nivel de las decisiones que se tomen al usar la información que les brindará. Es decir, en gran parte por la capacidad de los decisores que la usen. Es por ello, que será sumamente difícil estimar los ingresos al inicio del proyecto, pero inclusive igual grado de dificultad podrá tener su determinación al final del mismo, donde si bien se podrán observar nuevos ingresos desde su implementación, habrá que determinar cuantos de ellos son asignables a la información obtenida por los decisores. No obstante lo dicho, creo que igualmente debe justificarse económicamente un proyecto de esta naturaleza, dejando claro que la misma estará muy lejos de ser exacta. Es decir, que por un lado se deben estimar los costos y por otro lado ejemplificar que tipo de decisiones debería permitir esta solución para lograr los ahorros o ingresos que lo justifiquen. Para esquematizar los tipos de decisiones conviene dividirlas entre ingresos duros (reducción de costos, retención de clientes, adquisición de nuevos clientes, aumento de la porción del mercado, etc.) e ingresos blandos (aumento de la satisfacción del cliente, empleados más satisfechos, empleados con mayor autonomía, aumento de la imagen organizacional, etc.) Que se use la solución: todo un desafío. Como en tantos otros proyectos de TI, la construcción es relativamente fácil en relación a lo difícil que puede ser que el producto desarrollado finalmente se use y que le brinde beneficios a la organización usuaria. Las soluciones que aquí se plantean, no son la excepción a este comentario, e inclusive tener que trabajar con los niveles altos de una organización los convierte en proyectos más vulnerables. Estos usuarios suelen ser más complicados que el resto, dado el poco tiempo que están dispuestos a destinar, lo poco dispuestos que se encuentran para acatar instrucciones o recibir capacitación. Para lograr una buena implementación hay que conseguir que desde el inicio los potenciales usuarios entiendan y comprendan los beneficios que les proveerá la solución. Otro aspecto relevante es comenzar a pensar en la implementación desde las etapas iniciales de la construcción. En este sentido se debe generar una relación con los usuarios, durante el desarrollo, pensando en la implementación. Por ejemplo, considerando sus decisiones de diseño, sus 18

19 opiniones y haciéndolos sentir en todo momento que el proyecto es suyo. Los proyectos de data warehouse / business intelligence suelen destinar mucho tiempo para resolver los aspectos tecnológicos, sin hacer lo propio en las tareas que permitan una adecuada implementación. Esto se debe a que en muchas ocasiones pareciera que es posible desarrollar la solución sin la participación de los usuarios, y que, como se dijo antes, muchos usuarios dado su escaso tiempo prefieren que avancen sin ellos. Quienes opinan que es posible llegar a un producto sin consensuar demasiado con los usuarios, tienen razón, pero también deben entender que deberán poner en duda la factibilidad de su implementación. En la mayoría de los casos, cuando no se involucró a los usuarios desde el principio, no se dedica el debido tiempo para lograr una comunicación adecuada y fructífera, luego del desarrollo ya será tarde. La inexistencia de una adecuada comunicación es la mayor causa de los fracasos, y no la no resolución de los aspectos técnicos del data warehouse, o de haber elegido la herramienta informática errada. Posiblemente haya que rever las prioridades a la hora de dedicar tiempos y recursos La única verdad? Se ha planteado al inicio de este trabajo, en los tres problemas del OLTP, que los sistemas operacionales para brindar información para la toma de decisiones muchas veces tienen el inconveniente de brindar visiones parciales y que, en muchos casos, ofrecen distintas visiones de una misma realidad, y no es fácil determinar cual es la verdadera. Por ejemplo cuando el Gerente de marketing dice que el importe vendido en lo que va del año es de $ , mientras que el de Finanzas por su parte consigue información de sus sistemas por $ y el de Ventas por $ : cuál tiene razón? cada uno está tomando decisiones para la misma empresa pero mirando realidades distintas. Es por ello que se plantea como una solución el data warehouse, que permite integrar en una sola base de datos una representación integrada de la realidad de la organización. Sobre ella se trabajará con herramientas de business intelligence que permitan a todos los decisores obtener exactamente la misma información. Siguiendo con el caso planteado todos verían, por ejemplo, que las ventas en el año ascendieron a $ No obstante lo dicho, es fundamental que quienes implementen soluciones de data warehouse / business intelligence reflexionen que con la mera implantación de estas soluciones no 19

20 necesariamente se resolverá el problema original. Por el contrario podría agravarse, como suele suceder cuando se piensa que un problema está resuelto sin que sea cierto (ya que se despreocupa del mismo). Por más que exista un indicador unificado, y que cualquier persona que consulte el data warehouse obtenga el importe de $ para las ventas, lo que puede no estar unificada es la interpretación que cada decisor hace de dicho indicador. Es decir, cómo se construyó el número mostrado (por ejemplo si incluye o no impuestos, si descuenta bonificaciones o promociones, si incluye los productos discontinuados, etc.). Según la compresión que haga el decisor de dicho indicador es la decisión que finalmente tomará, y esto es lo que realmente importa. En el ejemplo (importe vendido) es una variable bastante sencilla, mucho peor será en otras de construcción más ambigua, como sería la rentabilidad, el valor de un cliente, etc. Es por ello que si se desea mejorar la percepción unificada de la realidad, por parte de los distintos decisores de la organización, será deseable incorporar explicaciones accesible por los usuarios acerca de su significado (ello incluye describir como se calculan dichas variables). 6. Conclusión Mucho se ha dicho y escrito sobre las falencias que existen en las organizaciones, a la hora de obtener información adecuada para la toma de decisiones, sobre los aportes que pueden hacer en este sentido las soluciones de business intelligence (y los data warehouse) y sobre las formas que deben asumir dichas tecnologías. Pero quienes deben encarar estos proyectos, muchas veces, no comprenden en profundidad los problemas con los que se enfrentan e intentan simplemente implantar una tecnología, desconociendo temas que exceden dichas fronteras, y ameritan análisis, estudio y reflexión de una problemática compleja. Este trabajo, así como la publicación en la que este autor está trabajando, intentan abordar este camino, a la espera de generar alertas y disparadores para futuros debates, que nos permitan mejorar las soluciones que las organizaciones necesitan, para que buenas decisiones en tecnología implique buenas decisiones de negocio. 20