LA TECNOLOGÍA OLAP COMPATIBLE CON LA WEB LLEGA AL MERCADO MASIVO
Hasta hace poco tiempo, el Procesamiento Analítico en Línea (OLAP) era considerado por muchos administradores de Tecnología de la Información (TI) como el dominio exclusivo de los integrantes de los departamentos financieros, ya que se trataba de una tecnología demasiado esotérica y fuera del alcance de los usuarios promedio.
Varios factores están obligando a las compañías a prestar más atención a la tecnología OLAP frente a la desaparición de los sistemas propietarios, el cambio por las arquitecturas cliente/servidor y la llegada de la tecnología Java. Y lo que es más importante aun, Internet está promoviendo profundos cambios en la forma en que las organizaciones acceden y extraen información.
Los administradores de TI han comenzado a advertir que OLAP y Business Intelligence (BI) no son solamente tecnologías, sino que representan un "movimiento" que ocurre en una organización. Cuando se ejecuta correctamente, OLAP permite que los directivos de una compañía puedan tomar decisiones informadas y coordinadas en un entorno que evoluciona velozmente, y en el cual las cosas que no son inmediatas simplemente llegan demasiado tarde. Un "movimiento" es una coordinación de información y toma de decisiones total y profunda, que mueve a toda una empresa de forma ordenada y armónica, y que se opone al tradicional flujo ascendente de información y flujo descendente de decisiones. OLAP ya no se percibe solamente como un software de apoyo a la toma de decisiones. En el nuevo modelo, el apoyo a la toma de decisiones representa a todas las herramientas y la tecnología para asistir a los directivos de alto nivel.
OLAP en movimiento...
Las exigencias de los modernos
lugares de trabajo están transformando a OLAP de ser una aplicación desconocida
hasta llegar a herramientas de BI que permiten que los usuarios consoliden,
exploren, segmenten y comparen la información de las empresas. Estos resultados
pueden ofrecerse en formatos de bases de datos tradicionales, así como también
en gráficas que permiten manipular directamente los datos para profundizar los
análisis, que incluyen identificar tendencias, correlaciones y series de
hechos. Esto ilustra el verdadero valor que OLAP proporciona, con su habilidad
para contextualizar la información, independientemente de dónde se encuentre
ubicada, en un marco de referencia que posibilita la toma de decisiones
informada y precisa.
Uso
de los cubos de datos
El crecimiento de OLAP como una
poderosa herramienta de BI está impulsado en gran medida por la facilidad con
que los usuarios pueden crear, manipular y acceder a los cubos de datos.
Cualquier tipo de información empresarial almacenada en una base de datos
central puede transformarse fácilmente en cubos de datos multidimensionales y
luego almacenarse en la red, y/o servidor para permitir el acceso de los
usuarios. Los usuarios también pueden viajar con los cubos o enviarlos vía
email o FTP. Los cubos de datos multidimensionales están compuestos por
dimensiones y medidas que representan las diferentes vistas y combinaciones
posibles de la información.
Por ejemplo, las dimensiones pueden clasificarse en categorías de productos,
clientes y países.
Las medidas contienen información tal como costos, ventas, ganancias y unidades vendidas. Un cubo contiene múltiples dimensiones, creando un modelo ideal para el análisis de datos. Los usuarios pueden encontrar respuestas a preguntas como "¿Qué cantidad de nuestro producto X compró nuestro cliente japonés durante el segundo trimestre de 1999?" O "¿Por qué no alcanzamos los estimativos del último trimestre para las ventas en el Este de los Estados Unidos?" Los gerentes pueden manipular los datos con esta herramienta para descubrir patrones ocultos y tendencias emergentes. OLAP se combina con la Web a través de Java
OLAP ha ganado aceptación en muchas empresas y su status se ha elevado dentro las mismas. Por lo tanto, actualmente hay más expectativas para OLAP, y los clientes han comenzado a expandir su uso más allá de departamentos específicos para abarcar toda la empresa. La tecnología OLAP combinada con la Web para realizar actividades de negocios brinda a los administradores de TI lo mejor de ambos mundos: una aplicación fácil de usar que es accesible para todos. Pero implementar una aplicación OLAP para la Web es un gran desafío técnico. El escepticismo todavía está presente, y algunos analistas sugieren que las versiones disponibles de OLAP para la Web no ofrecen "poder industrial", ya que muchos vendedores ofrecen una versión "diluida" de sus herramientas OLAP. Para ellos, esto trae como consecuencia que generalmente falten las funciones clave, tales como arrastrar y soltar, explorar, y refinamiento de consultas. Sin embargo, a través del uso de una aplicación OLAP totalmente Java, los administradores de TI cuentan con una gran cantidad de funciones accesibles por su simplicidad de uso. Arquitectura
Al programar totalmente en Java es posible crear un sistema de arquitectura de dos o tres capas, dividiendo el proceso entre un servidor de aplicación Java, applets Java que se descargan al cliente, y una base de datos o administrador de recursos. En un modelo de dos capas, un applet Java o aplicación se comunica directamente con la base de datos. Las sentencias SQL de los usuarios se entregan a la base de datos ví a JDBC, y los resultados de esas sentencias se devuelven al usuario. La base de datos puede estar ubicada en otra máquina a la que el usuario se conecta a través de una red (cliente/servidor).
En el modelo de tres capas los comandos se envían a una "capa intermedia" de servicios o servidor de aplicaciones Java, que luego envía las sentencias SQL a la base de datos. La base de datos procesa las sentencias SQL y envía los resultados nuevamente a la capa intermedia, que a su vez los devuelve al usuario. Esta capa intermedia, que puede estar ubicada en un servidor Web, también es responsable de proporcionar los applets Java. Luego de la descarga, el cliente y el servidor se comunican directamente con llamadas de procedimientos remotos (RPC) a través del protocolo RMI (Invocación de Método Remoto). Por último, el servidor Java transmite a través de los recursos en segundo plano usando controladores de base de datos nativos o JDBC.
El modelo de tres capas es atractivo para los administradores de TI porque la capa intermedia permite mantener el control del acceso a los datos de la empresa. Estas capas intermedias se escribían tradicionalmente en C o C++ porque ofrecen un desempeño muy rápido. Sin embargo, con la introducción de los compiladores que traducen el código Java en código específico de la máquina, ahora es muy práctico implementar la capa intermedia en Java. Esto representa una gran ventaja, ya que es posible aprovechar el poder de Java y sus características de multithreading y de seguridad.
Java ofrece más
Java ofrece aun más flexibilidad al permitir que las empresas usen las bases de datos e información de acceso que ya están instaladas aunque se encuentren almacenadas en un DBMS (Sistema de Administración de Base de Datos) diferente. La combinación de Java y JDBC hace que la distribución de información sea fácil y económica. La instalación y el control de versión también se simplifican. Un programador puede escribir una aplicación o actualización una vez, y ponerla en el servidor, proporcionando acceso a la última versión. Dado que los ejecutivos confían en los servicios OLAP para tomar decisiones, Java proporciona una forma mejor de distribuir las actualizaciones de la información a los clientes externos.
Independencia de plataforma e interface familiar
El poder de esta arquitectura de tres capas está en que permite que los usuarios operen en 150 plataformas diferentes que ofrezcan soporte para Máquina Virtual Java (JVM) o navegadores de Web basados en Java, incluyendo Internet Explorer y Netscape Navigator. La interface conocida del navegador permite reducir los costos de capacitación, ya que los usuarios se encuentran en un entorno familiar independientemente de su sistema operativo, y los desarrolladores pueden adaptar aplicaciones para la Web. Muchos usuarios ya están familiarizados con el proceso de señalar y hacer clic en enlaces, y el proceso OLAP de consulta y manejo es similar.
El navegador muestra los datos a los usuarios finales en forma de gráficas de barras, tortas y grillas. Con un simple clic en las gráficas, los usuarios pueden manipular los datos y ver cambios instantáneamente en la apariencia de la información. La organización de los datos en pantalla representa una gran ventaja para el usuario, ya que es posible colocar y organizar los datos en cualquier orden, filtrar, identificar y establecer excepciones para cualquier consulta. Por ejemplo, el personal de ventas puede analizar la información de las ventas, mientras que el equipo de recursos humanos puede consultar datos referentes a su campo en particular.
Otra ventaja que proporciona el uso de Java en la Web es que evita las limitaciones de HTTP y HTML. El servidor Java puede generar HTML, pero generalmente produce los datos en un formato propietario para que sea posible verlos directamente en el navegador Java del cliente. Este último enfoque brinda la posibilidad de codificar las comunicaciones para mejorar la seguridad.
Informes instantáneos
Esta arquitectura puede acceder a los datos en cualquier sistema que soporte ODBC, JDBC o exportación de archivos ASCII. También significa que los usuarios pueden ejecutar consultas sobre la marcha y que ofrece un alto grado de interactividad al compilar y generar informes. Las ventajas de utilizar Java van más allá de informes estáticos al permitir que los datos se analicen en tiempo real. En vez de recibir informes preparados, los gerentes pueden crear sus propios informes, con la flexibilidad de manipular la información para descubrir tendencias y áreas problemáticas. Ahora los gerentes son más autosuficientes y no dependen del departamento de TI para obtener una gran variedad de informes personalizados.
Reduce los costos de mantenimiento a través de "thin clients"
El enfoque de arquitectura centralizada de una aplicación OLAP totalmente Java en la Web reduce los costos de distribución y soporte. El "thin client" permite que los administradores de TI reduzcan los costos de actualizaciones y mantenimiento al actualizar a todos los usuarios simultáneamente en toda la empresa en vez de hacerlo nodo por nodo. Esto da como resultado un enorme incremento de la productividad y eficiencia tanto para los usuarios finales como para los administradores de sistemas. La ejecución basada en el servidor es un factor importante al reducir los costos totales de uso (TCO).
Conclusión
La característica más innovadora de la Web es su habilidad de distribuir y transmitir información. En el futuro las compañías van a necesitar que sus gerentes regionales, personal de ventas, e incluso sus clientes tengan más acceso al centro de datos de la empresa. La finalidad no sería solamente verificar qué está sucediendo en sus distritos o cuentas, o realizar consultas básicas e informes de estadísticas, sino lograr que sus opiniones tengan más peso con respecto a la mercadería que llega a sus negocios o los tipos de promociones que se realizan. Sin lugar a dudas, el valor de la información aumentará significativamente por el hecho de que más gente va a acceder a la misma. Esto significa que la información correcta va a estar al alcance de la gente que corresponde en cualquier momento y en cualquier lugar
O3 (Object Oriented Olap), es la primera herramienta OLAP (On-Line Analytical Processing) del mundo, desarrollada íntegramente en JAVA™
Es un software para BUSINESS INTELLIGENCE, que otorga sentido a sus datos corporativos, proporcionando el análisis de su negocio y permitiendo así identificar su ventaja competitiva.
Especializado en realizar sofisticados análisis multidimensionales de sus datos empresariales, O3 producirá un cambio significativo en su modelo de negocio.
Su principal objetivo es analizar datos y permitirle al usuario tener un conocimiento profundo de su información, al proveerle un acceso muy intuitivo, fácil y rápido a los datos que residen en los sistemas OLTP. Esto se logra con la creación de cubos multidimensionaes, a partir de los datos extraídos de los sistemas transaccionales. Los cubos son el objeto de análisis para O3, y cada uno de ellos se orienta al análisis de las distintas áreas del negocio.
El producto está basado en la plataforma JAVA™, y por lo tanto es adecuado para correr en ambientes Intranet o Internet, así como también en diferentes plataformas. O3 ofrece una arquitectura muy flexible, que permite al sistema correr como aplicación Standalone, cliente/servidor o arquitectura en 3 capas.
Sus principales componentes son: Browser, Organizer, Designer, Builder, Server, AdmServer
El Browser es la herramienta de análisis, usada por los usuarios finales para analizar los diferentes cubos. Es una herramienta gráfica, que despliega los datos en gráficas y grillas, permitiendo al usuario navegar por los modelos, haciendo Drills, Filtros, etc, directamente en las gráficas, usando el mouse.
El Organizer permite al usuario final organizar los distintos cubos y vistas que usa con más frecuencia, creando carpetas, subcarpetas y bookmarks.
El Designer se usa para definir los modelos que son usados luego para construir los cubos O3. Esta herramienta asiste al modelador en la definición de dimensiones, jerarquías y medidas que son parte de cada cubo, y también en el mapeo entre estos elementos y las fuentes de datos
El Builder es el componente que, basándose en el modelo, extrae los datos de los sistemas transaccionales y construye los cubos O3.
El Server permite a la solución correr en una arquitectura cliente/servidor, al procesar consultas multidimensionales hechas en el Browser, por muchos usuarios, sobre diferentes cubos, al mismo momento.
El AdmServer es la herrmienta de administración del Server. Permite al administrador del sistema agregar cubos al servidor, crear usuarios, asignarles permisos, etc.
Casos
Caso SANTA ELISA La mayor usina de azúcar y alcohol independiente de América esta en el Brasil y ha optado por incorporar soluciones de Business Intelligence para satisfacer múltiples requerimientos internos y externos de la empresa. Para esto definieron WEB OLAP como su preferencia y Java como la mejor implementación de la misma. Background Bajo la dirección entre la familia Biagi, el banco Bradesco y Usina San Geraldo, la empresa factura 250 millones de dólares anualmente. La companía Energética Santa Elisa es una empresa productora de azúcar y alcohol nada ortodoxa. Nació en 1936 en el interior de San Pablo. Es una empresa moderna, donde el Presidente Maurilio Biagi Filho esta espartanamente instalado junto con su dirección. Los funcionarios tienen, en promedio entre 15 y 20 anos en la empresa, dirigida por profesionales avanzados y comprometidos con la nuevas tendencias administrativas, tecnológicas y con la eficiencia y eficacia del rendimiento de la companía. Gano recientemente el primer premio CNI de Ecología, en la categoría de Materia Prima. Entre los principales clientes del país están Coca-Cola, Tostines, Nestle, Parmalat, Phillip Morris y exporta para Oriente Medio, Africa y USA. Hoy día Santa Elisa se encuentra recuperando una franja de mercado muy importante, que se produjo con el desfasaje de la economía Brasileña.
Informática y caña
Desde la recepción de la cana hasta su procesamiento, todas las etapas de la producción están automatizadas. Para brindar una idea del movimiento, llegan diariamente a Santa Elisa 2000 camiones cargados de cana de azúcar, cada una con 33 toneladas de cana, además de mercaderías e insumos.
En realidad, la mezcla de cana de azúcar e informática viene de tiempo atrás, ya en los comienzos del 80 se procesaban todas las transacciones en forma automatizada desde la recepción de la mercadería.
A pesar de ser una empresa agroindustrial y con raíces coloniales, la tecnología ha sido tomada como un valuarte de la empresa.
Base de datos para misión critica
Con los volúmenes diarios generados por el negocio, la base de datos fue creciendo a lo largo de los anos y hoy podríamos decir que es de una envergadura muy importante.
En el correr de los anos se ha logrado estabilizar en forma excelente los sistemas de misión critica en las aréas de RRHH, finanzas, contabilidad, costos, control de cana, producción agricola, boletín industrial, facturación, análisis de crédito, control de mantenimiento de flota de vehículos, servicio a clientes, por lo cual se había llegado a una nueva decisión estratégica, el análisis de la información:
Los usuarios de Santa Elisa
Santa Elisa parece que siempre tuvo usuarios hambrientos por la información. Todos los funcionarios siempre han exigido una evolución constante del sistema y la companía siempre ha respondido eficientemente a esto, creando un flujo natural rumbo a las nuevas tecnologías.
La fuerza de trabajo evoluciona cuando se le da condiciones para eso, y la informática es una herramienta fundamental en ese sentido? dice Henrique Rodriguez, Director de Control.
La exigencia de los funcionarios fue tal que se creo un comité de informática donde representantes de cada departamento trajeron sus necesidades. Maurilio Biagi, el presidente de la Santa Elisa, tuvo una participación en todo el proceso de implantación de la cultura informática en la empresa.
"La exigencia de los usuarios hoy en día movieron su exigencia a los sistemas de apoyo a la decisión. Con los sistemas de ejecución de la empresa en funcionamiento, necesitaban de un sistema donde poder navegar por la información, cruzarlas en tiempo real y verlas a través de un lenguaje gráfico. Ahí fue donde comenzamos a pensar en una herramienta de Business Intelligence" dice Henrique.
A su vez los clientes de la usina quería tener acceso a nuestra información no solo con los sistemas de EDI, sino tener un nuevo nivel de operación sobre sus datos, producciones, pedidos, etc., nos pedían información ejecutiva de su "área de datos".
La estrategia de análisis de información
Debido a la imperiosa necesidad de Santa Elisa de poner en practica los beneficios de esta tecnología y a su capacidad de integración con la tecnología ya existente, se ve la oportunidad de su incorporación mediante proyectos cortos y de alto impacto en las áreas claves.
La estrategia consiste en el desarrollo de modelos multidimensionales que ataquen la descripción de áreas o temas específicos. Estos modelos son puestos en marcha, e incorporados al proceso diario de trabajo, aprovechando los cortos tiempos que también presenta el entrenamiento en el uso de los sistemas por parte de los usuarios finales.
Componentes para definir una solución
A su vez Santa Elisa quien históricamente ha llevado una vanguardia tecnologica, decide enfrentar este nueve desafío incorporando las nuevas tendencias tecnológicas como son Un enfoque centrado en la red - Internet - Intranet Un enfoque proactivo del análisis del negocio (tecnologías de agentes)
El enfoque centrado en la red
Santa Elisa reconocía muy bien los problemas bien conocidos del mundo convencional cliente-servidor y no querían en esta nueva etapa incurrir en esta problemática, por lo cual se focalizaron en ubicar una solución con un thin-client y que tuviera una capa intermedia de procesamiento, donde la principal función del cliente fuera la presentación lógica, o sea Santa Elisa quería moverse a la segunda generación de la arquitectura cliente servidor.
Por lo tanto tres aspectos extremadamente relevantes había que tener en cuenta estar en la punta tecnológica, Business Intelligence, Internet, Segunda generación de cliente-servidor.
En esta integración de tecnologías, cambiaría la naturaleza de lo que en si mismo cada una de ellas es, brindándole una característica no solo de OLAP o Business Intelligence, sino un ámbito mucho mas general como aplicación en si, tanto a nivel de funcionalidad, como de los usuarios que alcanzaría esta aplicación de BI. Se abriría la puerta a un nuevo tipo de usuario, mas general, no solo el power-user, ya que el uso de BI a través de un Browser, permitiría acceder cada vez mas a todos los usuarios que analizan información.
Este panorama abrió nuevas opciones de habilitar a los clientes a tener acceso a BI de Santa Elisa a través de una aplicación de Web-Business Intelligence, lo que permitiría que todo cliente accediera a través de través de browsers genéricos, que brindarían directamente la multiplataforma.
La selección tecnológica confluía en
todos sus aspectos hacia la tecnología Java
1.-Arquitectura escalable
2.-Point to point connectivity y la seguridad que provee
3.-Independencia de la ubicación
4.-Independencia tecnológica
Santa Elisa, luego de una larga evaluación de herramientas, decidió optar por O3 como herramienta OLAP para todo el uso de análisis gerencial y soporte a la toma de decisiones de la companía. La expectativa de los usuarios de la companías, así como nuevos proyectos (como customer relationship managment) se hacían concretos con esta plataforma tecnológica. A su vez el producto con sus características nos abría un nuevo conjunto de posibilidades, las cuales no estaban contempladas en nuestros requerimientos iniciales, entre las que podemos enumerar
Varias arquitecturas en una misma solución
1.-Standalone
2 tiers
3. three tires
Estas tres posibilidades nos permitían incorporar al equipo de usuarios móviles de la companía, con actualización de los Data Marts via FTP, lo cual sumado al uso del Web, brinda al equipo de usuarios móviles una flexibilidad total.
A su vez la ejecución vía Internet/Intranet y la simplicidad de uso, permitió acceder a los clientes de Santa Elisa a su propia información, organizada en forma multidimensional, permitiendo darle una velocidad a los proyectos no pensados anteriormente por la empresa.
LDAP support
Permitió brindar un nivel superior en lo que es el acceso y disponibilidad de la información. LDAP brinda soporte para publicar soportes los cubos, modelos, vistas, servidores, etc., manejándolo como todo un servicio mas de la red.
Multiplatform in the server side
Santa Elisa había estudiado el movimiento de Java hacia el lado del Server por lo cual tener un Sever multimensional en Java permitió potenciar esta tendencia y poder mantener la multiplataforma del lodo del servidor. Business Active Analysis
La tecnología hoy día la encontramos mas avanzada que los requerimientos de los usuarios, por lo cual la alta capacidad de análisis activo con tecnología de push, permitió darle a los usuarios de Santa Elisa no solo un cambio en la calidad del trabajo, sino un aumento de productividad y eficiencia muy importante.
Un Unico producto para todas las plataformas
Santa Elisa, por la alta carga de trabajo de sus profesionales, necesita concentrar sus esfuerzos como toda empresa eficiente hoy en día, lo que le llaman en SE "esfuerzos centrales", por lo cual era imperioso lograr una misma plataforma de BI para el desktop, para Internet y para Intranet, con un mismo entrenamiento lograr un uso profundo en todas las plataformas de ejecución. Eficiente en el desktop, en Intranet e Internet
Santa Elisa a través de sus relevamientos había descubierto que muchos productos al ser portados sobre Internet perdían su performance, las características de O3 y su estructura informática sobre Java logran mantener una alta performance en todas las plataformas.
Multiplataforma.
O3 tienen todos sus bases de programación en 100% Pure Java, sobre Java Fundation Clases de JavaSoft y hace uso extensivo de JavaBeans, lo cual brinda una independencia total de la plataforma, corriendo en todo Web-Browser.
Los resultados obtenidos
Santa Elisa ha logrado en implantar una solución de Business Intelligence, sobre todas las áreas operativas de la empresa. Hoy día ya un conjunto de usuarios muy importantes de la empresa utilizan O3, y se ha llevado la toma de decisiones a todo nivel de la empresa, no solo a los cargos ejecutivos.
Santa Elisa hoy día se encuentra focalizada en darle un nuevo enfoque a la organización de la empresa y con O3 la Integración de Modelos de Performance y la creación de un modelo de "holistic perfomance", esta adopción tecnológica ha puesto a la companía Santa Elisa en un lugar privilegiado por la altísima capacidad de adaptación a nuevas tendencias de managment bajo una misma infraestructura tecnológica.
Caso de resultados
bancarios
Banco do Estado de Maranhao
Un banco necesita realizar un Proyecto de Evaluación de Resultados Bancarios para poder disponer en cualquier momento de todos los indicadores de rentabilidades.
Uno de los mayores desafíos de un Banco es el tiempo de implementación del proyecto, pues precisa de resultados a corto plazo. Alguien dijo: un Banco necesita de sistemas de apoyo para la toma de decisiones que puedan ser utilizados por el web, tanto por la Internet corporativa como por la Internet de sus principales gerentes y directores.
Los usuarios exigen un sistema de análisis de informaciones gráficas, intuitivas y de fácil utilización, para tener agilidad en el análisis de las informaciones.
A partitr de esos objetivos, CHOICE, una empresa especializada en Business Intelligence, donde una de las principales áreas de atención de proyectos de Datawarehouse, desarrollan un producto personalizado que puede ser aplicado en cualquier banco. Este producto cubre las necesidades de cada banco con versiones ya liberadas.
La misión de Choice es "Proporcionar soluciones que transformen la tecnología en ventajas competitivas para nuestros clientes".
Soluciones de Choice Choice tiene toda la solución de datawarehouse para los Bancos, atendiendo a todos los desafíos.
Para atender el desafío del tiempo de implementación, Choice utiliza su gran diferencial competitivo, la metodología DM2.
DM2 es una metodología para la creación de datawarehouse, que permite la implementación del proyecto por área de negocio de la empresa.
Este es un diferencial muy grande porque con un ciclo muy corto de tiempo es posible que el Banco observe el retorno de la inversión realizada en el proyecto.
Para atender el desafío en la toma de decisiones Choice utiliza O3. Este producto es el único sistema 100% puro Java del mundo, esto tiene muchas ventajas, como ser, total integración con Web, permitiendo así que los usuarios analicen las informaciones de sus clientes por Internet.
Uno de los puntos más importantes es la facilidad en el uso de la herramienta O3. Todas las áreas consiguen llegar a todas las informaciones existentes a través de gráficos y planillas, resultando de una alta productividad en cuanto a la velocidad de acceso y análisis a información estratégica.
Analistas, gerentes y ejecutivos de Bancos logran realizar análisis que nunca antes habían tenido disponibles, permitiendo así tomar decisiones fundamentadas y mucho más rápido.
Principales resultados ofrecidos
os principales resultados obtenidos por la solución de CHOICE : Evaluación de Resultados Bancarios son:
Créditos Rotativos
Análisis de perfil de tomador de crédito rotativo, clasificando los nuevos productos ofrecidos, por el canal de movimiento utilizado, por el tipo de movimiento, y por el tipo de tomador de tiempos entre otros factores.
A partir de ese análisis informaciones como saldo de operaciones, multas y comisiones entre otras pueden ser facilmente obtenidas.
Control de Financiamientos Análisis sobre los financiamientos obtenidos por los Bancos, considerando el tipo de perfil del cliente, tipo de operación financiera y canal utilizado.
Los Análisis se realizan con valores de operaciones, valores de encargos, intereses y rentas a apropiar.
Cuenta Corriente Análisis consolidados de Saldos, intereses,de todas las cuentas corrientes del Banco, en función del canal de atención, del tipo de movimientos de las agencias.
Cajas de Ahorros Análisis consolidados de todas las Cajas de Ahorros del Banco, a partir de la agencia, el canal de movimientos, persona física o jurídica, tipos de movimientos y tipos de operaciones ocurridas. Este análisis proporciona informaciones de Saldo, Saldo Medio, Captación Líquida e intereses. Cobranza Bancaria Análisis de toda la cobranza bancaria efectuada por el Banco, a partir de la agencia, el tipo de persona (física o jurídica), tipo de cobranza y canal utilizado, informando la cantidad de lanzamientos, valores captados y valores de tarifas de operaciones.
Arrendamientos y Convenios Análisis de las rentas obtenidas por tarifa, valores arrendados y cantidades activas recorridas en determinado período bancario en función a un tipo de convenio.
Pago de INSS Análisis consolidado de recaudación de INSS, generando informaciones de valores de pagos y tarifas recibidas mensualmente a partir de la agencia bancaria, forma de pago y canal de atención utilizado. Pago de Funcionarios Públicos Análisis del servicio de pago de funcionarios públicos, considerando la agencia de origen, el canal usado y la empresa del funcionario.
Pago de IPVA Análisis consolidado del pago de IPVA hecho al Banco, generando informaciones mensuales de valores y rentas recibidas por el Banco considerando el canal de movimiento utilizado.
Impuesto de Renta de Persona Física Análisis del servicio de pago de impuesto de renta de persona física, considerando el canal de atención utilizado. Este análisis genera indicadores de devoluciones, cantidades de devoluciones y total de tarifa por transacciones.
Introducción
La metodología DM2 se basa en las necesidades de información a nivel gerencial, donde la información debe ser encarada como patrimonio de la empresa, accesible a quien la necesite.
Por la propia naturaleza del ambiente, el modelo cumple con su objetivo (atender las necesidades de información del nivel gerencial y ejecutivo de una empresa), esta metodología se asemeja a la forma top-down , y acorta en función razonable el tiempo entre el inicio del análisis y la implantación. Esta rapidez no solo es buena para el cliente sino que también es exigida y necesaria por el propio ambiente que lo rodea. Quien decide no puede esperar meses de análisis, proyecto e implementación para poder tomar decisiones. No es necesario en todos los proyectos la construcción de un data warehouse. Esencialmente está concentrada en crear un modelo multidimensional OLAP (On-Line Analytical Processing) que atienda tales necesidades. Ella refleja las preocupaciones más relevantes de un área de negocio. Resumiendo, este conjunto brindará un verdadero soporte para la toma de decisiones. Se puede decir que la metodología se basa en dos principios: conocer la estructura del negocio o core business, la empresa conoce las necesidades de información de los usuarios finales. Conocido el negocio sabremos qué órganos deben de ser entrevistados, estudiadas estas necesidades de información, sabremos "qué" buscar y "dónde" están esos datos. Arquitectura Genérica En resumen, los elementos necesarios para la implementación de sistemas de apoyo como la toma de decisiones sigue la siguiente forma: Definición del ambiente y Areas de negocio Necesitamos tener definido el ambiente en el cual se desarrolla el proyecto. Estaremos siempre tratando con los altos niveles de la empresa. Conocer las áreas del negocio es vital para el suceso final. De esta forma, además de superar cuestiones departamentales, estaremos evidenciando qué es lo verdaderamente importante para la empresa, así se esté analizando una pequeña parte de ella. Por eso, este análisis será más utilizado para negocios que para una estructura organizacional. Análisis de Necesidades de Información: Debe consistir en el análisis de las necesidades de información de gerentes y ejecutivos involucrados. Sus decisiones están basadas en sus conocimientos proporcionados por la propia empresa. Es la forma de ver y usar estos datos lo que nos proporciona ventajas competitivas sobre la competencia. Análisis de Fuentes de Datos: Es necesario también un análisis sobre los datos de la empresa para verificar si existe información suficiente para atender las necesidades y calidad de la información. Proyecto de Extracción de Datos Se sigue un proyecto de acceso (Extracción) de los datos de la manera más correcta sin interferir en el trabajo de equipo de informática o de la persona responsable. Elaboración de Data Marts (modelo multidimensional) Conocidas las necesidades de los ejecutivos, detalles sobre los datos para ser usados en la extracción, se pasa al proyecto y construcción de los Data Marts, un modelo multidimensional OLAP. Personalización de las visiones del modelo Como resultado del análisis con los ejecutivos será posible reunir las necesidades más solicitadas por cada uno de ellos. Esta personalización aumenta la capacidad de análisis de las personas encargadas de la toma de decisiones por no tener que preocuparse en saber como llegar a ella: simplemente ella está ahí para ser usada. Con esto tenemos todas las informaciones relevantes del proyecto.
DM2
DM2 surge para organizar y estructurar la forma de obtención de información e implantación del modelo multidimensional, basado en la Arquitectura Genérica presentada anteriormente. De esta forma, ella se divide en: Análisis Corporativos Definición del ambiente de áreas del negocio Desarrollo de Data Marts Análisis de las necesidades de información Análisis de fuente de datos Proyecto de extracción de datos Elaboración del modelo multidimensional Personalización de visiones de los cubos Análisis Inter-departamental Eliminación de redundancias Dependiendo de lo extenso y complejo que pueda ser el proyecto, algunas etapas pueden no ser necesarias. Proyectos piloto y otros proyectos de pequeña envergadura no necesitarían DM2 completa, en tal caso se utilizaría DM2 Light (versión de DM2 que no incorpora el Análisis Corporativo, ni Análisis Departamental y suprime parte de la documentación de desarrollo de Data Marts).
Análisis Corporativos
El primer paso consiste en el análisis de la corporación a partir de la misión y áreas de negocio. No estaremos analizando departamentos, sectores, etc., estaremos analizando las funciones de negocio y sus procesos. De esta forma se tiene un análisis volcado hacia el negocio, el "alma" de la empresa, independiente de su estructura organizacional. La estructura de esta fase aumenta cuanto mayor sea la cantidad o el tamaño de la propia estructura porque además de evidenciar la presencia de diversos usuarios finales (gerentes y administradores), indica que estarán implicadas más de una función de negocio de la empresa.
El resultado de este análisis es un documento que caracteriza a la empresa con su estructura organizacional, las áreas del negocio involucradas en el proyecto con un cronograma a ser cumplido para la realización del mismo. Esto es importante porque es a partir de ello que varias orientaciones serán tomadas durante el proyecto. Prioridades, áreas y negocios, directores y gerentes a ser entrevistados son algunas de las cosas que están acá definidas, una falla podría atrasar el resto del proceso. No es aconsejable el uso de esta fase en proyectos pequeños o pilotos, sería un gasto innecesario de tiempo en algo cuyo retorno no sería muy significativo ya que proyectos pequeños están alrededor de una parte de un área del negocio de la empresa, o dentro de un departamento aislado.
Desarrollo de Data Marts Este es el cuerpo principal de la metodología. Identificados los procesos de cada función relevante del proyecto, se obtienen los Data Marts (Identificación de Data Marts), se sigue con las etapas de determinación de las necesidades de información del usuario final (Análisis OLAP) y determinación de datos corporativos con el equipo de informática (Análisis OLTP). Con esto se determina el grado de viabilidad del proyecto (Análisis de Viabilidad) y se comienza con la construcción del modelo dimensional -los cubos propiamente dichos- (Proyecto OLAP) y la forma de extracción de los datos (Proyecto OLTP OLAP). Finalizando, se deben definir las visiones de los usuarios sobre los cubos y sus permisos de acceso. Identificación de Data Marts Una vez definidos los procesos de las funciones de negocio de la empresa, se puede saber cuales son los Data Marts de cada uno.
Este "mapa" tiende a ser simple, pero debe ser realizado con mucha cautela pues en este análisis podrá detectarse si alguien tiene la necesidad de acompañar o verificar el funcionamiento de alguna actividad. Esto podrá generar un Data Mart que traspase los límites de una función del negocio y también será necesario levantar todas las etapas del ciclo de producción en dicho proceso.
Análisis OLAP De esta fase se obtienen todas las informaciones que darán cuerpo al Data Marts. Los usuarios finales deberán ser los entrevistados, con estas entrevistas iremos descubriendo cuales son las necesidades de información (medidas) de cada usuario y para cada necesidad cuales son los parámetros de consulta (dimensiones) que ellos utilizan.
Estas informaciones obtenidas son el núcleo de toda la metodología, son el objetivo de todo el proyecto. Por eso se deben obtener el máximo de información sobre cada necesidad, sobre cada espectativa. La falta de alguno de ellos puede alterar significativamente el proyecto OLAP (consecuencia natural del Análisis OLAP), igual que si se descubre que es imposible atender necesidades de información (generalmente por no haber datos correctos o suficientes para su determinación), se debe registrar el deseo del usuario. Este relevamiento y análisis se debe hacer antes de la verificación de la existencia de la fuente de datos. Para asegurar su calidad habrá que analizar: el cronograma, las diferencias entre el Análsis OLAP y el Análisis OLTP, las dificultades de las entrevistas, la complejidad de Data Mart, la complejidad del proyecto. Al final, tendremos la preparación del Documento de Análisis OLAP para ser evaluado junto con el usuario final. La estructura de este documento forma parte de DM2. Análisis OLTP El Análisis OLTP (On-Line Transaction Processing) va a revelar donde está el origen de la información necesaria para atender el Análisis OLAP. Estas informaciones no son invenciones o aproximaciones, son con datos adquiridos del pasado, de la historia de la empresa, datos que revelan perfiles que no pueden ser desperdiciados. Generalmente estas informaciones se encuentran en la BD corporativa.
Pero, qué es lo que realmente importa? Diversos SGBDs pueden estar siendo utilizados y las informaciones pueden estar conectadas entre sí. Se debe levantar y analizar como esto está funcionando y si se da alguna conexión entre los sistemas. El Modelo de Entidad - Relación (MER) existe o está incomplettto? Las mejores personas para responder sobre los datos de la empresa serán los DBAs de diversos sistemas que tengan información para los cubos. Las cuestiones sobre la calidad de los datos y la integración entre diversos bancos de datos merecen una atención especial. En algunos casos, esto requerirá un proyecto en particular, independiente de DM2. La propia DM2 incorpora soluciones sobre la calidad de los datos, estudiando antes algunas situaciones que pueden comprometer el objetivo final: la construcción del modelo multinacional que atienda a todos aquellos que estén en la toma de decisiones.
Al final de esta fase, tendremos el Documento de Análisis OLTP para ser evaluado junto al equipo de informática envolucrado. La estructura del este documento también es parte de DM2.
Análisis de Viabilidad En esta fase se sintetizan las diferencias entre las necesidades de información y los parámetros de consulta de los datos de las BD corporativos. Estas dificultades ya fueron evaluadas, pero ahora se debe estudiar lo difícil y complejo que será atender a los usuarios. Se debe concluir el grado de dificultad que será desarrollar los cubos, los procesos de extracción y conversión. El grado de dificultad es aprovechar aquellas informaciones que no estaban en BD ni en ningún archivo y que serán aquí definidas. Para estos casos se deben definir como los datos serán disponibles. Proyecto OLAP Esta fase del proyecto OLAP consiste en transformar todos los datos obtenidos de la fase de Análisis de OLAP, en el modelo multidimensional de OLAP. Al final de esta fase, el modelo podrá ser implementado en algún paquete de software que contenga herramientas para aplicaciones OLAP.
Finalizado el análisis, se pasa a construir el modelo OLAP, definiendo las medidas, las dimensiones y jeraquías , los cubos, las visiones, seguido del abordaje al modelo multidimensional. Lo que era Necesidad de Información se pasa a llamar medida, los parámetros de consulta son lógicamente agrupados (por. Ej: producto, tipo de producto,...son características de producto) definiendo una dimensión y sus atributos. Una de estas dimensiones merece atención especial: el Tiempo. Las dimensiones deben ser estructuradas en función de sus atributos. Por ejemplo, la dimensión tiempo está formada por Año, Año está formado por Meses y Meses está formado por Días, a esta estructura de agrupamientos la denominamos jerarquía. Se debe tener cuidado en el formado de estas jerarquías para que no perder la eficiencia. Otra información relevante es la granularidad de medida, definida como cada registro de una medida en un cierto intervalo de tiempo (ej: una necesidad de información por ver el total de los productos vendidos que fueron devueltos por semana, no será necesario almacenar el total de la devolución por día, pero si por semana).
Los cubos serán definidos a partir de la similitud entre las tuplas (medidas, dimensiones), o sea, de varias medidas utilizaremos las mismas dimensiones y esas medidas corresponderán al mismo proceso de función del negocio, entonces estas medidas formarán parte de un mismo cubo. Al definir cada cubo se debe también definir la periodicidad de los mismos, por ejemplo cuando será su actualización. Otro detalle a tener en cuenta es el aprovechamiento de las dimensiones entre los diversos Data Marts de los cubos. Proyectos grandes pueden involucrar varios equipos entonces ocure que varios cubos utilizan una misma dimensión. Al final de esta fase tendremos un Documento de Proyecto OLAP que contiene las informaciones necesarias para la implementación de los Data Marts y los cubos con sus dimensiones y medidas. La estructura de este documento también es parte del DM2.
Proyecto OLTP OLAP Esta etapa consiste en preparar los SGBDs y el servidor OLAP para la migración de los datos necesarios a O3. Así mismo el armado final entre medidas y dimensiones con la fuente de datos. En los proyectos que lo necesiten, debemos crear un modelo de metadatos que reúna todos los datos que serán procesados. Para cada una de las medidas de dimensiones, incluyendo las jerarquías, debemos registrar el origen y la definición del origen. Esto brindará apoyo para la próxima fase, además de facilitar futuras consultas o alteraciones. De la misma manera verificaremos los tipos básicos de datos de los bancos de datos. Los valores que serán guardados por el banco de datos OLAP deben de tener un tipo de dato previamente definido y solo pueden ser aquellos ya soportados por el banco. En tales casos, el valor de las variables deberá ser convertido para algún tipo válido en la base OLAP. En fin, estaremos definiendo las consultas SQL y serán hechas para la obtención de los datos corporativos. Algunos sistemas OLAPs tienen optimizaciones que hacen que se elimine el uso del SQL, reduciendo así el tiempo de ejecución. Por lo tanto se debe considerar el ambiente de extracción de modelo mutidimensional que será usado.
Al final de esta etapa tendremos un proyecto OLTP OLAP que contendrá las informaciones necesarias para la extracción de datos de los bancos de datos corporativos. La estructura de este documento también es parte de DM2. Proyecto de Visualización Finalmente, se crean las visiones y se implementan los accesos de los usuarios y los cubos de Data Marts ya creados. Se debe volver al usuario final para que de su aprobación al proyecto. A esta altura el modelo OLAP ya debe estar construído y la migración de datos y debe de ser posible. Al final de esta etapa tendremos un Documento de Proyecto OLTP OLAP que relaciona cada usuario con los Data Marts, cubos, dimensiones y medidas que utiliza. La estructura de este documento también es parte de DM2.
Análisis Inter Departamental En proyectos grandes con varios sectores involucrados y varios equipos trabajando, puede ser necesario que sean hechos análisis sobre los modelos que están siendo creados. De esta forma se asegura la calidad y se intenta aprovechar la información ya obtenida