QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS EN INFORMÁTICA

Transcripción

1 INSTITUTO POLITÉCNICO NACIONAL UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS INTELIGENCIA DE NEGOCIOS. APLICACIÓN EN LA ADMINISTRACIÓN DEL PRESUPUESTO EN UNA EMPRESA DEL SECTOR PÚBLICO. T E S I S QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS EN INFORMÁTICA P R E S E N T A GUSTAVO DAVID VEGA VIVAS DIRECTOR DE TESIS: M. EN C. GUILLERMO PEREZ VÁZQUEZ CODIRECTOR DE TESIS: M. EN C. MARTHA JIMENEZ GARCÍA MÉXICO, D.F. 2010

2 II

3 III

4 Resumen El presente trabajo consistió en el diseño e implementación de una herramienta de software usando tecnología de inteligencia de negocios, que cuenta con las características de confiabilidad y oportunidad, así como las últimas tecnologías de punta en materia de informática, para el apoyo a la toma de decisiones en los niveles estratégicos de la Secretaría de Comunicaciones y Transportes. Para ello, se realizó primeramente una identificación de la información y las fuentes de datos que utilizan las áreas involucradas para la elaboración de informes. Después se diseñó una base de datos multidimensional para consolidar esa información y se construyeron las interfaces de usuario necesarias, que sirven para mostrar los parámetros de control que los usuarios requieran evaluar. En el primer capítulo, se describe el significado, características y beneficios de los Sistemas de Información Ejecutivos, así como los conceptos de almacén de datos y de mercado de datos. También se habla sobre modelos de datos multidimensionales, cubos de información y minería de datos. En el capítulo dos se describen las actividades que se desarrollan en las áreas involucradas y la razón de querer implementar un Sistema de Información Ejecutivo en la organización. Finalmente, en los capítulos tres y cuatro se presenta la propuesta de solución y se hace una medición del impacto que tuvo su implementación, la cual resultó ser muy favorable en términos de confiabilidad y oportunidad a nivel estratégico y operacional. IV

5 Abstract This work concerns the design and implementation of a software tool using business intelligence technology, which has the characteristics of reliability and timeliness, and the latest advanced technologies in information, to support making decisions at the strategic levels of the Secretariat of Communications and Transport. This will be done first identification information and data sources that use the areas involved for reporting. Then building a multidimensional database to consolidate this information and built the necessary user interfaces, which serve to show the control parameters, require users to evaluate. In the first chapter describes the meaning, characteristics and benefits of Executive Information Systems, and the concepts of data warehouse and data mart. It also discusses multidimensional data models, data cubes and data mining. In Chapter two describes the activities that develop in the areas involved and the reason for wanting to implement an Executive Information System in the organization. Finally, in chapters three and four present the proposed solution and provides a measurement of the impact of deployment, which turned out to be very favorable in terms of reliability and timeliness to the strategic and operational level. V

6 Índice Relación de cuadros, gráficas e ilustraciones... IX Glosario... 1 Introducción... 3 Capitulo 1 Inteligencia de negocios Sistemas de Información ejecutivos Características de los Sistemas de Información Ejecutivos Factores de éxito de un Sistema de Información Ejecutivo Beneficios de un Sistema de Información Ejecutivo Desarrollo de un Sistema de Información Ejecutivo Como mejoran los SIE el proceso de toma de decisiones Concepto de data warehouse Características de un data warehouse Implementación de un data warehouse en la organización Personal que participa en la implementación de un data warehouse Arquitectura para la construcción de un data warehouse Diferencia entre un data warehouse y una base de datos relacional El data warehouse como un sistema de misión crítica Relación de un SIE con un data warehouse Ventajas y desventajas en el uso de un data warehouse Concepto de data mart Construcción de un data mart Requerimientos para la construcción de un data mart Data mart distribuido La complejidad de transformar datos en información en una solución de data warehousing Modelo de datos multidimensional VI

7 1.4.1 Modelo de estrella Modelado de consultas empresariales Minería de datos (data mining) Capitulo 2 La Subsecretaría de Infraestructura de la SCT La Subsecretaría de Infraestructura La Dirección General de Carreteras (DGC) La Dirección General de Conservación de Carreteras (DGCC) La Dirección General de Servicios Técnicos (DGST) Información a analizar en las áreas involucradas Capitulo 3 Diseño y desarrollo de la propuesta de solución Planteamiento del problema Objetivos de este proyecto Metodología utilizada Análisis FODA de la solución Diseño lógico del Sistema de Información Ejecutivo de Infraestructura Requerimientos de información Análisis de requerimientos Descripción funcional del SIE Descripción de los procesos desarrollados Parámetros de información que los usuarios pueden consultar Diseño de consultas empresariales Herramienta que se utilizó para la implementación Diseño físico de la base de datos Desarrollo del data mart Interfaces gráficas para el usuario final Herramientas de análisis VII

8 3.8 Seguridad de la información Capitulo 4 Impacto de la propuesta de solución Desempeño de la aplicación desarrollada Elementos básicos de la arquitectura (dimensiones dispersas y densas) Estimación de espacio en disco Estimación de espacio en memoria Pruebas de funcionamiento Medición de la calidad del software elaborado Análisis de los resultados obtenidos Conclusiones Bibliografía Anexo I VIII

9 Relación de cuadros, gráficas e ilustraciones Figura 1.1 Integración de aplicaciones para la construcción de un data warehouse (diseño propio) Figura 1.2 Arquitectura de referencia del data warehouse (Gill, H. S.) Figura 1.3 Ciclo de madurez de la tecnología (Gill, H. S.) Figura 1.4 Flujo de información entre un SIE y un data warehouse (diseño propio) Tabla 1.1 Ventajas y desventajas del uso de un data warehouse (diseño propio) Figura 1.5. Proceso de transformación de datos en información en una solución de data warehousing (diseño propio) Tabla 1.2 Una vista en dos dimensiones del presupuesto ejercido (métrica desplegada) en una empresa pública, con respecto a las dimensiones tiempo y tipo de trabajo en el Estado de Baja California (diseño propio) Tabla 1.3 Una vista 3-D del presupuesto ejercido (métrica desplegada) en una empresa pública, con respecto a las dimensiones tiempo, tipo de trabajo y localización (diseño propio) Figura 1.6 Una representación de un cubo de datos de tres dimensiones de la tabla 1.3, respecto a las dimensiones tiempo, tipo de trabajo y localización. La métrica que se despliega es el presupuesto ejercido en una empresa pública (diseño propio) Figura 1.7 Representación de un cubo de datos de cuatro dimensiones (4-D) para el presupuesto ejercido de una empresa pública, respecto a las dimensiones tiempo, tipo de trabajo, localización y centro de trabajo. Solo son mostrados algunos datos de ejemplo (diseño propio) Figura 1.8 Enramada de cuboides que forman un cubo de datos de cuatro dimensiones (4-D) las cuales son tiempo, tipo de trabajo, localización y centro de trabajo. Cada cuboide representa un grado diferente de agregación de la información (diseño propio) Figura 1.9 Modelo de estrella (diseño propio) Figura Modelo de molde de consulta (Gill, H. S.) Figura La minería de datos como un paso en el proceso de descubrimiento de conocimiento (Han, Jiawei) Figura Arquitectura general de un sistema de minería de datos (Han, Jiawei) Figura 2.1 Organigrama de la Secretaría de Comunicaciones y Transportes (Manual de organización de la Subsecretaría de Infraestructura de la SCT) IX

10 Figura 2.2. Proceso de ejercicio del presupuesto en obra pública (diseño propio) Tabla 3.1 Análisis FODA para la implementación del SIE (diseño propio) Figura 3.1. Construcción de los diferentes data mart para la SCT (diseño propio) Figura 3.2. Modelo de referencia propuesto para el Sistema de Información Ejecutivo de Infraestructura (diseño propio) Figura 3.3 Sección de exportación de datos de uno de los programas utilizados para extraer datos desde las fuentes de datos para el data mart construido (diseño propio) Figura 3.4 Muestra de los datos extraídos por la sección del programa de la figura 3.3, después de la ejecución del mismo (diseño propio) Figura 3.5 Apertura del archivo en el editor de reglas de carga de Essbase con información de ejemplo (definición de una regla de carga en Essbase) Figura 3.6 Ejemplo de delimitación de campos del archivo de texto en una regla de carga (definición de una regla de carga en Essbase) Figura 3.7 Resultado de haber deshabilitado los campos 1 y 5 en la regla de carga (definición de una regla de carga en Essbase) Figura 3.8 Adición de prefijos a algunos campos para su asociación con dimensiones de la base de datos dimensional (definición de una regla de carga en Essbase) Figura 3.9 Asociación de campos en la regla de carga con las dimensiones de la base de datos (definición de una regla de carga en Essbase) Figura 3.10 Especificación del campo que contiene los valores que serán importados a la base de datos (definición de una regla de carga en Essbase) Figura 3.11 Configuración de datos de carga a nivel de definición de encabezado de una fuente de datos (definición de una regla de carga en Essbase) Figura Modelo de estrella del SIE (diseño propio) Figura 3.13 Implementación de la dimensión Métricas (diseño propio) Figura 3.14 Molde de consulta empresarial de Presupuesto (diseño propio) Figura 3.15 Molde de consulta empresarial de Programa Operativo (diseño propio) Figura Implementación de la dimensión Total Anual (diseño propio) Figura Implementación de la dimensión Centro SCT (diseño propio) X

11 Figura Implementación de la dimensión Proyecto en los niveles de grupos de presupuesto y de tipo de contrato (diseño propio) Figura 3.19 Implementación de la dimensión Proyecto en los niveles de obra y de contrato (diseño propio) Figura 3.20 Implementación de la dimensión Avance (diseño propio) Figura 3.21 Implementación de la dimensión Programa Operativo (diseño propio) Figura 3.22 Implementación de la dimensión Programa de Presupuesto (diseño propio) 116 Figura 3.23 Implementación de la dimensión Unidad Donante (diseño propio) Figura 3.24 Implementación de la dimensión Financiamiento (diseño propio) Figura 3.25 Implementación de la dimensión Año (diseño propio) Figura 3.26 Implementación de la dimensión Dato (diseño propio) Figura 3.27 Página de inicio de SIE de Infraestructura (diseño propio) Figura 3.28 Grupo de reportes para la Dir. Gral. de Carreteras Federales (diseño propio) Figura 3.29 Grupo de reportes para la Subsecretaría de Infraestructura (diseño propio) 119 Figura 3.30 Grupo de reportes para la Dir. General de Conservación de Carreteras (diseño propio) Figura 3.31 Reporte con información de muestra de obras por Estado de la Dir. Gral. de Carreteras (diseño propio) Figura 3.32 Reporte con información de muestra del presupuesto ejercido vs asignación presupuestal (presupuesto modificado) de la Dir. Gral. de Carreteras (diseño propio) Figura 3.33 Reporte con información de muestra del presupuesto ejercido, ejercido en trámite y disponible de la Subsecretaría de Infraestructura (diseño propio) Figura 3.34 Reporte con información de muestra del presupuesto de inversión y metas de la Dir. Gral. de Conservación de Carreteras (diseño propio) Figura 3.35 Addin de Excel para realizar consultas al data mart de Infraestructura (diseño propio) Figura 3.36 Consulta con el addin de Excel al data mart de Infraestructura con información de muestra (diseño propio) XI

12 Figura 3.37 Cruce entre las dimensiones tiempo, proyecto de presupuesto y región, para obtener un dato de la métrica presupuesto modificado (diseño propio) Figura 3.38 Addin de Power Point para elaborar plantillas de consulta al data mart de Infraestructura (diseño propio) Figura 3.39 Consola de administración de usuarios (diseño propio) Figura 3.40 Definición de privilegios de acceso por grupo de usuarios (diseño propio) Figura 3.41 Control de acceso a grupo de reportes por medio de Workspace (diseño propio) Figura 3.42 Definición de privilegios de acceso al grupo de reportes de la DGCC (diseño propio) Figura 4.1 Ejemplo de dimensiones dispersas (diseño propio) Figura 4.2 Representación de bloques de datos y del índice que almacena los apuntadores a cada bloque (diseño propio) Figura 4.3 Representación de un bloque de datos (diseño propio) Figura 4.4 Base de datos con dimensiones dispersas y densas (Analytic Services Database Administrator s Guide) Figura 4.5 Bloque de datos que representa la combinación de dimensiones densas para d22 -> e3 (Analytic Services Database Administrator s Guide) Tabla 4.1 Configuración de las dimensiones de la base de datos desarrollada (diseño propio) Tabla 4.2 Dimensiones dispersas cuyo atributo de almacenamiento es Almacenar dato (diseño propio) Tabla 4.3 Dimensiones densas cuyo atributo de almacenamiento es Almacenar dato (diseño propio) Figura 4.6 Ejemplo de regla de carga de información hacia la base de datos (definición de regla de carga en Essbase) Figura 4.7 Scrip de importación y ejecución de cálculo de la base de datos multidimensional del data mart (diseño propio) Figura 4.8 Archivo log generado por la base de datos, durante la importación de información al data mart de Infraestructura Carretera (Oracle Hyperion Essbase) Figura 4.9 Datos resultantes de la aplicación del cuestionario para evaluar la calidad del software desarrollado (diseño propio) XII

13 XIII

14 Glosario 4 GL El término lenguaje de cuarta generación, que se abrevia 4GL, se refiere a un lenguaje que permite al programador o usuario indicarle a la computadora qué debe hacer, en vez de cómo hacerlo. También se usa el término lenguaje natural porque la sintaxis de los 4GL puede ser muy similar a la forma como hablamos normalmente. 1 Base de datos estructurada Base de datos multidimensional Clasificador por objeto del gasto Fuente de datos Información no estructurada Una base de datos es un conjunto de información estructurada, con un contenido básicamente textual o alfanumérico, que ha sido grabada en soporte digital y que dispone, además de un programa informático que nos facilita su recuperación. 2 Es una herramienta que crea vistas multidimensionales de los datos en bases de datos relacionales. El análisis multidimensional permite a los usuarios ver los mismos datos en diferentes maneras utilizando varias dimensiones. Cada aspecto de la información producto, precio, costo, región o lapso de tiempo- representa una dimensión diferente. 3 El clasificador por objeto del gasto es el documento que ordena e identifica en forma genérica, homogénea y coherente, los recursos humanos, materiales, tecnológicos y financieros, que requieren las dependencias y entidades de la Administración Pública Federal para cumplir con los objetivos y programas que se establezcan en el Presupuesto de Egresos de la Federación. (Artículo 2 del acuerdo por el que se expide el Clasificador por Objeto del Gasto para la Administración Pública Federal. SHCP. Fecha de expedición en el D. O. F. 13-Octubre- 2000). Información variable contenida en una fuente de datos, que puede ser una tabla de Microsoft Word, una base de datos de Microsoft Access o alguna otra fuente. 4 Documentos en lenguaje natural que no suelen tener una estructura predefinida. 5 1 McLeod Jr, R. (2000). Sistemas de información gerencial, 7a ed. México: Prentice Hall. p Abadal Falgueras, E. (2001). Sistemas y servicios de información digital. Barcelona: Universidad de Barcelona. p Laudon, K. C., & Laudon, J. P. (2004). Sistemas de Información Gerencial.8va. ed. México: Prentice Hall. p Diccionario de informática e internet: Computer and internet Technology Definitions in Spanish. (2004). Boston, Massachusetts: Thomson. p Joaquim, L. (2004). Tecnologías del texto y del habla. Barcelona: Universidad de Barcelona. p. 14.

15 Metadato ODBC OLAP (On Line Analytical Processing) Proceso de negocio RDBMS Es un trabajo de referencia de datos acerca de ellos compilados por los analistas de sistemas para guiarse a través del análisis y diseño. 6 Open Database Connectivity standard o el estándar de la conectividad abierta de base de datos, se desarrolló a principios de la década de 190, con el fin de proporcionar medios independientes del DBMS para el procesamiento de los datos de una base de datos relacional. 7 En español procesamiento analítico en línea, es el proceso de craer y totalizar data multidimensional e histórica que soporte la toma de decisiones. Su objetivo principal es producir información precisa, a tiempo y entendible. 8 Es una forma concreta de ordenar un conjunto de actividades, no acotadas por barreras organizativas, con un principio y un final, coordinadas y orientadas a la consecución de un producto que genera valor par un cliente final o intermedio. El elemento fundamental en la anterior definición es la búsqueda de la satisfacción del cliente final o intermedio. Si no hay cliente no hay proceso de negocio. De hecho la empresa se ha definido como una suma de procesos de negocio y el cliente la ve cuando utiliza uno determinado. 9 Sistema mediante el cual los datos están organizados como colección de tablas, y las relaciones entre las tablas se forman a tra ves de un campo común. RDBMS es la forma abreviada, en idioma inglés, de relational database management system (sistema de administración de base de datos relacional) 10 6 Kendall. (1997). Análisis y diseño de sistemas. 3ra ed. México: Prentice Hall. p Kroenke, D. (2003). Procesamiento de bases de datos. México: Prentice Hall. p Cardoso Militao, L. I. (2006). Sistemas de Base de Datos II: teoría aplicada para profesores y estudiantes. Caracas: Universidad Católica Andrés Bello. p Arjona Torres, M. (1999). Dirección estratégica. Un enfoque práctico. Madrid: Diaz de Santos. p Diccionario de informática e internet: Computer and internet Technology Definitions in Spanish. (2004). Boston, Massachusetts: Thomson. p

16 Introducción En toda organización, sea pública o privada, la administración del presupuesto es una actividad prioritaria para el logro de los objetivos. En los últimos años, esto se ha convertido en un aspecto muy importante para las instituciones públicas, debido a la nueva Ley de Transparencia y Acceso a la Información Pública que tiene por objetivo garantizar a la ciudadanía el uso adecuado de los recursos públicos. Por otro lado, en los últimos años el presupuesto asignado a la SCT en gasto de inversión para la construcción y conservación de carreteras federales, se ha incrementando considerablemente. En el 2009 el presupuesto asignado fue de 50 mil millones de pesos. Lo que representa un aumento del 25% con respecto al del año 2008 que fue de 40 mil millones de pesos. Esto ha originado la necesidad de dotar a la Secretaría con herramientas de software que faciliten no solo la operación del presupuesto asignado, sino su control y seguimiento por los niveles estratégicos de esa dependencia, como son: la oficina del Secretario, el personal de la Subsecretaría de Infraestructura y sus direcciones generales y la Dirección General de Programación, Organización y Presupuesto (DGPOP). El conocimiento oportuno y permanente de la ejecución de las obras, tanto física como financiera, es fundamental para el análisis y toma de decisiones. La Subsecretaría de Infraestructura en coordinación con la Dirección General de Programación, Organización y Presupuesto, tienen la responsabilidad de ejercer más del 70% del presupuesto total asignado a la SCT, destinado principalmente a la construcción y mantenimiento en Infraestructura Carretera. Esta cantidad de recursos a invertir, da una mejor idea de la importancia que una herramienta de software puede tener, si proporcione los elementos de información necesarios para tomar decisiones. En el aspecto tecnológico, la SCT ha operado desde el año de 1992 con sistemas de información basados en tecnología cliente-servidor, utilizando Progress como motor de base de datos. Progress es una base de datos de cuarta generación (4GL), que permite generar de forma muy rápida, acceso a la información almacenada. Sin embargo y a pesar de contar con sistemas de información que automatizan en gran medida la administración de las obras de infraestructura carretera y que permiten a las áreas usuarias ejecutar en forma precisa el presupuesto asignado, el personal de la Subsecretaria de Infraestructura y de sus áreas normativas, no cuentan con las herramientas de software adecuadas que les permitan conocer de manera rápida y oportuna la situación de las obras carreteras a nivel nacional y 3

17 controlar aspectos como avance físico, avance financiero, gestión de los contratos asignados, presupuesto ejercido, entre otros. Es importante mencionar que en la actualidad las empresas tanto públicas como privadas, enfrentan el problema del explosivo crecimiento de datos que producen, lo cual es un reto que no solo se limita a la administración de una cada vez mayor base de datos, sino que ahora también es preciso gestionar los datos de manera que ayuden a los ejecutivos de una organización a tomar decisiones de manera rápida, con base en la información almacenada. Para las empresas, esa información puede llegar a representar la inversión de muchos recursos financieros y humanos durante años. Pero el problema ya no es el almacenamiento de esa información. En la actualidad, el problema se ha convertido en buscar la manera de utilizar esos datos, para aprovecharlos como un recurso estratégico de las organizaciones. En esos datos se encuentran contenidas tendencias de mercados, necesidades y motivaciones de los clientes, necesidades de producción, recursos invertidos, estados financieros, necesidades de consumo, etc. Pero para descubrirla y obtener únicamente la información más importante, es necesario analizar esos datos e interpretarlos. Hoy en día, se habla de un nuevo término que más que un concepto es un conjunto de tecnologías de análisis de datos para obtener la información estratégica que las organizaciones necesitan: inteligencia de negocios o business intelligence, por sus siglas en ingles (BI). Ya hace algunos años, se hablaba de los Sistemas de Información Ejecutivos (SIE) o de los Sistemas de Información de Soporte a las Decisiones (SSD). Sistemas cuyo propósito era llevar información a los niveles gerenciales de la organización para tomar decisiones más rápidas y eficaces. Sin embargo, las tecnologías que se han desarrollado en inteligencia de negocios, han propiciado mayores avances y mejores resultados. Para la Secretaría de Comunicaciones y Transportes, se trata de un concepto nuevo en cuanto a tecnología se refiere. Actualmente, la dependencia cuenta con sistemas de información transaccionales que procesan y almacenan el detalle de la operación diaria. Sin embargo, lo que se busca con la aplicación de tecnología de inteligencia de negocios en la Secretaría, es llevar la información de las áreas operativas hacia las áreas estratégicas de manera rápida y precisa sin intervención humana, para proporcionar información al personal encargado de tomar decisiones en esas áreas. El presente trabajo que consistirá en la generación de un Sistema de Información Ejecutivo basado en tecnología de inteligencia de negocios, se desarrollará en 4 capítulos. 4

18 En el capítulo uno, inteligencia de negocios, se aborda el tema de los Sistemas de Información Ejecutivos (SIE). Se describe su significado, sus características y beneficios para una organización. También se describen los conceptos de almacén de datos o bodega de datos (data warehouse) y de mercado de datos (data mart). El SIE utilizará como base de datos un data mart que almacenará la información de la Subsecretaría de Infraestructura Carretera de la Secretaría de Comunicaciones y Transportes (SCT). Cabe mencionar que data mart y data warehouse son dos conceptos que forman parte de una solución basada en tecnología de business intelligence. En el capítulo dos, la información y la toma de decisiones en las áreas de la Subsecretaría de Infraestructura de la SCT, se habla brevemente sobre las actividades que desarrolla la Subsecretaría de Infraestructura. Qué herramientas se utilizan para tomar decisiones en materia de infraestructura carretera y cuál es la razón de querer implementar un SIE en las Direcciones Generales que conforman esa Subsecretaría. El capítulo tres, propuesta de solución, trata sobre el diseño y desarrollo del Sistema de Información Ejecutivo para la SCT. Se mencionan cuáles fueron las necesidades de los usuarios que dieron origen al proyecto. Se realiza un análisis de los requerimientos de información que se detectaron durante el desarrollo de las entrevistas llevadas a cabo con el personal de mando de la Dirección General de Conservación de Carreteras (DGCC), de la Dirección General de Carreteras (DGC) y de la Dirección General de Servicios Técnicos (DGST). Tres Direcciones de la Subsecretaría de Infraestructura encargadas del seguimiento a la construcción y conservación de las carreteras federales del país. En este capítulo, se habla también sobre la descripción funcional del Sistema y se presenta el diseño de la base de datos o data mart de la aplicación y las interfaces desarrolladas para el usuario final. Es importante mencionar que algunas de estas interfaces muestran los indicadores de control que los usuarios necesitan visualizar constantemente y que les sirven para detectar problemas en el ejercicio del presupuesto destinado a la inversión en carreteras. Finalmente, la medición del impacto que tuvo la implementación del Sistema de Información Ejecutivo de Infraestructura, es el tema tratado en el capítulo cuatro. En él se hablará sobre la aplicación de cuestionarios para evaluar la satisfacción de los usuarios del software desarrollado, mediante índices de resumen de los datos obtenidos. Adicionalmente, se encuentra la conclusión de la tesis, la bibliografía utilizada así como un glosario de términos. 5

19 Capitulo 1 Inteligencia de negocios. Para una organización, contar con información oportuna y precisa, puede representar la diferencia entre ganar o perder millones de dólares. En una empresa pública, puede representar cumplir en tiempo y forma con los objetivos y metas trazados con el mayor aprovechamiento de los recursos disponibles. Tener información que le permita a la alta gerencia saber en qué momento incursionar a un nuevo mercado, conocer las expectativas y preferencias de los clientes, determinar oportunidades de negocio, medir minuto a minuto el comportamiento financiero de la organización, entre otros aspectos, todos estos son parámetros estratégicos para tomar decisiones. Es precisamente en la administración de datos como la inteligencia de negocios puede ayudar a cualquier organización, pública o privada. La inteligencia de negocios se basa en la integración de datos históricos y actuales para determinar tendencias futuras y proponer escenarios posibles. Y en este sentido, es lógico que las decisiones deban estar basadas en datos precisos. Como sabemos, los datos por si solos no nos dicen nada. Pero dependiendo del contexto en donde se encuentren y de la correcta integración de los mismos, los datos van a permitir al ejecutivo tomar decisiones más rápidas y eficaces. En el ámbito informático, el procesamiento de datos mediante sistemas basados en computadoras, permite generar grandes volúmenes de información que representan el trabajo acumulado de años de operación. Esta situación ha originado que una enorme cantidad de datos se almacene en centros de información especializados en su alojamiento y administración. Para las organizaciones, esa información representa, además de una gran cantidad de recursos invertidos, el comportamiento financiero de la empresa. Pero el problema de tener esta información acumulada no es su almacenamiento. Actualmente, el problema se ha convertido en cómo utilizar esos datos guardados por años, para aprovecharlos como un recurso estratégico en las organizaciones. En esos datos se encuentran tendencias de mercados, necesidades y motivaciones de los clientes, necesidades de producción, recursos invertidos, situación financiera de la empresa y del país, tendencias de consumo, etc. Pero para descubrir y obtener únicamente la información más importante, es necesario analizar esos datos e interpretarlos. 6

20 En la actualidad, se habla de un nuevo termino para realizar ese análisis y para obtener la información estratégica que las organizaciones necesitan: Información basada en herramientas para la Inteligencia de Negocios. El termino Inteligencia de Negocios (Business Intelligence), es un concepto que está de moda. La inteligencia de negocios se refiere a un análisis de alta tecnología de los datos corporativos, con el fin de tomar mejores decisiones estratégicas. También conocida como minería de datos, la inteligencia de negocios implica buscar y analizar datos provenientes de múltiples fuentes ubicadas en toda la empresa, y algunas veces derivados de fuentes externas, a fin de identificar patrones y relaciones que pueden ser importantes. 11 En otras palabras, la inteligencia de negocios se refiere a un conjunto de tecnologías que van a permitir al dueño, ejecutivo o administrador de una organización, entender el comportamiento de la empresa. Contar con la información suficiente, permite a una organización además de mejorar las prácticas de trabajo existentes, preservar el conocimiento como una memoria organizacional para capacitar a los futuros empleados o para ayudarlos en la toma de decisiones. La memoria organizacional es el aprendizaje almacenado de la historia de una organización que se puede aprovechar para la toma de decisiones y para otros propósitos. 12 En este capítulo, se aborda el tema de los Sistemas de Información Ejecutivos (SIE). Se describe su significado, sus características y beneficios para una organización. También se describen los conceptos de almacén de datos o bodega de datos (data warehouse) y de mercado de datos (data mart). Es importante mencionar que el Sistema de Información Ejecutivo que se va a desarrollar utilizará como base de datos un data mart que almacenará la información relacionada con la construcción y conservación de carreteras del país, actividad que está a cargo de la Subsecretaría de Infraestructura de la Secretaría de Comunicaciones y Transportes (SCT). Cabe mencionar que data mart y data warehouse son dos conceptos que forman parte de una solución basada en tecnología de inteligencia de negocios. 11 Daft, R. (2007). Teoría y diseño organizacional. México: Cengage Learning. p Laudon, K. (2004). Sistemas de información gerencial: Administración de la empresa digital. México: Prentice Hall. 7

21 1.1 Sistemas de Información ejecutivos Sabemos que un dato es la unidad mínima de información que tratada en forma adecuada, puede utilizarse para su procesamiento e integración con otros datos y con base en ello, ayudar a las personas a tomar decisiones. Para una organización, contar con información oportuna y precisa, puede representar la diferencia entre ganar o perder millones de dólares. Tener información que le permita a la alta gerencia saber en qué momento incursionar a un nuevo mercado, conocer las expectativas y preferencias de los clientes, determinar oportunidades de negocio, medir minuto a minuto el comportamiento financiero de la organización, entre otros aspectos, todos estos son parámetros estratégicos para tomar decisiones. No puede haber decisiones sin información. La toma de decisiones que se lleva a cabo dentro de las organizaciones debe ser rápida, oportuna, fundamentada en datos concretos, que permita tomar decisiones eficientes, efectivas y con un bajo costo para la empresa; pues de ello dependerá el éxito o fracaso de la organización. Por otro lado, no solo es importante consolidar datos y tenerlos almacenados en algún medio. La interpretación que se haga de los datos es también muy importante para cada una de las actividades que se realizan dentro de la empresa. Por medio de esa información, los ejecutivos pueden establecer políticas de operación, se pueden enfocar en la solución de problemas específicos para la empresa, pueden determinar el desempeño que la compañía tiene en el mercado, pueden evaluar la rentabilidad de la compañía, etc. Contando con los datos precisos, el ejecutivo se convierte en un tomador de decisiones sobre aspectos como en dónde obtener recursos, en qué invertir, cuáles son las utilidades y beneficios de la empresa, cómo pagar a las fuentes de financiamiento y cómo reinvertir las utilidades, entro otros aspectos. Un Sistema de Información Ejecutivo (SIE) ayuda a los ejecutivos a contar con información oportuna y precisa para tomar decisiones. Un sistema de información para ejecutivos es un sistema que proporciona al ejecutivo información sobre el desempeño global de la compañía. La información se puede recuperar fácilmente y pude presentarse con distintos niveles de detalle. También se usa el término sistema de apoyo para ejecutivos (ESS, executive support system) McLeod Jr., Raymond (2000). Sistemas de información gerencial, 7ª ed. Prentice Hall Hispanoamericana, S. A. México. P

22 Podemos acelerar el arraigo de un SIE en una organización si se demuestra ante los jefes de las áreas funcionales que el nuevo sistema les permitirá conocer mejor cuáles son los factores clave que la dirección tiene en cuenta en su área. La unificación de criterios posibilitará que todas las áreas se centren en los factores que se han considerado críticos para la empresa. 14 Y, qué tan importante es para los ejecutivos de una organización, contar con información al día? La respuesta a esta pregunta es que bajo circunstancias óptimas de la información, los datos diarios permiten formar una mejor impresión del comportamiento organizacional. En muchas organizaciones, el manejo financiero es un ingrediente esencial de la gestión, por lo que los informes diarios son de una gran importancia. El conocimiento es poder y en cualquier organización existe una gran cantidad de información que puede ser transformada en conocimiento. La mayoría de los procesos de negocio generan información empresarial que sin duda constituye un activo muy valioso para las empresas, pero si no se utiliza de manera adecuada, esa información simplemente será una carga cada vez más pesada para su almacenamiento y una fuente de gastos continua para comprar y mantener la infraestructura necesaria para realizar esa actividad. Pero es necesario hacer énfasis en que las soluciones para la integración de la información, deben estar basadas en el análisis de procesos del negocio. Es preciso realizar un análisis exhaustivo sobre la operación de la organización y comprender sus procesos internos que le permiten operar. Una vez definidas las reglas de negocio y descritos los procesos, las organizaciones pueden desarrollar, buscar y elegir productos que automaticen dichos procesos y proporcionen valor para la toma de decisiones. En la actualidad, el almacenamiento de datos y su explotación implica el procesamiento de cualquier tipo de información, desde la contenida en bases de datos estructuradas hasta datos no estructurados, pasando por información en documentos o medios electrónicos, vídeo o audio. Un Sistema de Información Ejecutivo (SIE-EIS: Executive Information Systems por sus siglas en ingles) es un sistema de información informático que se ha concebido con el objetivo de que los directivos de una organización mejoren la calidad de su trabajo. Por este motivo, facilita el acceso a las informaciones de 14 Pastor, J. (2001). Usos de los sistemas de información en la organización. Barcelona: UOC. P

23 mayor relevancia, mejora la comunicación dentro de la organización y permite una mejor comprensión del entorno de la actividad de la organización 15. Estos sistemas proporcionan medios sumamente fáciles de usar para consulta y análisis de la información. Generalmente se diseñan para el usuario que necesita conseguir los datos rápidamente, pero quiere utilizar el menor tiempo posible para comprender el uso de la herramienta. En términos prácticos, un sistema de información ejecutivo tiene como meta obtener la información correcta para las personas adecuadas en el momento conveniente, de tal forma que tomen decisiones que pueden valer millones de dólares. Hoy en día, las organizaciones buscan obtener información en tiempo real, ofrecer sus productos y servicios en línea, lograr procesos más sofisticados, rápidos y eficientes, e incluso tener un envío y recepción de datos a la velocidad de la luz. Lo cierto es que cada vez nos sorprenden más los alcances y sobre todo las mejoras que la tecnología de la información logra en beneficio de las organizaciones. Un Sistemas de Información Ejecutivo es un sistema de información para directivos que permite automatizar la labor de obtener los datos más importantes de una organización, resumirlos y presentarlos de la forma más comprensible posible, provee al ejecutivo acceso fácil a información interna y externa al negocio con el fin de dar seguimiento a los factores críticos de éxito. Este tipo de sistemas se enfocan primordialmente a proporcionar información de la situación actual de la compañía y dejan en un plano secundario la visualización o proyección de esta información en escenarios futuros. Se construyen generalmente mediante la integración de software diseñado para operar conjuntamente con la infraestructura y las aplicaciones de información existentes en la organización. El Sistema de Información Ejecutivo debe ofrecer informes y análisis de la información en tiempo real a toda la organización, debe incluir cuadros, gráficas e informes fáciles de leer, sobre todo información intuitiva que permita a los administradores realizar el seguimiento de indicadores críticos o métricas. Estos sistemas deben proporcionar acceso a la alta gerencia a categorías claves de datos relevantes, como son los datos internos creados por la organización, datos 15 Pastor, J. (2001). Dirección y gestión de los sistemas de información en la organización. Barcelona: UOC. P

24 globales de la institución, datos externos (incluida información acerca de la competencia) y datos mundiales (con el uso de fuentes como Internet) Características de los Sistemas de Información Ejecutivos Un sistema de información ejecutivo que realmente ayude a la organización, debe estar alineado a la operación del negocio de tal forma que ayude a lograr los objetivos fijados. Las características de los SIE son las siguientes 16 : Están enfocados a cubrir las necesidades de la alta gerencia y administración de la organización. Este tipo de sistemas se desarrollan para que los gerentes y dueños de la organización puedan detectar fácilmente desvíos en el logro de los objetivos y de esta forma establecer los elementos de control necesarios para corregir un posible problema en el futuro. Extraen, filtran y permiten analizar información de diferentes fuentes de datos internas y externas a la organización. De esta forma, se pueden hacer cruces de información y detectar oportunidades de negocio y corregir desviaciones en el logro de los objetivos. Permite a los ejecutivos del negocio, contar con un sistema que tiene información consolidada de la operación de toda la organización, sin necesidad de tener intermediarios o solicitar reportes e informes a las áreas operativas. Es un sistema desarrollado con estándares de calidad en la información con el fin de mostrar al ejecutivo de la organización, información precisa para la toma de decisiones. Este tipo de sistemas también debe contener esquemas de seguridad que impidan el filtrado y consulta de información por personas no autorizadas. Estos sistemas realizan consultas en línea a las bases de datos en producción, con el fin de mostrar segundo a segundo si es preciso, el comportamiento de una determinada variable que puede implicar millones de pesos o dólares para una organización. 16 Gill, H. S. (1996). Data warehousing La integración de la información para la mejor toma de decisiones. México, D. F.: Prentice Hall. 11

25 En algunas organizaciones, este tipo de sistemas están acompañados por una infraestructura de hardware de costos muy elevados como: monitores de alta resolución, pantallas sensibles al tacto, impresoras de alta velocidad. Estos sistemas integran capacidad de análisis de datos, tales como hoja electrónica de cálculo (o interacción con paquetes ya existentes como Excel) o lenguajes especializados de consulta que utilicen comandos de SQL. En algunos casos, estos sistemas ejecutivos integran herramientas para la organización personal del ejecutivo, como calendario, agenda y tarjetero electrónico Factores de éxito de un Sistema de Información Ejecutivo Generalmente, este tipo de sistemas están desarrollados para ser empleados por los altos ejecutivos de una organización. Sin embargo, el éxito de este tipo de proyectos depende de diversos factores que, de acuerdo a mi experiencia, si falta alguno de ellos el sistema no tendrá la aprobación esperada: Apoyo y compromiso de la alta dirección. Para que los usuarios de los sistemas en producción den atención e importancia a un Sistema de Información Ejecutivo, es necesario que la alta dirección de la organización se involucre. Esto dará al Sistema una imagen de importancia para la alta gerencia, con lo cual todos los empleados proporcionarán la información necesaria y darán la suficiente importancia al desarrollo del proyecto. Apoyo operativo. El líder del proyecto debe de tener conocimientos tanto técnicos como operacionales en función del negocio, además de poseer las habilidades de comunicación necesarias para interactuar con los altos ejecutivos. Tecnología apropiada. Es de gran importancia la selección tanto de hardware como de software en la aceptación del sistema. Alinear claramente los objetivos del proyecto del SIE con los objetivos de la empresa. Debe de existir un claro enlace entre los objetivos de la empresa y los beneficios del sistema. 12

26 Acceso y administración de los datos. Un sistema de este tipo debe estar disponible los 365 días del año y 24 horas al día. Los datos deben ser accesibles desde medios internos como externos a la organización. Uso. Un indicador importante es su frecuencia de uso. Si un sistema no es usado, o simplemente los usuarios potenciales no lo emplean, esto se reflejará en el éxito del sistema. Satisfacción. Si el sistema no proporciona la información necesaria que los usuarios esperan, entonces dejarán de utilizarlo. Impacto positivo. Un sistema es exitoso si tiene un impacto benéfico en los ejecutivos de la organización. Cuando un ejecutivo toma decisiones correctas con base en la información del SIE, entonces el resultado de esas decisiones beneficiarán a la organización. Difusión. Otro punto importante para el éxito del proyecto, es el número de personas que utilizan el sistema. Y este sistema será utilizado por más usuarios en cuanto los primeros reconozcan el valor funcional que tenga para la toma de decisiones. Definir cuidadosamente los requerimientos de información. Algo muy importante en este proceso es la definición de los requerimientos de los usuarios. El éxito aplicará únicamente si estas necesidades son bien entendidas, lo cual no es una tarea fácil Beneficios de un Sistema de Información Ejecutivo Los SIE aportan diversos beneficios a la operación de una organización y al cumplimento de las metas y objetivos planeados. Se puede mencionar los siguientes: Información a tiempo. Los ejecutivos de la organización cuentan con información importante, precisa y relevante sobre la operación de la empresa. Con esta información, el ejecutivo y administrador del negocio, pueden tomar decisiones más acertadas y precisas. Sensibilidad al medio. Se obtiene información de mayor calidad, independientemente de cuál sea el origen o el medio, lo que se pretende es obtener información competitiva. 13

27 Efectividad de ejecutivos. Mejora la comunicación entre los ejecutivos de la organización, aumentando el desempeño y ahorrando tiempo. Cumplimiento de objetivos estratégicos. Con información precisa, se pueden hacer mejores planes para una mejor toma de decisiones. Y cuando se presente un problema, también se pueden obtener alternativas de solución óptimas para el cumplimiento de los objetivos. Economía en el uso de recursos. Se ahorran costos en papeleo y se obtiene una mejor respuesta al cambio en las necesidades de los clientes Desarrollo de un Sistema de Información Ejecutivo Es importante tener en cuenta que el proceso de desarrollo para un sistema transaccional, no necesariamente va a funcionar en un 100% para un SIE. Los pasos a considerar para desarrollar un SIE, son 17 : 1. El establecimiento del equipo de desarrollo: personas con un perfil adecuado, que dispongan de tiempo y que crean en la idea. 2. Determinación de las necesidades de los directivos: existen diferentes estrategias para la determinación de estas necesidades. Los diferentes métodos de planificación de sistemas aportan propuestas propias que se pueden basar en los problemas y las decisiones que hay que afrontar (Business System Planning), las finalidades y los medios existentes (Ends/Means Analysis) o los factores críticos para el éxito de la organización (Critical Success Factors). Para la determinación de estas necesidades tenemos que considerar los siguientes aspectos: a. Análisis de los objetivos de la organización a partir de entrevistas con directivos clave. b. Identificación de los factores críticos para alcanzar los objetivos. c. Identificación de las actividades básicas desarrolladas en la organización. d. Determinación de los indicadores clave de rendimiento para cada actividad básica. 3. Determinación del contenido inicial del prototipo. 17 Pastor, J. (2001). Usos de los sistemas de información en la organización. Barcelona: UOC. 14

28 4. Estudio de viabilidad. Es necesario tener en cuenta los tres aspectos que se presentan a continuación: a. Información interna: análisis del sistema de información actual y determinación tanto de la información que necesita el SIE y que ya existe como de las nuevas fuentes de información que son precisas. b. Información externa: determinación de las variables del entorno que hay que considerar y la manera de obtenerlas. c. Evaluación de las posibilidades de que las necesidades de los directivos queden cubiertas con el nuevo sistema. d. Establecimiento de un plan de actuación. 5. Elaboración y prueba del prototipo basándose en las necesidades determinadas anteriormente. 6. Adaptación del sistema de información existente para obtener la información interna de la que antes no se disponía. 7. Desarrollo del sistema real a partir del prototipo. Puesta en marcha por fases. 8. Establecimiento de los mecanismos de actualización y vistas diferenciadas según los usuarios. 9. Difusión del uso del sistema: ampliación a otros directivos del mismo nivel organizativo (ampliación horizontal) y de niveles inferiores (ampliación vertical). 10. Adaptación periódica del sistema a los cambios de la organización y al entorno: previsión de recursos para un posterior mantenimiento. Ahora bien, la persona que va a utilizar un SIE, debe tener también ciertas capacidades como: Capacidad de visualizar y declarar problemáticas Capacidad de generar soluciones o abrir nuevas posibilidades Capacidad de decision Un Sistema de Información Ejecutivo fortalece también el proceso de planeación de la organización de la siguiente manera: 15

29 Automatizando el proceso de planeación de la compañía Creando aplicaciones de planeación estratégica y análisis competitivo, las cuales se perfeccionan a través de comunicaciones adecuadas y acceso a las bases de datos. Logrando que los ejecutivos utilicen el sistema para planeación técnica y, a largo plazo, con aplicaciones que antes fueron concebidas para el control administrativo. Habilidad de realizar análisis específicos utilizando información que está en las bases de datos. Es importante mencionar que los SIE deben diseñarse de tal forma que provean a la alta administración de la información que emerja de las bases de datos Como mejoran los SIE el proceso de toma de decisiones En la actualidad, las compañías están haciendo frente a un nuevo fenómeno dentro del almacenamiento empresarial; el explosivo crecimiento de datos que se está produciendo dentro del mercado actual. Un nuevo reto que no se limita a la gestión de una, cada vez mayor, base de datos. Sino que ahora también es preciso gestionar los datos de manera que ayuden a los ejecutivos de la organización a tomar decisiones de manera rápida con base en la información almacenada. De esta forma, el uso de un SIE tiene entre otras ventajas, las siguientes 18 : Mejora del desempeño. Las empresas participantes de un SIE disponen de mayor cantidad de financiamiento, lo que facilita que puedan diseñar tecnologías que apoyen sistemas de información más personalizados a las necesidades del grupo. Aumento de la flexibilidad. El uso de un mismo sistema de información para compartir datos, permite a las organizaciones lograr una ventaja competitiva, sin alterar el funcionamiento de sus departamentos o sucursales ni su interacción con otras organizaciones. Ampliación de servicios complementarios. Compartir un sistema común puede originar propuestas de servicios adicionales como por ejemplo, servicios de facturación electrónica, promociones, ofertas y descuentos. 18 Pablos Heredero, C. d. (2004). Ilustraciones de la aplicación de las tecnologías de información en la empresa española. Barcelona: ESIC. P

30 Colaboraciones en la elaboración de nuevos productos y servicios. El involucramiento de todas las empresas participantes en diseños de productos y servicios a través de un sistema común, puede propiciar una mayor aproximación a las demandas de los clientes. Reducción y/o eliminación de los costos administrativos. Poseer mayor información de manera electrónica aumenta las posibilidades de reducir el movimiento de papel típico en estas operaciones. Reducción de intermediarios. La conexión a través de una red de comunicaciones entre los productores de la información (personal operativo) con el consumidor final (estratega), podría eliminar la necesidad de representantes e intermediarios, ó en su caso provocar la redefinición de sus funciones. 1.2 Concepto de data warehouse Para algunas organizaciones, es una arquitectura. Para otras, es un depósito semánticamente consistente en datos (separados y que no interfieren con los otros sistemas en producción existentes) que llenan por completo los diferentes requerimientos de acceso y reporte de datos. También se puede entender como un proceso continuo que mezcla los datos de varias fuentes heterogéneas, incluyendo datos históricos y adquiridos para soportar la constante necesidad de consultas estructuradas, reportes analíticos y soporte de decisiones. Pero sin lugar a dudas, es una tecnología esencial en el conjunto de soluciones para el soporte de decisiones en una empresa. Un data warehouse es el lugar donde se recoge toda aquella información que puede ser de interés analizar a la hora de tomar decisiones por los diferentes departamentos de una compañía. Para generar esta información es necesario acceder a datos de distintos sistemas informáticos de la organización y construir los procesos que apliquen la lógica del negocio y trasladen los resultados hasta el data warehouse. 19 Con mucha frecuencia la gente de tecnologías de la información de alguna empresa, cree haber construido uno. Pero en muchos casos lo que se ha 19 Barranco, Jesús (2001). Metodología de análisis estructurado de sistemas. Madrid, España. Universidad Pontificia. P

31 construido es un recurso de acceso de último usuario para navegar, reportar y unirse a un Sistema de Soporte de Decisiones (SSD). En otros casos, se ha transferido información de las bases de datos relacionales a una base de datos multidimensional y generalmente se desarrollan herramientas de análisis para conectarse a las bases de datos multidimensionales. De hecho, trabajar con bases de datos multidimensionales es solo un paso que permitirá la implementación de la solución de data warehouse. Sin embargo, una implementación de este tipo de tecnología, debe complementarse con los siguientes aspectos: Integrar datos de diversas fuentes. Cuidar la calidad de los datos que van a ser consolidados hacia el data warehouse. Crear los mecanismos de sincronización de las fuentes de datos con el data warehouse para asegurar una actualización constante del mismo, conforme se crean nuevos datos dentro de las fuentes. Cuidar los aspectos de desempeño relacionados con la infraestructura tecnológica como servidores y plataformas de sistemas manejadores de bases de datos (RDBMS) y OLAP. Dar mantenimiento a la estructura de las bases de datos multidimensionales y relacionales para implementar nuevos requerimientos de información. La mayoría de las bases de datos e incluso de los data warehouse, no toman en consideración el aumento de la necesidad de extraer información de los datos a mayor velocidad o la de usar datos no estructurados almacenados fuera de éstos sistemas. En la actualidad, el almacenamiento e interpretación de datos no estructurados, se ha convertido en una necesidad para las organizaciones, ya que mucha de la información que reciben proviene de correos electrónicos, páginas de Internet, documentos de procesadores de texto u hojas de cálculo. Los datos usados para el análisis operacional se utilizan con mucha frecuencia antes de ser almacenados. Esta tendencia continuará con el incremento de la demanda, por parte del usuario, de sistemas que le permitan analizar y obtener la información por sí mismo. El propósito de un data warehouse es ayudar a la administración y alta gerencia de una organización a comprender el pasado y planear para el futuro. Pero es importante mencionar que el éxito de una compañía no va a estar garantizado por el solo hecho de contar con esta tecnología. Para obtener valor de 18

32 una herramienta de este tipo se requiere una combinación de técnicas, habilidades, intuición y experiencia por parte de los usuarios Características de un data warehouse Las principales características de un data warehouse son las siguientes: Integra información. Es una herramienta que va a permitir consolidar información de muy diversas fuentes con la ventaja de guardar datos históricos que ya no son útiles en los sistemas operacionales pero que sin embargo sirven para análisis de escenarios, determinación de pronósticos, comparación de comportamientos organizacionales, etc. Está dirigido al usuario. Generalmente, estas aplicaciones están dirigidas al personal que conforma la alta gerencia o dueños del negocio y a todas aquellas personas encargadas de tomar decisiones diariamente. La finalidad de estas herramientas es apoyar en la toma de decisiones para que sea un proceso más rápido y con mayor precisión. Evoluciona con el tiempo. Son herramientas que van a tener que cambiar y ser adaptadas a requerimientos cada vez más precisos por parte de sus usuarios finales, ya que van a demandar información más exacta y estratégica, de acuerdo al contexto de la organización y a las condiciones de mercado. Por lo que el personal de TI tendrá que realizar ajustes, buscar nuevas fuentes de información, cambiar las reglas de extracción, carga y cálculo de la información, etc. Está orientado a la toma de decisiones. Un data warehouse se construye para consolidar información de diversas fuentes en una sola y con ello apoyar en la mejor toma de decisiones y así obtener una ventaja competitiva. Su uso está enfocado a la alta gerencia. Un data warehouse no esta orientado a los procesos operativos de la organización. Sino más bien a los ejecutivos o dueños del negocio que son quienes toman las decisiones y guían el curso de la empresa de acuerdo a la información almacenada en el data warehouse. 19

33 1.2.2 Implementación de un data warehouse en la organización La implementación de un data warehouse en una organización, implica conocer forzosamente sus procesos de negocio. La idea central para la implementación de este tipo de herramientas es que se almacenen y manejen grandes cantidades de información para su análisis, de tal forma que su resultado satisfaga las necesidades empresariales en el menor tiempo y con la mayor precisión posible. Sin embargo, existen en el mercado una gran cantidad de proveedores y metodologías que se pueden utilizar para su implementación. Elegir una adecuada metodología de desarrollo implica conocer detalladamente los procesos de negocio con el fin de poder determinar las métricas e indicadores que realmente se necesitan por la alta gerencia o por los usuarios finales de la aplicación. También será necesario identificar todas aquellas posibles fuentes de información que nutrirán de los datos necesarios al data warehouse. Como en todo proyecto, el análisis del problema es el primer paso para encontrar la solución. La complejidad para la implementación de un data warehouse se centra en lo complejo que pueda ser el negocio y de la necesidad que se quiera modelar. Las características de cada negocio son diferentes. De ahí que también la profundidad de sus procesos y la organización al interior de la empresa, sean factores que ayudarán a dimensionar la arquitectura necesaria y la configuración para satisfacer los requisitos del desarrollo. Una buena estrategia para el desarrollo de un data warehouse en grandes empresas, es construirlo poco a poco. En algunas organizaciones puede consistir en un proceso a largo plazo que involucre las siguientes actividades: 1. Determinar las fuentes de información existentes como sistemas operacionales, intranets, Internet, hojas de cálculo, etc. Es recomendable que se busquen fuentes estructuradas de información aunque, como se analizará más adelante, es posible también consolidar fuentes no estructuradas como lo son documentos de Word y archivos de Excel. 2. Construir, si no existen, los sistemas operacionales que procesaran la información cotidiana de la empresa, como son: sistemas para la gestión de pagos, sistemas para la administración de ventas o sistemas para la administración del presupuesto, etc. 3. A partir de los sistemas operacionales, desarrollar data marts para cada uno de ellos. Estos mercados de datos tendrán como objetivo consolidar la información más importante para la toma de decisiones dentro de una sola área. Apoyarán en las actividades de reporteo, análisis de información, análisis de escenarios, etc. Más adelante se estudiará con mayor detalle el 20

34 concepto de data mart, ya que el Sistema de Información Ejecutivo que se va a desarrollar, utilizará uno de ellos como repositorio de información. 4. Consolidar la información de cada uno de los data marts construidos, hacia el data warehouse empresarial. A su vez, estos mercados de datos que son independientes unos de otros, servirán para consolidar la información hacia un data warehouse que contendrá las métricas necesarias para su análisis. Cada vez que se construya un data mart, se podrá enviar su información hacia un data warehouse el cual contendrá toda la información de la organización, pero deberá estar consolidada de tal forma que apoye en el análisis y proceso de toma de decisiones de la alta gerencia. 5. Construir las herramientas de software necesarias para explotar la información del data warehouse. Pueden ser portales o páginas web, algunas herramientas de reporteo o construir un Sistema de Información Ejecutivo que permita la explotación de esta información. Estos cinco pasos son, a grandes rasgos, las actividades que se pueden llevar a cabo para la construcción de un data warehouse. En un esquema de desarrollo, se pueden visualizar 3 niveles o capas de abstracción (ver figura 1.1) y cada una de ellas conlleva una serie de actividades para su construcción. En la figura 1.1, se hace mayor énfasis en el uso de sistemas operacionales para la construcción de los data marts. Esto se debe a que generalmente se puede tener un mayor control y una mayor certidumbre de la información almacenada en el data warehouse, cuando esta proviene de sistemas de información que contienen la regla del negocio específica para las áreas que los usen, así como un conjunto de restricciones y de elementos de seguridad que van a garantizar que la información procesada en la base de datos transaccional, tenga la menor cantidad de errores posible. A diferencia de hojas de calculo y de otras fuentes de información en las que es menos probable que se tengan elementos de seguridad que garanticen la integridad de la información que se almacena en los data marts y en el data warehouse. Sin embargo, es posible ingresar información de estas fuentes alternas de datos (hojas de cálculo, Internet, etc.) e incluir en el data mart y en el data warehouse, las reglas de negocio necesarias, que eviten integrar información errónea. Esta estrategia de construir un data warehouse a partir del desarrollo de data marts, tiene algunas ventajas. En primer lugar, se obtiene un mejor desempeño en la consolidación de la información en el data warehouse a partir de información que ya se encuentra depurada en un data mart. Esto disminuirá los tiempos de consulta y explotación de la información. 21

35 Y en segundo lugar, se tiene la ventaja de desarrollar un sistema de data warehouse modular que permitirá detectar rápidamente el origen de alguna información incorrecta, ya que no es lo mismo consolidar y buscar información de todas las fuentes de datos organizacionales directamente en un data warehouse, que buscar el origen del dato erróneo en un data mart, el cual es muy particular y específico de una área. Figura 1.1 Integración de aplicaciones para la construcción de un data warehouse (diseño propio) Por otro lado, independientemente de la metodología de desarrollo que se utilice, es indispensable tener una disciplina y organización en el desarrollo e implantación de proyectos de data warehousing. Esto permitirá, además de contar con la documentación técnica necesaria al final del proyecto, reducir los costos de desarrollo, mejorar el trabajo de análisis de la aplicación, integrar de forma más rápida nuevo personal y mejorar y establecer una comunicación común entre todos los participantes. En la implementación también se debe tener en cuenta que en muchos casos se debe recoger datos de fuentes que estén geográficamente dispersas para después integrarlos y finalmente entregarlos a usuarios que también estén separados físicamente en delegaciones, cedes o corporativos. Por lo tanto, la infraestructura de comunicaciones se vuelve crítica en este tipo de soluciones. 22

36 1.2.3 Personal que participa en la implementación de un data warehouse Existe personal interno y externo a la organización, que invariablemente deberá participar en el diseño y desarrollo de un data warehouse ya que sin su apoyo, sería muy difícil identificar claramente los requerimientos de información. Por parte de la organización, el personal que participe en la implementación de un data warehouse debe ser aquel que esté directamente involucrado con la operación diaria y manejo de la información. Esto permitirá modelar el proceso de negocio e identificar el flujo de la información, facilitando la determinación de los indicadores necesarios para la toma de decisiones. También deben estar involucrados los usuarios de tipo ejecutivo o de la alta gerencia quienes serán finalmente los usuarios de la herramienta y serán quienes utilizarán su información para tomar decisiones. Así que solamente ellos podrán determinar cuáles serán las métricas del negocio de alto nivel que necesitarán visualizar para su control. El otro tipo de personal involucrado es el técnico responsable de implementar la solución de data warehouse. Generalmente es personal contratado por consultoría o por outsourcing. Pero será necesario que en el desarrollo de todas las actividades de construcción, esté involucrado también el personal técnico interno de la organización, con el fin de garantizar que el conocimiento del desarrollo y mantenimiento de la nueva herramienta se quede dentro de la empresa y evitar así, la dependencia hacia el consultor. En resumen, el personal involucrado deberá ser el siguiente 20 : Los ejecutivos y los administradores (inversionistas) invierten en la tecnología del data warehouse y pagan por el desarrollo de la solución. Son responsables de aprobar el presupuesto y valorar si la retribución del data warehouse conviene a su inversión. Les interesa la permanencia de su inversión y su retribución continua. Los arquitectos de sistemas son responsables de establecer las bases del data warehouse. Son los responsables de interpretar los requerimientos del inversionista y diseñar la arquitectura del data warehouse que los cumpla. 20 Gill, H. S. (1996). Data warehousing La integración de la información para la mejor toma de decisiones. México, D. F.: Prentice Hall. P

37 Les interesa la duración, la modulación, la facilidad de implementación y el grado de compatibilidad con sus tecnologías y sistemas existentes. Los constructores son los profesionales de la tecnología de información que realmente construirán el data warehouse. Son responsables del tiempo, la calidad, el desempeño y la satisfacción de las personas que realmente emplearán la herramienta cada día. Los usuarios son los profesionales de la empresa y su personal de apoyo que accederán y utilizarán el data warehouse como una herramienta de soporte de decisiones en su trabajo cotidiano. Son personas cuyo trabajo se basa en la información, y los datos que adquieren les ayudará a formular recomendaciones empresariales. Son especialistas en analizar la información de diversas maneras para tratar de destacar hechos acerca de clientes, mercado y productos, y utilizarla como una ventaja competitiva. Les interesa entender lo que está pasando en el negocio y después analizar los Qué tal si? e y ahora que? Para sus empresas. Es importante mencionar que no todas las empresas están preparadas para la implantación de sistemas de data warehouse. Hay varios factores que influyen. Lo fundamental consiste en los siguientes puntos: Tener información. Disponer de sistemas internos que generen información. Los sistemas transaccionales como los ERP (Enterprise Resource Planning) o los sistemas hechos a la medida de una empresa contribuyen a esto. Que la empresa tenga cultura de análisis. Si el equipo directivo no tiene una cultura de análisis que le permita sacar partido a la información, no tiene sentido invertir en este tipo de tecnología. Se podría invertir y lo más que se llegaría a tener son una serie de informes y herramientas de reporteo. Pero no se tendría la capacidad técnica ni el interés por llevar a cabo un análisis exhaustivo de los datos, el cual es el objetivo central de una solución de data warehouse. Es necesario que la organización cuente con procesos y procedimientos organizados, que el trabajo se lleve a cabo de forma ordenada y en general que la empresa siga un cierto aspecto metodológico en el desarrollo de sus actividades. Para poder implantar soluciones de este tipo, es preciso que la empresa tenga un gabinete de dirección, unos presupuestos asignados a la 24

38 operación diaria de la empresa y una dinámica interna que le permita el aprovechamiento de esta plataforma. Es importante mencionar que los ejecutivos de negocio o alta gerencia, van a demandar cada vez más informes para lograr una visión más profunda sobre alguna métrica o elemento de control en particular. Esto implica que el desarrollo de una solución de data warehouse no termina en el momento en que se finaliza la implementación del mismo. No hay que olvidar que las organizaciones evolucionan y con ello las herramientas de inteligencia de negocios o de data warehousing deben adaptarse, con el fin de que proporcionen información estratégica que mantengan o mejoren la competitividad. Los datos que hoy son importantes para una organización en un determinado contexto, puede ser que ya no lo sean el día de mañana. En la actualidad, las empresas implementan tecnologías de data warehousing, todas basadas en incrementar las ganancias y vencer a la competencia. La información adquirida se encuentra, como regla, disponible para todos. Pero los datos de la propia empresa en su data warehouse son un activo importante. Estos datos son una historia detallada de los negocios de la empresa y su relación con sus clientes. Las empresas que aprenden a aprovechar sus datos están verdaderamente en posición de construir planes, ejecutarlos y afinarlos para obtener una ventaja competitiva Arquitectura para la construcción de un data warehouse Esta arquitectura permite mostrar los distintos tipos de información necesaria para construir un data warehouse. La arquitectura se describe primero desde un punto simplificado a alto nivel, del modo siguiente: Un conjunto de datos extraídos de bases de datos operacionales. Un software que prepara los datos para que los accedan los usuarios. Un conjunto de aplicaciones y herramientas que ejecutan un conjunto de consultas y análisis complejos. En la figura 1.2, se puede analizar el esquema de construcción y la infraestructura necesaria para implementar una solución de este tipo. Es importante mencionar que en cada bloque se desarrollan actividades que permitirán cubrir las necesidades de información de la organización. 25

39 Figura 1.2 Arquitectura de referencia del data warehouse (Gill, H. S.) La arquitectura de referencia mostrada en la figura 1.2, contiene los siguientes elementos: Modelo de datos. Provee una estructura para identificar, nombrar, describir y relacionar los elementos de información de la base de datos. Es necesario desarrollar este modelo de datos porque con base en él, es como se va a estructurar la información almacenada en las soluciones de data warehousing a desarrollar. Es un mapa para la integración de datos que va a permitir integrar fuentes de datos de data marts con el data warehouse. Existen dos modelos que se pueden utilizar para desarrollar una data warehouse o data mart. Modelo de estrella y modelos de copo de nieve (snowflake). Más adelante en este capítulo, se analizarán brevemente estos dos modelos. Fuente de datos. En este bloque se analizan todas las posibles fuentes de información que alimentaran al data warehouse. Puede tratarse de datos de sistemas en producción, datos de herencia, sistemas internos de oficina, sistemas externos. Nuevamente se hace hincapié en que la información proveniente de fuentes no normalizadas, debe estar lo mas estructurada posible, con el fin de facilitar la integración de la información periódica de estas fuentes, hacia el data warehouse. Desarrollo e implementación del data warehouse. Este bloque se refiere al desarrollo de los elementos que permitirán el funcionamiento del data warehouse. Algunas de las actividades que se llevan a cabo en esta fase son la normalización o estandarización de la estructura de datos, el filtrado de datos, la definición y creación de metadatos, la condensación o 26

40 consolidación de los datos, la aplicación de cálculos, la transformación de los datos y su reubicación. Desarrollo e implementación de data marts o mercados de datos. En este bloque se crean los mercados de datos a partir del contenido de las fuentes de información y visualizando la condensación de la información contenida en el data mart hacia el data warehouse. Las actividades que se desarrollan para la construcción de un data mart, son similares a las del data warehouse. La principal diferencia entre estos dos componentes de data warehousing, es el enfoque del usuario final. Los data marts están enfocados al análisis y consolidación de información para un área en particular. Son herramientas que satisfacen las necesidades de información de un grupo de usuarios con funciones muy específicas como podrían ser el área de ventas, el área de adquisiciones o el área de recursos humanos. Cada área dentro de la organización puede tener su propio data mart del cual se extraerá información para su consolidación hacia el data warehouse empresarial. Tecnologías de análisis y explotación de la información. En este bloque se determinan cuales serán las herramientas que el usuario final utilizará para visualizar la información. En algunas ocasiones puede tratarse del diseño de un portal web, de la construcción de un Sistema de Información Ejecutivo (SIE) o de algo muy sencillo como una hoja de cálculo. Estas herramientas estarán conectadas el data warehouse o a algún data mart y permitirá al usuario extraer información y realizar operaciones de drill down (búsqueda en profundidad) o drill up (búsqueda en ascenso). Es importante mencionar que deben considerarse los elementos de seguridad necesarios para evitar accesos no autorizados a la información y en general, la corrupción o pérdida de los datos almacenados. Por otro lado, dentro de la arquitectura también se tienen una serie de capas o niveles, las cuales son 21 : Capa de administración de metadatos. La arquitectura del data warehouse se basa en el concepto de definiciones de datos o metadatos. Los metadatos se utilizan en toda la construcción tanto del data warehouse como de data marts. El manejo de metadatos permite conocer información 21 Ibid., p

41 como la fecha de integración de un dato, la fuente u origen o el dueño responsable de los datos consolidados. Precisamente la actividad de consolidación requerirá de la creación de nuevas columnas para contener la información resumida y deberá estar basada en la utilización de reglas de carga que eviten la integración de datos incorrectos o no estructurados. La capa de administración de metadatos es responsable de la administración de los metadatos que usa el data warehouse, tales como la descripción completa de los datos almacenados. Capa de transporte. La tarea de transportar los datos está contenida en este bloque. Actividades como determinar la velocidad necesaria de transmisión de los datos que permita su consulta en el momento en el que se requiere, donde se requiere y a la hora que se requiera o el análisis del impacto que tendrá la transferencia de información a través de la red al momento de consolidarla desde las fuentes de datos hacia el data warehouse o la tarea de transportar los datos entre los distintos bloques de la arquitectura, se desarrollan en esta capa de transporte. Esta capa utiliza tecnología de actualización y duplicación, red para transferencia y entrega de datos y también aporta elementos de seguridad y de autentificación para la transmisión de información. Infraestructura de operación. En esta capa se analizan los elementos necesarios para el funcionamiento del data warehouse como la determinación del motor de la base de datos, lenguajes de programación y arquitectura de construcción, administración de los componentes de seguridad (tanto de software como de hardware), administración de licencias y elementos de monitoreo del desempeño de la infraestructura Diferencia entre un data warehouse y una base de datos relacional Para entender la diferencia de un data warehouse con respecto a una base de datos relacional, deben conocerse muy bien las diferencias entre los sistemas operacionales y los sistemas enfocados a informar (como es el caso de un almacén de datos o data warehouse). Un sistema operacional representa a los sistemas de gestión de la empresa, generalmente basados en transacciones de negocio, que recogen la información puntual y detallada de la gestión de los servicios de la empresa, y que sirven para actualizar las bases de datos contenedoras de la información del negocio. Cada aplicación de gestión utiliza su base de datos, dedicada a las funciones de negocio 28

42 que abarca. Como sabemos, a este tipo de aplicaciones se les denomina On-Line Transaction Processing (OLTP). 22 Un sistema operacional utiliza bases de datos relacionales como repositorio de información. Una base de datos relacional puede llegar a tener cientos de tablas para soportar la operación óptima de un sistema operacional. Un data warehouse puede llegar a tener algunas decenas de dimensiones o tablas (el término dimensión se utiliza para nombrar a cada una de las vistas que puede tener un cubo de información y se analizará mas adelante en este mismo capítulo) que son utilizadas para consolidar la información de grandes volúmenes de datos. Un sistema de data warehouse (o sistema informativo) es utilizado para realizar consultas, a diferencia de una base de datos transaccional que está enfocada a almacenar y procesar información de ese tipo. Por otra parte, la fase de análisis y el entendimiento de los procesos de negocio son indispensables en ambos modelos. Lo importante en este punto es modelar claramente lo que se quiere obtener de las aplicaciones. Puede utilizarse UML para diseñar los procesos del negocio y entender como funciona. Sin embargo, hay que tener en cuenta siempre, como se mencionó en el párrafo anterior, que el fin de ambos sistemas es distinto y que el proceso de construcción de estas aplicaciones es diferente también. El data warehouse hace lo siguiente 23 : Administra grandes cantidades de información. La mayoría de los data warehouse contienen información histórica que se retira con frecuencia de los sistemas operativos porque ya no es necesaria para las aplicaciones operacionales y de producción. Por el volumen de información que un data warehouse debe manejar, también debe ofrecer opciones para la adición y la consolidación que clasifican esta inmensa cantidad de datos. Un data warehouse debe administrar información histórica de la organización además de la información actual. Incluso la misma solución de data warehouse puede necesitar de una gran cantidad de espacio para almacenar su propia información. Una sola aplicación puede crecer en megabytes de información al día. 22 Barranco, Jesús (2001). Metodología de análisis estructurado de sistemas. Madrid, España. Universidad Pontificia. P Gill, H. S. (1996). Data warehousing La integración de la información para la mejor toma de decisiones. México, D. F.: Prentice Hall. P

43 Almacena información en diversos medios. Debido a las grandes cantidades de información que deben manejarse, un data warehouse debe permitir guardar información en diferentes medios. Incluso debe pensarse en que la información puede estar dispersa geográficamente. Actualmente, las organizaciones contratan servicios de centros de datos - que pueden encontrarse a kilómetros de distancia del origen de los datos- y que se van a encargar de almacenar y administrar la infraestructura necesaria para guardar grandes volúmenes de información. Y para llevar a cabo esta tarea, utilizan discos duros, discos compactos, cintas magnéticas, etc. Una solución de data warehouse debe contemplar dos cosas. La minería y extracción de datos en todos esos medios y la consolidación de la información y su almacenamiento en los mismos. Puede administrar versiones diferentes de un esquema de base de datos. Debido a que un data warehouse puede almacenar información histórica, las aplicaciones de minería y extracción de datos deben ajustarse constantemente para poder conectarse a bases de datos que cambien su estructura periódicamente para adaptarse a las nuevas necesidades del negocio. Esto puede ser una ventaja y una desventaja. Si consideramos que un data warehouse opera en parte con la información que se procesa a diario en los sistemas operacionales y que estos últimos evolucionan a través del tiempo, entonces el data warehouse y los data marts construidos también deben evolucionar de acuerdo a nuevas condiciones de la organización. No hay que olvidar que la construcción de un data warehouse es un proceso evolutivo que busca constantemente proporcionar información estratégica dentro de un contexto actual de la organización. Por otro lado, manejar distintas versiones de bases de datos operacionales, obliga a la organización a contar con el personal técnico necesario (interno o externo) para realizar los ajustes correspondientes a las aplicaciones de data warehousing. En la actualidad, las consultarías que se dedican a proporcionar este tipo de servicios pueden cobrar millones de dólares por sus servicios, lo cual hace prácticamente imposible para la pequeña y mediana empresa pensar en este tipo de implementaciones. Sin embargo, existen diferentes metodologías para implementar este tipo de herramientas y que no llegan a ser tan caras. Lo importante es comprender el negocio y las necesidades de información. 30

44 Consolida y agrega información. Con frecuencia, es muy alto el nivel de detalle de la información guardada por bases de datos operacionales. Un data warehouse consolida y agrega la información para presentarla en forma comprensible a las personas. La consolidación y adición es esencial para entender la imagen global y poder responder a una pregunta del negocio en particular. Una vez consolidada la información pueden ejecutarse scripts de cálculo que van a permitir obtener estadísticas u otro tipo de resultados. Integra y relaciona información de diversas fuentes de información. Debido a que las organizaciones han administrado sus operaciones desde hace mucho tiempo utilizando numerosas aplicaciones de software y múltiples plataformas de bases de datos, es necesario que un data warehouse integre toda esa información y la consolide de tal forma que solamente exista una sola fuente de datos para la toma de decisiones. Esta tarea es muy complicada porque en la actualidad existen numerosas plataformas tecnológicas de bases de datos relacionales, así como una gran diversidad en la semántica y estructuración de la información. Por lo que implica un enorme trabajo de análisis, construcción y mantenimiento de la solución. Está dirigido a la alta gerencia para resolver problemas de información. Organiza y orienta los datos desde la perspectiva del usuario final. Los sistemas de procesamiento de transacciones organizan sus datos desde la perspectiva de la aplicación, de modo que el acceso de la aplicación a los datos tenga la mayor eficiencia posible. Con frecuencia, la información que está organizada para que una aplicación del negocio la recupere y actualice con facilidad, no está organizada necesariamente de modo que un analista con herramientas gráficas inteligentes de consulta pueda formular las preguntas empresariales correctas El data warehouse como un sistema de misión crítica Conforme las organizaciones comienzan a utilizar un data warehouse para realizar las actividades diarias y cuando los usuarios se dan cuenta de la importancia que puede llegar a tener una herramienta de este tipo, el sistema de data warehouse se convierte en un sistema de misión crítica. Generalmente este tipo de aplicaciones comienzan a utilizarse con ciertas reservas y dudas sobre su funcionamiento. Incluso en algunas organizaciones se utilizan en paralelo los mismos reportes con los que operaban antes de que el data warehouse arrancara en producción. 31

45 Sin embargo, cuando los usuarios se dan cuenta de que pueden tener en unos cuantos minutos la misma información que anteriormente recibían después de un largo proceso de integración que hacían los responsables de diferentes áreas, entonces es cuando ya no podrán dejar de utilizar el almacén de datos para tomar decisiones. A partir de ese momento el data warehouse se convertirá en un sistema de misión crítica, ya que los usuarios tendrán la confianza de operarlo e incluso la falla del sistema podría ocasionar un mal funcionamiento del negocio. La aceptación de la nueva herramienta conlleva un proceso de evolución y de madurez tanto del personal como de la misma tecnología. A pesar de las bondades tecnológicas que en la actualidad existen para analizar la información de un data warehouse, no deja de ser algo nuevo para los usuarios que finalmente esperarían contar con una herramienta que tomara las decisiones casi por ellos con solo hacer clic sobre un botón. Pero no es así de sencillo. En la figura , se puede visualizar el proceso de madurez tecnológico con respecto a la importancia que va cobrando el uso de un sistema dentro de la organización. El personal que utilice el data warehouse debe estar realmente consciente de las necesidades y de la visión del negocio. Debe tener claro hacia donde se dirige la organización y su estrategia para alcanzar sus objetivos. De alguna manera, los usuarios del data warehouse deben tener un cierto perfil metodológico para analizar la información. Finalmente, un almacén de datos contiene grandes volúmenes de información y si no se sabe por dónde comenzar a analizar, es muy fácil perderse entre un océano de datos y más datos. 24 Gill, H. S. (1996). Data warehousing La integración de la información para la mejor toma de decisiones. México, D. F.: Prentice Hall. P

46 Figura 1.3 Ciclo de madurez de la tecnología (Gill, H. S.) Conforme la compañía comienza a usar cada vez más la información del data warehouse para las actividades diarias, su disponibilidad comienza a ser cada vez más importante. Los requerimientos para un sistema de misión crítica incluyen lo siguiente: Disponibilidad Consistencia y precisión Fuerza Estandarización Actividades basadas en requerimientos Compatibilidad con la tecnología existente y la infraestructura de base de datos Uso diario Uso amigable Alto desempeño Verificable Seguro 33

47 1.2.7 Relación de un SIE con un data warehouse Un sistema de información ejecutivo puede contribuir de manera importante en la toma de decisiones al permitir redefinir y reorientar algunas de las fases del ciclo administrativo de una organización, principalmente en la planeación y control. Esto permite a la organización optimizar en la asignación de recursos, tanto cuantitativos como cualitativos; además de mejorar sus procesos y como resultado aumentar sus utilidades. En la figura 1.4., se pueden observar los pasos que sigue un sistema de información ejecutivo para llevar la información hasta el usuario final. Es importante notar que un data warehouse provee de información al SIE. Por lo que se debe garantizar que la información almacenada en el data warehouse sea confiable y oportuna para su visualización y consulta por cualquier medio. El concepto de sistema de información ejecutivo es simple: los ejecutivos no tienen mucho tiempo, ni la habilidad en muchos casos, para efectuar el análisis de grandes volúmenes de datos. El SIE presenta vistas de los datos simplificados, altamente consolidados y mayormente estadísticos. Puede observarse en la figura 1.4 que se utilizan data marts para relacionar la información entre el data warehouse y las bases de datos operacionales. Existen dos razones de esta división. Primero, simplificar el trabajo que los especialistas de tecnologías de la información (TI) tendrán que hacer para consolidar la información desde las fuentes de datos hasta el data warehouse. La segunda razón son los altos costos que implica mantener una infraestructura tecnológica de este tipo. Usuarios ejecutivos y de negocios Sistema de Información Ejecutivo Control de métricas, variables y parámetros Información externa a la organización Análisis de información de: Estados del presupuesto, reportes financieros, consultas de ingresos y egresos, reportes de nómina y plantilla de personal Datawarehouse Información actual e histórica Análisis multidimensional Datamart del sistema de presupuesto Datamart del sistema de almacén Datamart del sistema de ingresos Datamart del sistema de RH Sistema de presupuesto y contabilidad Sistema de almacén Sistema de ingresos Sistema de recursos humanos Figura 1.4 Flujo de información entre un SIE y un data warehouse (diseño propio) 34

48 El proceso normal de evolución de todo negocio, propicia que la tecnología hacia su interior se vuelva obsoleta y por lo tanto, también tenga que evolucionar. Y el costo de mantenimiento de un SIE y de sus componentes, puede ser tan caro como el desarrollo del proyecto inicial. Por esta razón, los sistemas de información ejecutivos no son una herramienta apropiada para el análisis de información a nivel departamental dentro de la organización. Para apoyar en las tareas de análisis, reporteo y consulta de datos por las áreas operativas de una empresa, se desarrollan data marts y con base en ellos se construye el data warehouse, mismo al que pueden estar conectadas herramientas de análisis multidimensional que permitirán explotar la información de diversas maneras y a costos no tan elevados como la construcción y ajuste del Sistema de Información Ejecutivo empresarial. Los SIE generalmente presentan al ejecutivo dueño del negocio, la información de una manera muy espectacular. Quién no ha visto películas norteamericanas en donde se muestra a los altos ejecutivos de una organización tras sus escritorios, analizando graficas y tablas que se despliegan en pantallas de televisión y en grandes monitores de computadoras? Sin embargo, el desarrollo del concepto de data warehouse ha venido a absorber algunas funciones de los SIE que generalmente eran muy costosas de mantener en ellos. Por ejemplo, todos aquellos reportes que no requieren de una presentación muy sofisticada y que tienen una amplia colección de consultas que se pueden ejecutar sobre ellos, son elementos que pueden ser explotados por herramientas de análisis multidimensional e incluso mediante la ejecución de consultas directamente al data warehouse. Técnicamente, el SIE utiliza la información almacenada en el data warehouse empresarial y la puede combinar con la información externa a la organización, desplegando en pantalla una serie de métricas, variables y parámetros de control que le van a indicar al ejecutivo el comportamiento real de la organización. La información debe fluir a altas velocidades entre los diferentes bloques e incluso se pueden generar alarmas cuando se presentan excepciones al comportamiento normal o esperado de la organización. Las notificaciones pueden enviarse entonces a los responsables por correo electrónico o por mensajes a los teléfonos celulares y radio localizadores. Estos sistemas deben ser lo suficientemente parametrizables para responder a diferentes necesidades de la organización. La programación de estos sistemas debe ser tan modular y flexible, que permita integrar nueva información proveniente del data warehouse y de fuentes externas, con el fin de que los 35

49 administradores puedan mantener al sistema alineado a las especificaciones y requerimientos de los ejecutivos. En la actualidad, la relación SIE data warehouse, es muy común en las organizaciones. Ya sea en menor o mayor escala según las posibilidades de inversión de las empresas que implementan soluciones de este tipo, no hay duda de que a todos los dueños de negocios les gustaría contar con una herramienta de software que les permitiera monitorear al instante y con el menor esfuerzo posible, las condiciones organizacionales para tomar decisiones precisas en el momento preciso Ventajas y desventajas en el uso de un data warehouse A pesar de los beneficios que un data warehouse podría tener en una organización, existen algunas barreras que pueden limitar su uso. Si bien es cierto que este tipo de herramientas resuelven problemas de análisis de grandes volúmenes de información, también es cierto que son productos de software que no se encuentran al alcance de todas las empresas, principalmente por sus altos costos. Relacionado con esto nos encontramos con que es necesario contar con hardware y software muy potente. Un proyecto de este tipo resulta en todos los aspectos excesivo para algunas organizaciones. Para resolver este tipo de necesidades existe la tecnología de los data marts. Algunas de las ventajas y desventajas del uso de un data warehouse, se pueden analizar en la tabla 1.1. Ventajas Desventajas Integrador de sistemas Revisión del modelo de datos, objetos, transacciones, almacenamiento Información consolidada, limpia, consistente, histórica, válida Enfoque al análisis complejo y eficiente Automatizable Normalizador Diseño complejo y multidisciplinar Reestructuración de los sistemas operacionales Alto costo Sistemas, aplicaciones y almacenamiento específico Visión integral de control y gestión de procesos. Tabla 1.1 Ventajas y desventajas del uso de un data warehouse (diseño propio) 36

50 1.3 Concepto de data mart Un data mart es una facilidad parecida a un data warehouse, pero con un dominio mucho más pequeño. El data mart se puede restringir a un tipo particular de datos, a determinada función de negocios, a una unidad de negocios específica, o a un área geográfica 25. Por el contrario, un data warehouse es un almacén que tiene información histórica generada por diversos departamentos en la organización y que responde a consultas enfocadas al análisis estratégico por parte de la alta gerencia, dueños o administradores de una empresa. Se pretende que con el data warehouse se cuente con un único medio de consulta de información en toda la organización, así como de estandarizar el lenguaje corporativo y que todos conozcan los mismos términos. Un data mart puede ser solamente una copia de un conjunto de datos históricos almacenados en el data warehouse. Aunque considero que sería más complicado iniciar por la construcción del data warehouse que por los data marts, que en diseño son más simples de construir. Tanto el data warehouse como los data marts pueden ser explotados utilizando diferentes herramientas. Una de las más utilizadas son las herramientas OLAP (On Line Analytical Processing). Se construyen procesos batch para cargar datos con una frecuencia conocida y después se pueden utilizar las herramientas OLAP, las cuales ofrecen una visión multidimensional de la información. Como se puede ver en la figura 1.4, tanto los data marts como el data warehouse pueden ser utilizados para la construcción de Sistemas de Información Ejecutivos Construcción de un data mart Para construir un data mart, es necesario hacer énfasis en tres aspectos muy importantes: El diseño, la explotación y su mantenimiento. La fase de diseño, contempla realizar un análisis detallado del proceso de negocio del área que se desea modelar y de las posibles fuentes de información disponibles. De un buen diseño, depende que el data mart cumpla con las expectativas del usuario final. Por lo tanto, un modelo de un proceso siempre deberá ir validado y autorizado por el área responsable con el fin de que el constructor esté seguro de que lo que se va a desarrollar, realmente aporte valor a toda la organización. 25 Kroenke, D. (2003). Procesamiento de bases de datos. México: Prentice Hall. P

51 La explotación de la información implica el uso de herramientas que permitan utilizar la información almacenada en el data mart. Pueden utilizarse herramientas de análisis multidimensional que permitirán realizar consultas desde diferentes enfoques y de acuerdo a las necesidades muy particulares de diferentes usuarios. También pueden utilizarse hojas de cálculo e incluso desarrollar aplicaciones de carácter ejecutivo que permitan consultar la información en tableros de control. Ya existen en el mercado algunos productos de software que proporcionan herramientas de reporteo para generar tableros de control y reportes ejecutivos de una forma rápida y sencilla. El mantenimiento del data mart es una de las fases en la que también deberá ponerse mucho cuidado. La actualización de la información almacenada es un aspecto muy importante para las organizaciones. Por este motivo el data mart debe ser lo suficientemente flexible, de tal forma que se pueda agregar nueva información o quitar información obsoleta. También es importante considerar la automatización de archivos de carga de información, con el fin de que esta tarea se repita de manera periódica obteniendo la información de los sistemas operacionales y consolidando y calculando información. En algunas organizaciones, las tareas de carga y consolidación de la información en data marts se realiza en forma manual, lo cual no es lo más aconsejable debido a que esta tarea puede llevar horas e incluso días. En otras organizaciones, estas tareas se encuentran automatizadas y generalmente la información se consolida por las noches. Esta actividad se configura cuando la conexión entre los data marts y las bases de datos operacionales no pude estar en línea debido a cargas de información en las redes de comunicaciones, lo cual puede originar lentitud debido a la gran cantidad de datos que pueden viajar por la red. Por otro lado, aunque no menos importante se encuentra la capacitación en el uso y explotación de los data marts. Si bien es cierto que este tipo de herramientas ayudan a agilizar los procesos de toma de decisiones de los usuarios, también es cierto que la capacitación es indispensable para un mayor aprovechamiento de la tecnología. Lo importante es que el usuario no sea dependiente de las áreas técnicas para generar consultas. Es necesario dotar a los usuarios de aquellas herramientas de reporteo que les permitan realizar consultas y que el data mart responda en tiempos adecuados. No obstante, el uso exitoso de este tipo de herramientas también dependerá de la capacidad de análisis y habilidades de toma de decisiones que tengan los usuarios. De nada servirá proporcionar la mejor herramienta de consulta o la más rápida o un sistema ejecutivo muy dinámico si los usuarios no tienen la capacidad 38

52 metódica y analítica para consultar e interpretar la información que un data mart o que cualquier otra herramienta de reporteo- les puede proporcionar. Desarrollar un data mart para una organización contempla dos pasos. Primero se deberán identificar los requerimientos del negocio y después planear la mejor forma de implementar la solución. En el primer paso, es necesario entender: Cómo está estructurada la información dentro de la organización? Cómo fluye la información en la organización? Cuál será el nivel de detalle o desagregación de la información en el data mart? El segundo paso consistirá en: Localizar las fuentes de datos. Identificar si los datos están disponibles en alguna parte o deberán construirse los sistemas de información necesarios que permitan primero almacenar dichos datos y después consolidarlos en el data mart. Determinar si la estructura de la información almacenada en las fuentes de datos será compatible con la estructura de información del data mart o deberán diseñarse reglas de carga para filtrar, ajustar, integrar y fragmentar los datos a consolidar. Determinar la periodicidad con que la información deberá ser consolidada desde las fuentes de datos hacia el data mart y realizar la automatización de esta tarea. Definir el nivel de detalle que la base de datos del data mart deberá tener, a fin de considerar todos los requerimientos de información de los usuarios. Definir la estructura de metadatos necesaria, así como las reglas de cálculo que se necesitarán para consolidar información en el data mart. Desarrollar las consultas necesarias así como preparar los elementos de explotación de información basados en la arquitectura del data mart. Una herramienta importante para diseñar la estructura del data mart es definir un outline o plantilla que contendrá la estructura de metadatos y los diferentes niveles de agregación de la información que será almacenada. Un data mart tiene componentes similares (ver figura 1.2) a los del data warehouse. La principal diferencia está en el enfoque del usuario final. Como en el caso de un data warehouse, cada componente o bloque contempla el desarrollo de un conjunto de procesos para: 39

53 Diseñar el modelo de datos con base en el análisis de requerimientos. Definir y crear la estructura de los metadatos que almacenarán la información en el data mart. Filtrar la información de las fuentes de datos. Ajustar la información al formato requerido para el data mart. Integrar la información en un bloque de datos para ser importados al data mart. Consolidar y agregar la información en el data mart. Ejecutar procesos de cálculo una vez consolidada la información en el data mart. Explotar la información almacenada en el data mart Requerimientos para la construcción de un data mart Una forma de apreciar los beneficios es analizar las necesidades empresariales con las que deberá cumplir el desarrollo de un data mart. Las necesidades son diferentes para cada tipo de usuario: El inversionista/dueño de la empresa, el arquitecto o constructor de la solución y el usuario final 26. El inversionista o dueño de la empresa participa en la definición de la visión de lo que será el data warehouse o del data mart. Participa en la planeación y coordinación de todo el proyecto. Por su capacidad de toma de decisiones y de control sobre todas las actividades de la organización, este usuario tiene la facultad de hacer que las cosas se lleven a cabo. Por lo tanto, él autoriza la construcción de la solución así como los costos del desarrollo. Algunas de sus actividades son: o Participar en la elaboración del plan de implementación de la solución. o Aprobar el costo de la inversión. o Garantizar el soporte organizacional para quitar barreras que impidan completar las tareas de análisis y desarrollo. o Ser una guía en el desarrollo de los trabajos y para la definición del alcance y objetivos del proyecto. El arquitecto o constructor de la solución se encarga de definir el modelo de datos así como de estimar las necesidades tecnológicas para el desarrollo y 26 Gill, H. S. (1996). Data warehousing La integración de la información para la mejor toma de decisiones. México, D. F.: Prentice Hall. P

54 operación del data warehouse o del data mart. Si es personal interno a la organización, este usuario se responsabiliza también por el mantenimiento de la aplicación, así como de la automatización de los procesos de carga y consolidación de información en la solución de data warehousing. Si es personal externo a la organización, este usuario se responsabiliza por dejar el conocimiento necesario al personal técnico interno que se encargará de mantener y automatizar las tareas a fin de que la solución se ejecute con el menor número de errores y con la mínima intervención humana. Algunas de sus actividades son: o Mantener la calidad de la solución implantada agregando nuevas funcionalidades y manteniendo en óptimas condiciones la operación de la herramienta. o Proporcionar al usuario final las herramientas de explotación de información necesarias y que sean de fácil uso. o Mantener la exactitud de los formatos diseñados y el contenido de la solución de data warehousing desde la perspectiva del usuario final. o Buscar y mantener en óptimas condiciones las velocidades de consulta y respuesta de la herramienta hacia el usuario final. El usuario final es la persona que utilizará diariamente la solución de data warehousing. Su principal interés es que la herramienta le proporcione la información necesaria para conocer el estado del negocio y tomar así mejores decisiones aumentando la productividad y la eficiencia de su trabajo. Estos usuarios necesitan contar con información y visualizarla de diferentes formas, utilizando herramientas de análisis multidimensional y análisis de datos como hojas de cálculo. Algunas de sus actividades son: o Proporcionar el conocimiento necesario sobre los procesos de negocio relacionados con su trabajo. o Ser el enlace con los clientes y proveedores por lo que necesitan contar con información precisa de las operaciones de la organización. o Informar a los dueños del negocio y administradores sobre las actividades desarrolladas en un cierto periodo de tiempo. Por otro lado, el arquitecto o constructor de la solución, puede realizar su análisis de requerimientos con base en las preguntas tradicionales para el diseño de 41

55 software. Me refiero a las clásicas preguntas de: Quién? Qué? Dónde? Cuándo? Cómo? 27 Quién? o Quiénes serán los usuarios finales de la aplicación? El equipo de administración, finanzas, mercadotecnia, etc. o Quién desarrollará y dará soporte a la aplicación? Deberán ser personas con conocimientos de la tecnología y del negocio. o Quién es responsable de analizar y cambiar la estructura de la solución de data warehousing? Debería ser el DBA de la aplicación, ya que debe ser alguien que conozca el contexto general de la aplicación ya que un cambio puede afectar a toda la solución. Qué? o Cuáles son los requerimientos del negocio? El propósito principal de esta herramienta será proveer la información necesaria en el momento adecuado para la mejor toma de decisiones. o Cuáles son las necesidades de reporteo? Análisis de presupuestos, análisis de mercado, etc. o Cuáles serán las perspectivas de análisis? Análisis de escenarios, de tiempos, de productos, de mercados, etc. o Cuál será el nivel de detalle que se consolidará en el data mart? El análisis podrá ser anual, trimestral, diario, por áreas geográficas, por tipo de producto, etc. o Cuáles son los requerimientos de información histórica? Adicionalmente a la información del año actual, cuántos años hacia atrás deberá considerar el data mart. o Cuál será la criticidad de la herramienta? La herramienta debería estar disponible las 24 horas del día, los 365 días del año, los 7 días de la semana, con acceso de lectura escritura por periodos de tiempo o solo de lectura. o Cuál será el origen de los datos? Los datos serán extraídos de las bases de datos de los sistemas operacionales y se construirán sistemas nuevos que almacenen y procesen aquellos datos no considerados en los sistemas existentes, se extraerá información de hojas de cálculo, documentos de Word o de otros formatos, etc. 27 Hyperion Solutions Corporation. (2000). Hyperion Essbase Fundamentals Training. Sunnyvale, California: Hyperion Solutions Corporation. P

56 Dónde? o Dónde se encontrará físicamente trabajando el personal que será usuario de la herramienta? Podrá ser personal que continuamente viaje, el personal trabaja desde algún lugar diferente a la oficina o se encuentra concentrado en un área geográfica invariable. o Dónde se encontrarán las fuentes de datos disponibles? Son bases de datos concentradas en centros de datos, algunos datos están dispersos en hojas de cálculo por diferentes áreas de la organización, son datos provenientes de sistemas externos, etc. Cuándo? o En qué momento estará disponible la información para su consolidación al data mart? En algunas organizaciones esta tarea se lleva por las noches, ya que el volumen de datos puede representar una carga excesiva para la red de comunicaciones. o En qué momento se publicará y estará disponible la información del data mart hacia los usuarios? Dependerá de las necesidades de información del área usuaria. Cómo? o Cómo será el mecanismo de extracción de información actual e histórica? Se construirán data marts históricos y uno solo que consolide la información de todos o cuál será la arquitectura de diseño para responder a preguntas de este tipo. o Qué tan frecuentes serán los ajustes a la configuración y estructura de la solución de data warehousing? Podría ser cada fin de ejercicio fiscal o cada vez que se necesite agregar nueva información, etc. o Cómo se tendrá que diseñar la estructura del data mart para permitir que sea lo suficientemente flexible? Con la respuesta a esta pregunta, se logrará que el personal técnico modifique lo menos posible la estructura de la base de datos y realizar rápidamente los cambios solicitados. 43

57 1.3.3 Data mart distribuido Muchas organizaciones, sobre todo los grandes corporativos, están divididas en organizaciones más pequeñas que se especializan en realizar cierta función. Una de las ventajas de utilizar data marts para construir un data warehouse, es que los data marts pueden estar dispersos geográficamente en diversas localidades. Esto permite que áreas o departamentos exploten la información de sus propios data marts, a la vez que la información almacenada en ellos se puede consolidar hacia el data warehouse empresarial (en caso de que exista). Esta capacidad de los data marts permite también compartir información entre los mismos. Algunos beneficios de distribuir data marts en áreas geográficas son (Hyperion Solutions Corporation, 1999): Permiten que las áreas usuarias por departamento, tengan a su disposición un mercado de datos de todas las operaciones consolidadas en su área. Cuando un usuario del data warehouse necesita consultar una información o algún dato con mayor detalle, puede enlazarse desde el data warehouse hacia el data mart directamente. Es más sencillo el mantenimiento de un data mart que el de todo un data warehouse. La consolidación de información hacia un data mart es mucho más rápida que intentar consolidar la información de toda una organización hacia un data warehouse. Los data marts distribuidos son diseñados por el arquitecto o constructor de la solución de data warehousing, en respuesta a las necesidades del negocio. El constructor también diseña la manera en la que se van a comunicar los data marts entre sí y la forma en la que se consolidará la información hacia el data warehouse de la organización. La complejidad del diseño del data mart se encuentra en la construcción de la base de datos del mismo. Como ya se ha mencionado anteriormente, el primer paso es determinar los requerimientos del negocio y después diseñar la estructura que contendrá el data mart para almacenar la información que el área necesite. Múltiples bases de datos de un data mart pueden conformar un modelo. 44

58 1.3.4 La complejidad de transformar datos en información en una solución de data warehousing Una razón de la complejidad de construir una solución de data warehouse, es el conjunto de técnicas que se requieren para formular, desarrollar, implementar, desplegar y explotarlo. En mi opinión, el diseño del data warehouse - como el de todo sistema de información basado en computadoras -, conforma la parte medular para obtener una buena herramienta de negocios. Es en el diseño donde se invertirán la mayor cantidad de recursos, ya que debe definirse claramente el alcance del proyecto de la solución, el origen de los datos, el tipo de información que podrá ser consultada y la relación entre diferentes almacenes de datos que incluso pueden estar separados físicamente por varios kilómetros de distancia. El conocimiento del negocio es imprescindible para el éxito de un proyecto de este tipo. Con frecuencia, el reto consiste en transformar la regla de negocio y los enunciados estratégicos generales de la organización en indagaciones empresariales precisas y después convertirlos en solicitudes y reportes del data warehouse (ver la figura 1.5). En muchos de los casos, el data warehouse se basa en resúmenes de información provenientes de sistemas de producción. Construir un data warehouse, en algunos casos implica: Comprender la forma como estos sistemas manejan y almacenan datos. Entender cómo construir extractores de información, los cuales transfieren datos de los sistemas de producción al data warehouse Construir y configurar el software de sincronización que conservará actualizado el data warehouse con la información del sistema de producción. Figura 1.5. Proceso de transformación de datos en información en una solución de data warehousing (diseño propio) 45

59 Y una vez construido el data warehouse, es necesario aplicar técnicas de análisis de datos para entender el comportamiento organizacional que muestra el data warehouse, como por ejemplo: Evaluación de información cuantitativa. Derivar conclusiones basadas en hechos a partir de información histórica. Descubrir patrones y tendencias. Extrapolar las tendencias basadas en los antecedentes a fin de entender e identificar las anomalías o cambios de paradigma. Una parte de estas técnicas se basa en las matemáticas, otra en la estadística, una más en la psicología y la intuición o la experiencia. Antes de que los administradores de una organización puedan tomar decisiones cruciales basadas en un data warehouse, se necesita realizar una transformación de la información almacenada en los sistemas operativos. Muchas compañías usan Sistemas de Procesamiento de Transacciones en Línea (OLTP) para recuperar y analizar la información almacenada. Una vez que la información está concentrada, se aplica un procesamiento de consolidación y cálculo de datos.cuando este procesamiento finaliza, los datos pueden ser utilizados para su análisis y puede convertirse en información útil para la toma de decisiones. 1.4 Modelo de datos multidimensional Como en todo proyecto de software, la construcción de una solución de data warehousing inicia por el modelado de datos. Los modelos de datos que se usan para representar los datos almacenados en un data warehouse, no son necesariamente los mismos que los usados para representar una base de datos relacional. Sin embargo, el desarrollo del proyecto comienza como en cualquier desarrollo de software, por el análisis de requerimientos y por el modelado de lo que se va a construir. El modelo de datos y los requerimientos de los usuarios pueden ayudar a diseñar la estructura de un data warehouse. En algunas ocasiones, el modelo de datos para la construcción de un data warehouse o de un data mart se puede obtener analizando el modelo de datos de toda la organización. Los data warehouses y las herramientas OLAP están basadas en un modelo multidimensional. Este modelo visualiza los datos en forma de un cubo de datos. 46

60 Un cubo de datos permite modelar y visualizar datos en múltiples dimensiones. 28 Los cubos de información son matrices multidimensionales que sirven para representar el almacenamiento de datos y su consulta desde múltiples puntos de análisis. Este concepto de modelos multidimensionales, convierte el análisis de información visto en dos dimensiones (renglones y columnas) en múltiples dimensiones representadas por un cubo de información (ver la figura 1.7). Las fases o caras del cubo representan las dimensiones. Por ejemplo, supongamos que una empresa necesita crear un data warehouse para almacenar sus registros de ventas con respecto al tiempo, producto y mercado. Las dimensiones le permitirán al usuario poder obtener información semejante a las ventas por mes, clasificándola por tipo de producto y por mercado. Cada dimensión tiene una tabla asociada, a la cual se le llama tabla de dimensión (dimension table). Por ejemplo, una tabla de dimensión para producto puede contener los atributos nombre, marca y tipo. Un modelo multidimensional se organiza con base en un tema central como las ventas de una empresa. El tema central de un cubo es representado en el modelo multidimensional por medio de una tabla de hechos (fact table). Las tablas de hechos contienen métricas o parámetros numéricos. Los hechos representan las cantidades que se obtienen mediante las relaciones entre las dimensiones. Ejemplos de tablas de hechos para un data warehouse de ventas pueden ser unidades_vendidas, ventas_en_dolares y presupuesto_ventas. Aunque usualmente representamos un cubo como una estructura tridimensional, en un modelo multidimensional los cubos de datos pueden tener n dimensiones. Cada dimensión o cara del cubo de información, es identificada por una etiqueta que representa la percepción que el usuario tiene de los datos que esa cara representa. Para comprender mejor los cubos de datos y los modelos multidimensionales, analicemos primero un ejemplo de un cubo de datos de dos dimensiones (representación 2-D), el cual es realmente una tabla de registros estructurada en filas y columnas. Esta tabla de datos contiene información referente al presupuesto ejercido o pagado para la reconstrucción de tramos de carretera o puentes en el Estado de Baja California, clasificada con respecto a la dimensión Tiempo organizada por trimestre (ver tabla 1.2). 28 Han, J. (2006). Data Mining: Concepts and Techniques. San Francisco, CA.: Morgan Kaufmann. 47

61 Localización = "Baja California" Tipo de trabajo Tiempo (trimestre) Reconstrucción de puentes Reconstrucción de tramos 1mer trimestre do trimestre er trimestre to trimestre Tabla 1.2 Una vista en dos dimensiones del presupuesto ejercido (métrica desplegada) en una empresa pública, con respecto a las dimensiones tiempo y tipo de trabajo en el Estado de Baja California (diseño propio) Ahora supongamos que queremos visualizar el presupuesto ejercido con respecto a una tercera dimensión. Tal vez nos gustaría ver los datos con respecto a las dimensiones tiempo y tipo de trabajo, pero también clasificada para otro Estado de la República como Nayarit. Esta vista en 3-D se puede analizar en la tabla 1.3. La vista en 3-D de la tabla 1.3 se representa como una serie de tablas en 2-D. Conceptualmente podemos representar los mismos datos en forma de un cubo de datos de tres dimensiones (3-D cube), como se puede visualizar en la figura 1.6. Localización = "Nayarit" Localización = "Baja California" Tipo de trabajo Tipo de trabajo Tiempo (trimestre) Reconstrucción de puentes Reconstrucción de tramos Reconstrucción de puentes Reconstrucción de tramos 1mer trimestre do trimestre er trimestre to trimestre Tabla 1.3 Una vista 3-D del presupuesto ejercido (métrica desplegada) en una empresa pública, con respecto a las dimensiones tiempo, tipo de trabajo y localización (diseño propio) Supongamos ahora que necesitamos visualizar el presupuesto ejercido con una cuarta dimensión adicional llamada centro de trabajo, el cual representa la oficina encargada de ejercer el presupuesto para construir o conservar las carreteras del país. Visualizar información pensando en una cuarta dimensión puede parecer confuso. No obstante, podemos pensar en un cubo de cuatro dimensiones como una serie de cubos de tres dimensiones, como se puede visualizar en la figura 1.7. De hecho, podríamos visualizar un cubo de n-d dimensiones como una serie de (n-1)-d cubos. Un cubo de datos es una forma de representar el almacenamiento de datos multidimensional. Pero el almacenamiento físico de los datos puede diferir de su representación lógica. Lo importante para el presente trabajo y en general para la materia de data warehousing, es tener en mente que los cubos de datos son n-dimensionales y no están limitados a cubos de tres dimensiones. 48

62 Trimestre Trimestre Trimestre Trimestre Reconstrucción de puentes Nayarit Reconstrucción de tramos 1ro do 3ero 4to Localización Baja California Nayarit 1ro do ro 2do Baja California Reconstrucción Reconstrucción de puentes de tramos ero 4to Reconstrucción de puentes Reconstrucción de tramos Tipo de trabajo ro to Figura 1.6 Una representación de un cubo de datos de tres dimensiones de la tabla 1.3, respecto a las dimensiones tiempo, tipo de trabajo y localización. La métrica que se despliega es el presupuesto ejercido en una empresa pública (diseño propio). Centro de trabajo = CT1 Centro de trabajo = CT2 Centro de trabajo = CT3 Localización Baja California Nayarit 1ro do 3ero 4to Reconstrucción Reconstrucción de puentes de tramos Tipo de trabajo Reconstrucción Reconstrucción de puentes de tramos Tipo de trabajo Reconstrucción Reconstrucción de puentes de tramos Tipo de trabajo Figura 1.7 Representación de un cubo de datos de cuatro dimensiones (4-D) para el presupuesto ejercido de una empresa pública, respecto a las dimensiones tiempo, tipo de trabajo, localización y centro de trabajo. Solo son mostrados algunos datos de ejemplo (diseño propio). 49

63 Las tablas anteriores muestran datos a diferentes niveles de agregación. En la literatura de investigación data warehousing, los cubos de datos como los antes descritos son llamados a menudo cuboides. Dado un conjunto de dimensiones, podemos generar un cuboide para cada uno de los posibles subconjuntos de las dimensiones dadas. Como resultado se podrá obtener una enramada de cuboides, cada uno mostrando datos a diferentes niveles de agregación o agrupación (group by). A la enramada de cuboides es llamada entonces cubo de datos. 29 La figura 1.8 muestra una enramada de cuboides que forma un cubo de datos para las dimensiones tiempo, tipo de trabajo, localización y centro de trabajo. Todo 0-D cuboide Tiempo Tipo de trabajo Localización Centro de trabajo 1-D cuboide Tiempo, tipo de trabajo Tiempo, localización Tiempo, centro de trabajo Tipo de trabajo, localización Tipo de trabajo, centro de trabajo Localización, centro de trabajo 2-D cuboide Tiempo, tipo de trabajo, localización Tiempo, tipo de trabajo, centro de trabajo Tiempo, localización, centro de trabajo Tipo de trabajo, localización, centro de trabajo 3-D cuboide Tiempo, tipo de trabajo, localización, centro de trabajo 4-D cuboide Figura 1.8 Enramada de cuboides que forman un cubo de datos de cuatro dimensiones (4-D) las cuales son tiempo, tipo de trabajo, localización y centro de trabajo. Cada cuboide representa un grado diferente de agregación de la información (diseño propio). El cuboide que recupera el nivel más bajo de agregación de la información se llama cuboide base. Por ejemplo, en la figura 1.8 el cuboide 4-D es el cuboide base para las dimensiones tiempo, tipo de trabajo, localización y centro de trabajo. La figura 1.6 es un cuboide 3-D (no base) para las dimensiones tiempo, localización, tipo de trabajo para todos los centros de trabajo. En la figura 1.8, el 29 Ibid., p

64 cuboide 0-D recupera el nivel más alto de agregación de la información. En este ejemplo, el cubo desplegaría el total de presupuesto ejercido sumarizado para las cuatro dimensiones. Un dado global que pudiera no tener sentido para los usuarios, hasta el momento en que comenzaran a desagregar la información navegando por la enramada de cuboides para las dimensiones dadas. Pero, Cuántos cuboides hay en un cubo de datos de n dimensiones? Si no hay asociaciones de jerarquía en cada dimensión, entonces el número total de cuboides para un cubo de datos de n dimensiones sería de 2ⁿ. Sin embargo, en la práctica, las dimensiones tienen jerarquías. Por ejemplo, la dimensión tiempo tiene una jerarquía similar a año > trimestre > mes > día. Para un cubo de datos de n dimensiones, el número total de cuboides que se pueden generar (incluyendo los cuboides generados navegando por la jerarquía de niveles de cada dimensión) es 30 n Número total de cuboides = (Lі+1) і =1 (1.1) donde Li es el número de niveles asociados con la dimensión i. Se adiciona uno a Li para incluir el nivel virtual más alto o 0-D. Esta fórmula se basa en el hecho de que al menos un nivel de abstracción de cada dimensión aparecerá en un cuboide. Por ejemplo, la dimensión tiempo especificada arriba tiene 4 niveles, o 5 si incluimos el nivel virtual 0-D. Si el cubo tiene 10 dimensiones y cada dimensión tiene 5 niveles (incluyendo el nivel cero), el número total de cuboides que puede generarse es x 10 6 El tamaño de cada cuboide depende también de la cardinalidad (número de valores distintos) para cada dimensión. Continuando con el ejemplo de la empresa pública, si se desarrollaran todos los tipos de trabajo en todos los Estados del país, habrá tipo de trabajo x localización tuplas en la agrupación tipo de trabajolocalización. Trabajar con cubos de información para construir un data mart o un data warehouse tiene diferentes ventajas como: a) Permitir que los usuarios generen sus consultas de diferentes formas y vistas ya que no se requieren conocimientos de programación, b) Compartir y ser la única fuente de información en toda la organización y 30 Han, J. (2006). Data Mining: Concepts and Techniques. San Francisco, CA.: Morgan Kaufmann. P

65 c) Combinar información de múltiples fuentes y con diversas estructuras de datos. Con estos cubos de información, se pueden construir Sistemas de Información para ejecutivos y sistemas de ayuda a la toma de decisiones. La responsabilidad del análisis de la información queda en manos del dueño de los datos con el objeto de que extraiga información útil para realizar predicciones y determinar sus propios indicadores, liberándole así el tiempo necesario para definir qué información desea consultar y no cómo la puede obtener. Un modelo multidimensional está organizado alrededor de un tema central como las ventas de una empresa, por ejemplo Modelo de estrella El modelo de estrella es el modelo más simple para desarrollar un data warehouse. Es llamado así porque el diagrama asemeja a una estrella. En el centro de la estrella se tiene una tabla llamada tabla de hechos (fact table) y alrededor se tienen otras tablas a las que se les llama tablas de dimensión (dimension tables). Ver fig 1.9. El modelo de estrella es el modelo más sencillo para diseñar un data warehouse o un data mart. Como se puede observar en la figura 1.9, existe solo una relación entre la tabla de hechos contra cada tabla de dimensión. En este trabajo se construirá un data mart que utilizará como repositorio de datos un cubo de información. En muchos aspectos, un cubo de información es muy parecido a un modelo de estrella. El cubo desempeña el papel de tabla de hechos y una dimensión OLAP desempeña el papel de una tabla de dimensiones. Las dimensiones pueden ser listas simples de miembros, o pueden estar organizadas en niveles y jerarquías. Las dimensiones jerárquicas permiten que los datos se agrupen desde niveles más bajos a niveles más altos de resumen Vlamis, D. (s.f.). Oracle OLAP 11g incorpora características de alto desempeño para el depósito de datos en Oracle Database 11g. Recuperado el 03 de Agosto de 2009, de 52

66 Figura 1.9 Modelo de estrella (diseño propio) Modelado de consultas empresariales Una técnica adicional que puede servir para definir la estructura de un data warehouse o de un data mart, es hacer el modelado de consultas que los usuarios finales van a poder ejecutar. La técnica de modelado para entender, modelar y analizar consultas empresariales consiste en construir moldes de consultas. La figura 1.10 muestra un modelo típico de molde de consulta. 32 En esta figura, se aísla de sus dimensiones al área tema de la consulta. Esto permite buscar candidatos potenciales de tablas de hechos y dimensión para el modelo del data warehouse. Figura Modelo de molde de consulta (Gill, H. S.) 32 Gill, H. S. (1996). Data warehousing La integración de la información para la mejor toma de decisiones. México, D. F.: Prentice Hall. 53

67 Una vez identificados los moldes de consulta para cada consulta empresarial, las consultas y sus moldes se consolidan. El diagrama consolidado resultante para cada área tema se denomina modelo Starnet (Red estrella). Esta es la representación combinada de todas las consultas empresariales Minería de datos (data mining) Los almacenes de datos (data warehouses) y los mercados de datos (data marts) son usados en un amplio rango de aplicaciones. Los ejecutivos de negocios usan los datos almacenados en un data warehouse y en un data mart para realizar análisis de datos y tomar decisiones estratégicas. Los almacenes de datos son muy utilizados en la banca y en las compañías que proporcionan servicios financieros, para detectar necesidades de consumidores y sectores de distribución rentables. Para llegar al momento actual, los almacenes de datos tuvieron que pasar por diferentes fases. Inicialmente, eran muy utilizados para la generación de reportes y para contestar a preguntas predefinidas. Progresivamente, los almacenes de datos fueron usados para analizar información resumida y detallada, donde los resultados eran presentados en forma de reportes y gráficas. Posteriormente, los almacenes de datos fueron usados con propósitos estratégicos, realizando análisis multidimensional y operaciones sofisticadas de análisis de datos. Finalmente, los almacenes de datos fueron empleados para el descubrimiento de conocimiento y toma de decisiones estratégicas usando herramientas de minería de datos. En este contexto, las herramientas para data warehousing pueden ser clasificadas en herramientas de acceso y recuperación de datos, herramientas de reporteo de datos, herramientas de análisis de datos y herramientas de minería de datos. Los usuarios de negocio necesitan conocer el contenido de su data warehouse o data mart, cómo explotarlo por medio de herramientas de análisis y como presentar el resultado de dicho análisis. Existen tres tipos de aplicaciones de data warehouse: procesamiento de información, procesamiento analítico y minería de datos 34. El procesamiento de información soporta consultas, análisis estadístico básico y reporteo usando hojas de cálculo, tablas, gráficas. 33 Ibid., p Han, J. (2006). Data Mining: Concepts and Techniques. San Francisco, CA.: Morgan Kaufmann. P

68 El procesamiento analítico soporta operaciones OLAP básicas, incluyendo drill-down, roll-up y pivoteo. Estas operaciones generalmente se hacen en datos históricos ya sea sumarizada o a detalle. El mayor esfuerzo en este tipo de procesamiento es el análisis multidimensional. La minería de datos soporta el descubrimiento de conocimiento buscando patrones y asociaciones ocultas, construyendo modelos analíticos, realizando clasificación y predicción y presentando los resultados de la minería usando herramientas de visualización. Y, qué significa entonces el concepto de minería de datos? Se refiere a extraer o minar conocimiento de grandes cantidades de datos. 35 Mucha gente se refiere a la minería de datos como un sinónimo de otros términos como Descubrimiento de Conocimiento (KDD por sus siglas en ingles Knowledge Dicovery from Data). Otras personas ven a la minería de datos como un paso esencial en el proceso de descubrimiento de conocimiento. Este proceso lo podemos analizar en la figura 1.11 y consiste en una secuencia iterativa de los pasos siguientes. Figura La minería de datos como un paso en el proceso de descubrimiento de conocimiento (Han, Jiawei) 35 Ibid, p

69 1. Limpieza de datos (remover inconsistencias en los datos). 2. Integración de los datos (múltiples fuentes de datos pueden ser combinadas). 3. Selección de datos (los datos importantes para determinado análisis son recuperados de la base de tados). 4. Transformación de los datos (convertir o consolidar los datos en alguna forma apropiada para minar, realizando operaciones de resumen o agregación, por ejemplo). 5. Minería de datos (es un proceso en donde mediante la aplicación de métodos inteligentes se extrae patrones de datos). 6. Evaluación de patrones (identificar los patrones realmente importantes que representen conocimiento basado en alguna métrica de interés). 7. Presentación de conocimiento (técnicas de visualización y representación de conocimiento son usadas para presentar el conocimiento minado al usuario). Los paso 1 al 4 son diferentes formas de preprocesamiento de datos, en donde los datos son preparados para minar. El paso 5 (minería de datos) puede interactuar con el usuario o con la base de conocimiento. Los patrones de interés son presentados al usuario y pueden ser almacenados como un nuevo conocimiento en la base de conocimiento. Es importante resaltar que de acuerdo a lo anterior, la minería de datos es solo un paso en el proceso completo, aunque es un paso esencial porque permite descubrir patrones escondidos para su evaluación (paso 6). La minería de datos es el proceso de descubrimiento de conocimiento de interés en grandes volúmenes de datos almacenados en bases de datos, almacenes de datos u otros repositorios de información. 36 Con base en lo anterior, la arquitectura de un sistema de minería de datos típico puede tener los siguientes componentes (figura 1.12): Una base de datos, un data warehouse, la www (Word Wide Web) u otro repositorio de información: Esto es una o un conjunto de bases de datos, 36 Ibid, p

70 almacenes de datos, hojas de cálculo u otros tipos de repositorios de información. Pueden llevarse a cabo técnicas de limpieza e integración de datos. Un servidor de base de datos o de data warehouse: El servidor de base de datos o del data warehouse es responsable de buscar datos relevantes, basado en las solicitudes de minería de datos del usuario. Conocimiento base: Es el dominio de conocimiento que es usado para guiar la búsqueda o evaluar la importancia de los patrones resultantes. Tal dominio de conocimiento puede incluir el concepto de jerarquías, usadas para organizar atributos o valores de atributo en diferentes niveles de abstracción. Motor de minería de datos: Este es esencial para el sistema de minería de datos y consiste en un conjunto de módulos funcionales para realizar tareas de caracterización, asociación y análisis de correlación, clasificación, predicción, análisis de valores atípicos y evaluación. Módulo de evaluación de patrones: Este componente normalmente emplea métricas de interés e interactúa con el módulo de minería de datos para enfocar la búsqueda hacia ciertos patrones. Alternativamente, el módulo de evaluación de patrones puede estar integrado con el módulo de minería de datos, dependiendo de la implementación del método de minería utilizado. Interfase de usuario: Este módulo es el medio de comunicación entre el usuario y el sistema de minería de datos, permitiendo al usuario interactuar con el sistema especificando consultas, proveyendo información de ayuda para enfocar la búsqueda y realizando exploración basado en resultados previos. Este componente le permite al usuario navegar en bases de datos y almacenes de datos o estructuras de datos, evaluar patrones de minería y visualizar patrones de diferentes maneras. Desde una perspectiva de data warehouse, la minería de datos puede ser vista como un estado avanzado de procesamiento analítico en línea (OLAP). No obstante, la minería de datos va mucho más allá que el ámbito de aplicación estilo resumen del procesamiento analítico de los sistemas de data warehouse, incorporando técnicas más avanzadas de análisis de datos. La minería de datos integra técnicas de diferentes disciplinas como tecnología de bases de datos y de data warehouse, estadísticas, inteligencia artificial, reconocimiento de patrones, redes neurales, visualización de datos, recuperación 57

71 de información, procesamiento de imágenes y señales y análisis espacial o temporal. Pero, cómo se relaciona la minería de datos con el procesamiento de información y con el procesamiento analítico en línea? El procesamiento de información, basado en consultas (queries), puede encontrar información útil. Sin embargo, las respuestas a tales consultas reflejan la información almacenada directamente en bases de datos. Las consultas hechas no reflejan patrones o regularidades ocultas en la base de datos. Por lo tanto, el procesamiento analítico en línea no es minería de datos. Figura Arquitectura general de un sistema de minería de datos (Han, Jiawei) El procesamiento analítico en línea es muy cercano a la minería de datos, ya que puede desagregar información de un data warehouse agregada en múltiples niveles de granularidad. Sin embargo, las funcionalidades OLAP y de minería de datos no tienen ninguna relación. La tecnología OLAP es una herramienta de resumen/agregación que ayuda a simplificar el análisis de datos, mientras que la minería de datos permite el descubrimiento automático de patrones y el descubrimiento de conocimiento importante oculto en grandes volúmenes de datos. Las herramientas OLAP están dirigidas a simplificar y soportar el análisis interactivo de datos, mientras que el objetivo de las herramientas de minería de datos es automatizar el proceso tanto como sea posible, permitiendo a los 58

72 usuarios guiar el proceso. En este sentido, la minería de datos va un paso adelante del procesamiento analítico en línea tradicional. La minería de datos cubre un mayor especto de funcionalidades que las operaciones permitidas por las herramientas OLAP, debido a que la minería de datos no solo realiza agregación y comparación de datos sino que también permite la asociación, clasificación, predicción, análisis de series de tiempo y otras tareas de análisis de datos 37. Las funcionalidades de minería de datos son usadas para especificar los tipos de patrones que pueden encontrase en minería de datos. En general, las funciones de minería de datos pueden clasificarse en dos categorías: descriptivas y predictivas. Las funciones de minería descriptivas determinan las propiedades generales de los datos en una base de datos. Las tareas predictivas realizan inferencia en los datos para realizar predicciones. En algunos casos los usuarios no tienen idea en cuanto a que tipo de patrones en sus datos pueden ser de interés y por lo tanto deciden buscar diferentes tipos de patrones en paralelo. Esta es una característica que los sistemas de minería de datos deben proporcionar. También deben permitir a los usuarios especificar sugerencias a fin de guiar la búsqueda de patrones. Las funcionalidades de minería de datos y los tipos de patrones que pueden encontrar son los siguientes: Caracterización de datos. Es un resumen de las características generales de una clase objetivo de datos. Un ejemplo puede ser describir las características de los clientes que gastan más de $10, pesos al año en equipo electrónico. Discriminación de datos. Es una comparación de las características generales de una clase objetivo de datos contra uno o un conjunto de clases en contraste. Por ejemplo, para el usuario puede ser importante comparar las características de algún equipo electrónico cuyas ventas se hayan incrementado en determinado porcentaje en el último año, contra otros equipos cuyas ventas hayan disminuido en el mismo periodo de tiempo. Asociación. Corresponde al descubrimiento de patrones que ocurren frecuentemente de manera simultánea. Como la compra de leche y pan o la 37 Ibid., p

73 compra de una computadora seguido por la compra de una cámara digital que a su vez le puede seguir la compra de una tarjeta de memoria. Clasificación y predicción. Consiste en buscar un modelo que permita describir y distinguir clases de datos o conceptos, con el propósito de usar el modelo para predecir objetos de clases no conocidas. El modelo obtenido se basa en el análisis de un conjunto de datos de prueba. Por ejemplo, El número de personas que pudieran comprar cierto tipo de auto con base en su edad, ingreso, trabajo y genero. Clustering. A diferencia de la clasificación y predicción (punto anterior), el cual analiza clases etiquetadas de objetos de datos, esta funcionalidad analiza objetos de datos sin tener una clase ya conocida. En general, no existe una clase conocida para cierto tipo de objetos. Los objetos son agrupados según sus similitudes en comparación con objetos que a su vez son muy diferentes con respecto a objetos pertenecientes a otros grupos. Por ejemplo, los clientes en diferentes poblaciones pueden agruparse con base en sus preferencias o diferencias de compra por población, edad, ingreso, región Análisis de datos anormales. Una base de datos puede contener objetos de datos que no cumplan con el mismo comportamiento que los objetos de su misma clase presenten. Estos objetos de datos son anormales. La mayoría de los métodos de minería de datos descartan este tipo de objetos o lo consideran ruido o excepciones. Sin embargo, en algunas aplicaciones como detección de fraudes, los eventos excepcionales pueden ser más interesantes que las demás ocurrencias con comportamientos normales. Ejemplo de este tipo de análisis son los que permiten determinar cargos incorrectos en tarjetas de crédito o cambio de preferencias de los clientes con respecto a cierto tipo de productos. Análisis evolutivo. Este tipo de análisis describe y modela regularidades o tendencias para objetos cuyo comportamiento cambia con el tiempo. Por ejemplo un inversionista que vende o compra acciones de una empresa, con base en el análisis de mercado de ciertos productos. La minería de datos no está limitada al análisis de datos almacenado en un data warehouse. Esta permite analizar datos existentes a niveles de granularidad mayores que los datos agregados en un almacén de datos como: datos transaccionales, textuales y multimedia. En este contexto, la minería de datos abarca un espectro mayor que las herramientas OLAP con respecto a la búsqueda y recuperación de datos. 60

74 Pero, en qué tipos de repositorios de datos puede aplicarse la minería de datos? En principio, la minería de datos debe ser aplicable a cualquier tipo de repositorio de datos, así como a datos transitorios como flujos de datos. Ejemplos de lo anterior son: Archivos planos. Bases de datos relacionales. Data warehouses. Bases de datos transaccionales. Sistemas avanzados de bases de datos e información y aplicaciones avanzadas. Con el progreso de la tecnología de bases de datos, diversos tipos de sistemas avanzados están en proceso de desarrollo para hacer frente a nuevas aplicaciones. Estos incluyen: o Bases de datos objeto-relacionales. o Bases de datos temporales, bases de datos de secuencia y bases de datos de series de tiempo. o Base de datos espaciales y espacio temporales. o Bases de datos de texto y bases de datos multimedia. o Bases de datos heterogéneas y legadas. o Data streams. o World Wide Web (www). 61

75 Capitulo 2 La Subsecretaría de Infraestructura de la SCT La Secretaría de Comunicaciones y Transportes es la dependencia del Estado encargada de dotar al país con sistemas de transporte y de comunicaciones. Para lograr su misión, la Secretaría está organizada en Subsecretarias que cuentan con Direcciones Generales encargadas de planear y ejecutar el desarrollo de las obras terrestres y marítimas. Una de sus Subsecretarías es la de Infraestructura, que tiene a su cargo tres Direcciones Generales que, entre otras funciones, dan seguimiento a la ejecución de las obras para la construcción y conservación de la Red Nacional de Carreteras. Estas son la Dirección General de Carreteras, la Dirección General de Conservación de Carreteras y la Dirección General de Servicios Técnicos (ver fig. 2.1). Figura 2.1 Organigrama de la Secretaría de Comunicaciones y Transportes (Manual de organización de la Subsecretaría de Infraestructura de la SCT) 62

76 En este capítulo se habla brevemente sobre las actividades que desarrolla la Subsecretaría de Infraestructura de la SCT. Qué herramientas se utilizan para tomar decisiones en materia de infraestructura carretera y cuál es la razón de implementar un SIE para su uso por las Direcciones Generales que conforman esa Subsecretaría. 2.1 La Subsecretaría de Infraestructura 38 Misión La Subsecretaría de Infraestructura es el área de la SCT encargada de preservar la red carretera federal, así como de propiciar el desarrollo de una infraestructura carretera moderna, segura y de calidad para aumentar la competitividad de la economía, impulsar el desarrollo nacional y regional, extender la comunicación y eliminar el aislamiento de las comunidades rurales a través de la correcta y eficaz aplicación de los recursos presupuestales y de esquemas de asociación público privada para el financiamiento de esta infraestructura, con objeto de prestar un mejor servicio al usuario de las carreteras del país. Visión Ser una Subsecretaría eficaz que permanentemente asegure la conservación, expansión, modernización, operación y administración de la infraestructura carretera federal, desarrollando nuevas fuentes de recursos, utilizando óptimamente los recursos disponibles, preservando el medio ambiente y ofreciendo en todo momento seguridad, accesibilidad e información al usuario del sistema carretero nacional. Objetivos de la Subsecretaría de Infraestructura Ampliar la cobertura del sistema y la oferta de una infraestructura carretera confiable y de calidad para toda la población. Abatir el costo económico y social del transporte carretero y contribuir a reducir el costo de sus externalidades. Impulsar el papel del sistema carretero como generador de oportunidades y empleos. Modernizar la gestión del sistema carretero con objeto de lograr una operación más eficiente e incrementar la calidad de los servicios que se ofrecen en las carreteras del país. 38 Subsecretaría de Infraestructura. (Febrero de 2009). Manual de Organización. D. F., México. 63

77 2.2 La Dirección General de Carreteras (DGC) 39 Misión Integrar las distintas regiones que conforman nuestra nación, modernizando la red carretera federal, alimentadora y rural, a fin de proporcionar mayor seguridad en el transporte de personas y bienes. Así como abatir costos de operación, para contribuir al bienestar y al crecimiento económico del país, en forma armónica y sustentable preservando el medio ambiente y la riqueza arqueológica heredada de nuestros ancestros. Visión Ser una unidad normativa que se distinga por su eficiencia en el proyecto, programación, administración y ampliación de altas especificaciones, así como la construcción, reconstrucción y conservación de caminos alimentadores y rurales cuya aportación al sistema de transporte carretera garantice el movimiento rápido, económico y seguro que el desarrollo del país demanda. Por otro lado, la Dirección General de Carreteras (DGC) tiene, entre otras atribuciones, participar en la planeación, coordinación y evaluación de los programas carreteros para la construcción y modernización de la red federal de carreteras, así como para la construcción, modernización, reconstrucción y conservación de caminos rurales y alimentadores. Objetivos de la DGC Continuar construyendo la integración territorial del país. Modernizar los corredores carreteros. Mejorar la red básica de la construcción de libramientos y accesos a ciudades. Impulsar los puntos de conexión con los modos de transporte. Transformar los recursos financieros en kilómetros operativos en el menor tiempo posible. Colaborar para la obtención de fuentes de financiamiento al participar en el ámbito de su competencia, en la planeación en materia de caminos alimentadores y rurales, así como el seguimiento, control y evaluación del desarrollo y ejecución de los programas de construcción, reconstrucción y conservación de los mismos. 39 Dirección General de Carrreteras Federales. (Agosto de 2007). Manual de Organización de la Dirección General de Carreteras Federales. D. F., México. 64

78 2.3 La Dirección General de Conservación de Carreteras (DGCC) 40 Misión Unidad administrativa de la Secretaría de Comunicaciones y Transportes, encargada de conservar y mejorar las condiciones físicas de las carreteras federales libres de peaje, a través de obras públicas realizadas en tramos y puentes, para brindar a los usuarios una mayor seguridad, económica y un mejor nivel de servicio. Visión Ser un ente público que proporcione al usuario una red federal de carreteras libres de peaje en buenas condiciones y con altos estándares de servicio y seguridad, que coadyuven a una mejor competitividad del transporte, así como al desarrollo social y económico del país, por medio de trabajos de calidad, eficacia y eficiencia, realizados con ética y responsabilidad. Objetivos de la DGCC Abatir el costo económico, social y ambiental del transporte asociado con el estado físico de la infraestructura carretera, en beneficio de toda la población y la seguridad del tránsito vehicular. 2.4 La Dirección General de Servicios Técnicos (DGST) 41 Misión Brindar apoyo técnico integral y multidisciplinario para la planeación, estudio, diseño, proyecto, construcción, conservación y operación de la red nacional de carreteras, mediante la más avanzada tecnología disponible. Visión Ser un grupo de profesionales y técnicos altamente capacitados, equipados con los instrumentos más modernos y organizados territorialmente para atender las solicitudes de las Unidades Administrativas receptoras. 40 Dirección General de Conservación de Carreteras. (Febrero de 2009). Manual de Organización. D. F., México. 41 Dirección General de Servicios Técnicos. (Noviembre de 2008). Manual de Organización. D. F., México. 65

79 Objetivos de la DGST Revisar y elaborar normas, manuales, reglamentos o cualquier otro medio escrito que indique reglas o metodologías a seguir o a las que deben ajustarse los actos u operaciones para la buena ejecución de las obras viales, en materia de proyectos constructivos y de conservación de la infraestructura del transporte. Contar con instrumentos para la aplicación de los principios básicos de ingeniería, transparentando los procesos de contratación para la ejecución de las obras y sus servicios relacionados, enfocados al desarrollo de la infraestructura para el transporte, a través de normalizar sus etapas con mecanismos confiables que vigilen su implementación y desarrollo. Proporcionar el apoyo administrativo en Capacitación, Recursos Humanos, Materiales, Financieros e Informático, con oportunidad mediante la aplicación de la Normatividad vigente, para coadyuvar en el cumplimiento de las labores sustantivas encomendadas a la Dirección General de Servicios Técnicos. Por otra parte, se encuentra la Dirección General de Programación, Organización y Presupuesto (DGPOP), la cual depende de Oficialía Mayor y tiene entre sus atribuciones la de llevar el análisis, control y seguimiento del ejercicio de presupuesto autorizado, así como informar a las unidades administrativas respecto de su avance 42. Por lo que las tres Direcciones Generales mencionadas anteriormente, deben estar coordinadas con la DGPOP para ejercer sus presupuestos a tiempo y en forma. Estas son las áreas en las que se analizarán los requerimientos de información de su personal, a fin de definir un modelo de datos idóneo que satisfaga sus necesidades de información y entonces desarrollar un Sistema de Información Ejecutivo que sea el único medio de consulta a niveles estratégicos de la Secretaría y que sea útil para la toma de decisiones. 2.5 Información a analizar en las áreas involucradas Una parte importante del análisis de requerimientos será determinar si el personal cuenta con información financiera suficiente y precisa que realmente les ayude a tomar una decisión a tiempo. 42 Dirección General de Programación, Organización y Presupuesto. (24 de Mayo de 2007). Manual de Organización de la Dirección General de Programación, Organización y Presupuesto. D. F., México. 66

80 En toda organización, pública o privada, la administración del presupuesto es una actividad prioritaria para el logro de los objetivos. Y tanto para la Secretaría de Comunicaciones y Transportes como para todas las instituciones públicas, se trata de un aspecto muy importante, debido a la Ley de Transparencia y Acceso a la Información que tiene por objetivo garantizar a la ciudadanía el uso adecuado de los recursos públicos. En los últimos años, el presupuesto asignado a la SCT en gasto de inversión para la construcción y conservación de carreteras federales, se ha incrementando considerablemente. En el 2009 el presupuesto asignado fue de 50 mil millones de pesos. Lo que representa un aumento del 25% con respecto al del año 2008 que fue de 40 mil millones de pesos. Esto ha originado la necesidad de dotar a la Secretaría con herramientas de software que faciliten no solo la operación del presupuesto asignado, también su control y seguimiento por el personal de los niveles estratégicos de la dependencia, como son: la oficina del Secretario, el personal de la Subsecretaría de Infraestructura y sus direcciones generales y la Dirección General de Programación, Organización y Presupuesto (DGPOP). Este tipo de presupuesto (presupuesto de gasto de inversión) es ejercido por las unidades administrativas representativas de la Secretaría en los Estados, conocidas como Centros SCT y que tienen entre otras de sus funciones la construcción, modernización y conservación de infraestructura carretera, aeroportuaria, portuaria y de comunicaciones del país. Por otro lado, la SCT ha operado desde el año de 1992 con sistemas de información basados en tecnología cliente-servidor, utilizando Progress como motor de base de datos. Progress es una base de datos de cuarta generación (4GL), que permite generar de forma muy rápida, acceso a la información almacenada. Sin embargo y a pesar de contar con sistemas de información que automatizan en gran medida la administración de las obras de infraestructura carretera y que permiten a las áreas usuarias ejecutar en forma precisa el presupuesto asignado, el personal de la Subsecretaria de Infraestructura y de sus áreas normativas, no cuentan con las herramientas de software adecuadas que les permitan conocer de manera rápida y oportuna la situación de las obras carreteras a nivel nacional y controlar aspectos como avance físico, avance financiero, gestión de los contratos asignados, proveedores contratados, presupuestos asignados, entre otros. El ciclo de vida de una obra involucra diferentes procesos, Asignación de un presupuesto original a cada programa que sufre modificaciones a lo largo del año. 67

81 Una vez que la Unidad donante conoce el presupuesto que tiene asignado distribuye estos montos a los diferentes proyectos y obras, que son licitados. Una vez efectuada la licitación, se comprometen los montos mediante contratos. Durante la obra, el contratista entrega reportes periódicos de avance de obra, y se van entregando estos recursos comprometidos conforme al avance reportado, los recursos entregados se denominan recursos ejercidos. El diagrama de la figura 2.2, muestra el proceso antes descrito. En términos generales se desea conocer la situación del flujo de recursos y del avance de obra, a lo largo de todo el ciclo de obra y de la asignación de recursos a la Secretaría, desglosado por Centro SCT, Unidad Donante, operaciones mensuales y en el caso del ejercido a nivel diario, por fuente de financiamiento (Recursos fiscales o Crédito externo), por programa operativo y programa presupuestal y por proyecto de obra. Es importante mencionar que en la actualidad las empresas tanto públicas como privadas, enfrentan el problema del explosivo crecimiento de datos que producen. Un nuevo reto que no se limita a la gestión de una, cada vez mayor, base de datos. Sino que ahora también es preciso gestionar los datos de manera que ayuden a los ejecutivos de una organización a tomar decisiones de manera rápida con base en la información almacenada. Figura 2.2. Proceso de ejercicio del presupuesto en obra pública (diseño propio) Para las empresas, esa información puede llegar a representar la inversión de muchos recursos, tanto financieros como humanos, durante años. Pero el problema ya no es el almacenamiento de esa información. En la actualidad, el problema se ha convertido en buscar la manera de utilizar esos datos, para aprovecharlos como un recurso estratégico de las organizaciones. En esos datos se encuentran contenidas tendencias de costos, información de proveedores, necesidades de inversión, estados financieros de la organización, necesidades de 68

82 la población, etc. Pero para descubrirla y obtener únicamente la información más importante, es necesario analizar esos datos e interpretarlos. Hoy en día, se habla de un nuevo término que más que un concepto es un conjunto de tecnologías de análisis de datos para obtener la información estratégica que las organizaciones necesitan: inteligencia de negocios (business intelligence). La inteligencia de negocios se refiere a un análisis de alta tecnología de los datos corporativos con el fin de tomar mejores decisiones estratégicas. También conocida como minería de datos, la inteligencia de negocios implica buscar y analizar datos provenientes de múltiples fuentes ubicadas en toda la empresa, y algunas veces derivados de fuentes externas, a fin de identificar patrones y relaciones que pueden ser importantes. 43 No se trata de una idea nueva. Ya hace algunos años, se hablaba de los Sistemas de Información Ejecutivos (SIE) o de los Sistemas de Información de Soporte a las Decisiones (SSD). Sistemas cuyo propósito era llevar información a los niveles gerenciales de la organización para tomar decisiones más rápidas y eficaces. Sin embargo, las tecnologías que se han desarrollado en inteligencia de negocios, han propiciado mayores avances y mejores resultados. Lo que se pretende lograr con el presente trabajo es desarrollar un Sistema de Información Ejecutivo (SIE), que le proporcione al personal de las áreas objeto de estudio la información que necesitan día a día. En una empresa pública, contar con información oportuna y precisa puede representar cumplir en tiempo y forma con los objetivos y metas trazados con el mayor aprovechamiento de los recursos disponibles. Tener información que le permita a la alta dirección saber cómo se ejerce el presupuesto a nivel nacional y en qué se están gastando los recursos, puede ser parámetros estratégicos para tomar decisiones. Es precisamente en la administración de datos como la inteligencia de negocios puede ayudar a la Secretaría de Comunicaciones y Transportes. La inteligencia de negocios se basa en la integración de datos históricos y actuales para determinar tendencias y proponer posibles escenarios. Esto es posible cuando se les proporciona a los usuarios que toman decisiones, la información suficiente y oportuna para su análisis. Y en este sentido, es lógico que las decisiones deban estar basadas en datos precisos. Como sabemos, los datos por si mismos no nos 43 Daft, R. (2007). Teoría y diseño organizacional. México: Cengage Learning. p

83 dicen nada. Pero dependiendo del contexto en donde se encuentren y de la correcta integración de los mismos, los datos van a permitir al ejecutivo tomar decisiones más rápidas y eficaces. Contar con la información suficiente, permite a una organización además de mejorar las prácticas de trabajo existentes, preservar el conocimiento como una memoria organizacional para capacitar a los futuros empleados o para ayudarlos en la toma de decisiones. La memoria organizacional es el aprendizaje almacenado de la historia de una organización que se puede aprovechar para la toma de decisiones y para otros propósitos Laudon, K. (2004). Sistemas de información gerencial: Administración de la empresa digital. México: Prentice Hall. p

84 Capitulo 3 Diseño y desarrollo de la propuesta de solución En los últimos años, el presupuesto asignado a la SCT en gasto de inversión para la construcción y mantenimiento de carreteras, se ha incrementando considerablemente. En el 2009 el presupuesto asignado fue de 50 mil millones de pesos. Lo cual representa un aumento del 25% con respecto al del año 2008 que fue de 40 mil millones de pesos. Esto ha originado la necesidad de dotar a la Secretaría con herramientas de software que faciliten no solo la operación del presupuesto asignado, sino su control y seguimiento por los niveles estratégicos. Sin embargo y a pesar de contar con sistemas de información que automatizan en gran medida la administración de las obras de infraestructura carretera y que permiten a las áreas usuarias ejecutar en forma precisa y oportuna el presupuesto asignado, los Subsecretarios y áreas normativas de la dependencia, necesitan herramientas de software que les permita conocer en forma rápida datos puntuales como avances físicos, avances financieros, gestión de los contratos asignados, proveedores contratados, presupuestos asignados, entre otros. Por lo tanto, proporcionar una herramienta de software a las áreas estratégicas de la Secretaría, que cubra los requerimientos de información necesarios para tomar decisiones, es un proyecto que puede propiciar un mejor aprovechamiento de los recursos disponibles y una mayor transparencia en el uso de los mismos, dos aspectos que por su importancia pueden resultar de gran impacto para los diferentes niveles ejecutivos de la dependencia. En este capítulo se habla sobre el diseño y desarrollo del Sistema de Información Ejecutivo para la SCT, que busca satisfacer la necesidad de información arriba descrita. Se hace una breve descripción del problema a solucionar, se menciona el objetivo general y los objetivos específicos y se describe la metodología de investigación utilizada. También se mencionan cuáles fueron las necesidades de los usuarios que dieron origen al proyecto y se realiza un análisis de los requerimientos de información que se detectaron durante el desarrollo de las entrevistas llevadas a cabo con el personal de mando de la Dirección General de Conservación de Carreteras (DGCC), de la Dirección General de Carreteras (DGC) y de la Dirección General de Servicios Técnicos (DGST). Las cuales son tres Direcciones de la Subsecretaría de Infraestructura encargadas del seguimiento a la construcción y conservación de las carreteras federales del país. 71

85 Se habla también sobre la descripción funcional del Sistema de Información Ejecutivo y se presenta el diseño de la base de datos o data mart de la aplicación, así como la estructura dimensional con la cual se implementó. Por último, el desarrollo de interfaces de usuario también se describe en este capítulo. Es importante mencionar que algunas de estas interfaces muestran los indicadores de control que los usuarios necesitan visualizar constantemente y que les sirven para detectar problemas en el ejercicio del presupuesto destinado a la inversión en carreteras. 3.1 Planteamiento del problema La enorme cantidad de información que manejan los sistemas transaccionales u operacionales y que se almacena en bases de datos relacionales, no se está aprovechando al máximo en la toma de decisiones a niveles estratégicos de la Secretaría de Comunicaciones y Transportes. La normatividad vigente y los sistemas transaccionales en operación (mismos que están diseñados en apego a la normatividad), establecen los mecanismos de control necesarios para evitar un mal manejo de los recursos disponibles. La información viaja desde los niveles operativos hasta los niveles tácticos y estratégicos de la dependencia a través de los canales de comunicación establecidos. Pero hoy en día, los Directores Generales, requieren de herramientas ágiles que les permita visualizar, en forma clara y oportuna, métricas y parámetros de control con base en los cuales puedan tomar decisiones rápidamente. La preocupación principal se centra en la necesidad de contar con información oportuna disponible sobre la inversión en infraestructura. Por lo tanto, se tiene la necesidad de desarrollar una herramienta de software para los niveles estratégicos de la Secretaría de Comunicaciones y Transportes, que les proporcione información suficiente y oportuna para tomar decisiones con respecto a las obras que se desarrollan en los estados de la República Mexicana, para conocer de manera precisa y en cualquier momento el avance físico y financiero por obra, los recursos presupuestales asignados y ejercidos en cada proyecto, los contratos autorizados y la disponibilidad presupuestal periódica. Particularmente en infraestructura carretera ya que representa más del 70% del presupuesto asignado para este año. Actualmente, los sistemas de información institucionales proporcionan datos útiles y confiables para la operación cotidiana de la dependencia. Esto involucra a los niveles táctico y operativo. Sin embargo, en muchas ocasiones el personal de las áreas estratégicas de la Secretaria, debe solicitar información a diversas áreas y 72

86 después de ello, un grupo de personas integra toda esa información y la ordena para presentar los informes ejecutivos necesarios para la oficina del Secretario y para la Subsecretaria de Infraestructura. Esto último también suele ser un proceso lento y complicado porque se deben unificar criterios e ideas para tomar la decisión más acertada en materia de obra pública. En resumen, el requerimiento de información que se presenta, responde a la necesidad de conocer en forma rápida y precisa el presupuesto asignado, el compromiso de pago con los proveedores y la manera en la que se ha ejercido el presupuesto en infraestructura carretera en las unidades centrales y estados o Centros SCT, como se les llama a las oficinas representativas de la Secretaría en los estados. 3.2 Objetivos de este proyecto Para definir el objetivo general, es necesario responder primero a la pregunta será posible construir una herramienta de software que consolide la información física y financiera de la construcción y conservación de carreteras nacionales y que sea lo suficientemente flexible para mostrar las métricas y parámetros de control necesarios para la toma de decisiones? Objetivo general. El objetivo general de este trabajo es desarrollar una herramienta de software usando tecnología de inteligencia de negocios, enfocada a la gestión de información en el rubro de gasto de inversión en infraestructura carretera, que cuente con las características de confiabilidad y oportunidad bajo los estándares tecnológicos adoptados por la Secretaría de Comunicaciones y Transportes, para el apoyo a la toma de decisiones en los niveles estratégicos de la Secretaría. El software a desarrollar será el Sistema de Información Ejecutivo de Infraestructura. Objetivos específicos. Los objetivos específicos de este proyecto son los siguientes: Identificar la información y las fuentes de datos que utiliza el personal de las áreas de infraestructura para el monitoreo de las obras carreteras. Desarrollar una base de datos para la consolidación de la información a nivel nacional. 73

87 Desarrollar interfaces gráficas que muestren los parámetros de control que los usuarios requieran para evaluar el desarrollo de la infraestructura carretera en el país. Desarrollar reportes personalizables que los usuarios utilicen para la elaboración de sus informes ejecutivos. 3.3 Metodología utilizada En esta investigación se utilizó el método analítico para comprender la manera en la que las áreas objeto de estudio, utilizan la información a su alcance para tomar decisiones cotidianas en materia de infraestructura carretera. Con base en este estudio, se determinó cuáles eran los requerimientos de información que podían ser sistematizados utilizando tecnología de inteligencia de negocios y con base en ello, se desarrolló una propuesta de solución cuyo objetivo es proporcionar información en forma rápida y precisa, al personal de las áreas usuarias. Esta metodología permitió conocer también la naturaleza de la información que se produce al interior de las áreas de estudio, la manera en que es transmitida hacia los niveles estratégicos de la Secretaría y cuál es el uso que se le da. Por otro lado, se utilizó también una metodología que en desarrollo de software se conoce como método espiral. Este método hace énfasis en la velocidad y la culminación, tomando en cuenta que los requerimientos no se pueden identificar con claridad o especificar al inicio. Este método se presta principalmente al desarrollo de aplicaciones de base de datos, al desarrollo de un data warehouse y al desarrollo de sistemas orientados a objetos (sistemas OO) 45. En el desarrollo de productos de software, el método de desarrollo espiral se utiliza cuando surgen las siguientes situaciones: No se pueden predecir con claridad ni anticipación la dirección de un mercado y sus requerimientos. El tiempo de colocación en el mercado es un ingrediente importante en la implementación de un producto. Es necesaria una mejora iterativa para hacer correcciones de mercado. 45 Gill, H. S. (1996). Data warehousing La integración de la información para la mejor toma de decisiones. México, D. F.: Prentice Hall. p

88 La ventaja competitiva sostenida proviene de una mejora súbita en forma continua. A la organización le toma por lo menos seis meses absorber las versiones sucesivas de software. 3.4 Análisis FODA de la solución En la figura 3.1, se puede ver el análisis FODA realizado para la implementación del SIE en la SCT. Es importante resaltar que a pesar de las amenazas que existen para realizar la implementación, las oportunidades de mejora son más importantes para las áreas usuarias, ya que la herramienta les proporcionará más información para tomar mejores decisiones. Las debilidades existentes serán subsanadas por el desarrollo de esta solución, aprovechando las fortalezas que un software de este tipo puede tener. 3.5 Diseño lógico del Sistema de Información Ejecutivo de Infraestructura El diseño lógico del SIE contempla los aspectos conceptuales de la aplicación. Se realiza un análisis de requerimientos, se plantea la descripción funcional del Sistema y se describen brevemente los procesos sobre los que operará Requerimientos de información Derivado de las entrevistas realizadas al personal que labora en las áreas de la Subsecretaría de Infraestructura, se detectaron las siguientes necesidades de información. 1. Contar con una única fuente de información financiera. La integración de datos deberá ser mucho más sencilla y rápida. La integración de la información financiera entre las diferentes áreas se realiza en forma periódica y puede ser mensual, trimestral, semestral y anual. Anualmente, a cada unidad administrativa de la Secretaría se le asigna un presupuesto, el cual ejerce de manera independiente y es responsable de su gasto. Sin embargo, la DGPOP en coordinación con las Direcciones Generales de la SCT, analizan los estados financieros en forma periódica con el fin de encontrar tendencias, determinar áreas de oportunidad, redistribuir gastos y en general, verificar si lo que se planeó al inicio de un ejercicio es congruente contra la ejecución de las actividades financieras de las unidades. 75

89 Al tener fuentes de información distintas, es complicado determinar una sola verdad de los datos y por lo tanto, el tiempo que tarda la DGPOP en consolidar la información de toda la Secretaría, generalmente es de un par de semanas. 2. Reducir los tiempos de respuesta para que los usuarios de la alta gerencia de la organización, cuenten con reportes confiables de los movimientos del presupuesto cuando ellos los necesiten. La línea de mando en la organización de la Secretaría es jerárquica, por lo que cuando el Director General de una unidad requiere reportes financieros, esta solicitud debe pasar por lo menos por tres niveles hacia abajo (Directores de Área, Subdirectores y Jefes de Departamento) hasta llegar a los niveles operativos donde se encuentran los usuarios de los sistemas transaccionales quienes elaboran o imprimen los estados financieros de los sistemas transaccionales disponibles. Esta solicitud puede tardar desde un par de horas hasta algunos días de acuerdo a las cargas de trabajo y disponibilidad del personal para atender el requerimiento. El inconveniente con esta situación es que cuando los Directores Generales de las diferentes áreas, quienes son los responsables de guiar las actividades de la Secretaría, necesitan información confiable para tomar una decisión y no cuentan con ésta en el momento en el que se necesita, se pueden originar diferentes problemas como atrasos en la ejecución de obras públicas, selección de proveedores de servicios, atención a necesidades de operación de la Secretaría, responder de manera inmediata a necesidades de información de otras dependencias públicas y privadas o simplemente, no contar a tiempo con los datos necesarios para la planeación de actividades en la ejecución de un trabajo, entre otros. Para resolver esta situación, es necesario controlar la información financiera, por medio de herramientas confiables, a los niveles ejecutivos de la Secretaría, con el fin de que dispongan de todos los datos necesarios para la toma de decisiones en el momento en el que los requieran. 76

90 Tabla 3.1 Análisis FODA para la implementación del SIE (diseño propio) 1. Adquisición de nuevas tecnologías y herramientas. 2. Integración de sistemas departamentales. 3. Renovación tecnológica. 4. Enfoque al análisis para una mejor toma de decisiones. Fortalezas (F) 1. Integración de sistemas institucionales. 2. Alta disponibilidad de la información. 3. Orientado a la toma de decisiones alineado a la estrategia de negocio. 4. Consolidar la información de diversas fuentes. F1-O2. Por políticas tecnológicas de la Unidad de Tecnologías de la Información de la SCT, todo desarrollo de Sistemas de cualquier área deberá tener un data mart para la explotación de la información. F2-O1. Las áreas usuarias requieren consultar su información en cualquier momento y desde cualquier lugar. La adquisición de tecnología de BI incluye componentes que ayudan a satisfacer esta necesidad. F3-O4. El SIE a desarrollar busca satisfacer la necesidad de información que los niveles ejecutivos de la SCT requieren. F4-O2. El uso de la plataforma tecnológica sobre la que se desarrollará el SIE, permite integrar datos de diversas fuentes para proporcionar al usuario una única fuente de información. Esto ayudará a que la información de diferentes áreas se consolide en una única herramienta para su consulta por las áreas estratégicas. Debilidades (D) 1. Poca integración de sistemas internos y externos. 2. Re-análisis de modelos de datos, objetos, transacciones, almacenamiento. 3. Diseño complejo y multidisciplinar. 4. Se requieren sistemas, aplicaciones y almacenamiento específico. D1-O2. Aunque no se genere una integración directa entre las aplicaciones institucionales, la información de todas las áreas se consolida en una sola base de datos. D2-O3. El desarrollo de la solución implicará analizar nuevamente la documentación generada en el construcción de los sistemas actuales. Pero esto permitirá desarrollar nuevas herramientas de explotación de información y con ello renovar la infraestructura tecnológica disponible al interior de la Secretaría, para la toma de decisiones. D3-O4. El diseño de la solución implica coordinar empleados de diferentes áreas de la Secretaría para generar un diseño complejo de Sistema, que satisfaga los requerimientos de información de todos. Sin embargo, una vez terminada la aplicación, se contará con una única fuente de información y una mejor herramienta para la toma de decisiones. D4-O1. La construcción de sistemas basados en tecnología de BI, requiere que existan las fuentes de información transaccionales o que la información esté almacenada en un data warehouse. Pero esto se puede convertir en una oportunidad para automatizar todas las áreas de la organización y hacerlas más eficientes. 1. Costos crecientes. 2. Cambios constantes en los criterios de gestión de la organización. F1-A1. El desarrollo de la solución permitirá integrar la información de diferentes áreas en una única fuente de información. Sin embargo, es probable que se requieran técnicos calificados que conozcan la nueva tecnología sobre la que se hará el desarrollo. También se va a necesitar infraestructura de almacenamiento y procesamiento adecuados para ejecutar la solución. F3-A2. Cambios constantes en los criterios de gestión de la organización, pueden provocar la modificación a la regla de negocio en las fuentes de datos. Y con ello, la modificación de los criterios de consolidación de información en el SIE. F4-A1. La consolidación de la información de diversas fuentes implica que para cualquier nuevo desarrollo de sistemas, también se construya una solución similar. Esto puede provocar desarrollos más caros y con más recursos. D1-A2. Cambios constantes en la manera en la que se gestiona la construcción y conservación de carreteras, puede provocar una mayor desintegración entre los sistemas internos. Afortunadamente, la normatividad aplicable no cambia tan frecuentemente. D2-A1. Analizar los desarrollos de software ya implementados en su momento para implementar una solución sobre una herramienta de BI, implica el uso de recursos y la adquisición de nueva tecnología. Esto provocará mayores costos. Sin embargo, es una inversión que producirá beneficios al reducir tiempos en la supervisión de las obras de infraestructura carretera del país. D3-A2. El desarrollo de una solución sobre herramientas OLAP no es algo sencillo que se pueda modificar en cualquier momento. Se trata de desarrollos de software con herramientas complejas y poco flexibles. Por lo tanto, cambios en la regla de negocio de las fuentes de información o errores en el diseño de la solución, puede provocar el uso de recursos alternos y costos de mantenimiento no contemplados. D4-A1. Es necesario que existan las fuentes de datos si se quiere implementar una solución de BI. Pero si estas no existen, entonces se tendrán que construir, lo cual puede provocar costos no contemplados.

91 3. Promover la sistematización total del negocio en las áreas financieras con el fin de que las posibles fuentes de datos que no existan, se construyan con el objetivo de que el data mart integre la información necesaria para un mejor aprovechamiento del mismo. Puede ser necesario desarrollar sistemas que ayuden a registrar toda aquella información financiera que actualmente no esté sistematizada pero que se deba integrar al data mart. Por esta razón, al momento de determinar las posibles fuentes de datos de la solución, será necesario analizar detenidamente las fuentes oficiales existentes y su capacidad para procesar y entregar datos correctos y poner a valoración de la alta gerencia, la construcción de los sistemas de información necesarios para el registro de información financiera. 4. Integrar la información del ejercicio del presupuesto de las diferentes áreas en forma rápida y sin depender de la operación de las áreas administrativas de la Secretaría. La información que se entrega a otras dependencias públicas como la Secretaría de Hacienda, son los estados consolidados de toda la operación financiera que se realizó en la Secretaría en un determinado periodo de tiempo. La integración de esos estados financieros debe provenir de una única fuente de información y su generación debe ser casi inmediata sin necesidad de validar con los responsables de las áreas financieras, que la información que se reporte sea la ejecutada realmente. Es decir, la herramienta que se elabore debe garantizar la integridad de la información con el fin de evitar lo más posible la intervención de los responsables que la generaron. De esta manera se pretende liberar a los Directores Generales de tiempo muy valioso que pueden dedicar al desarrollo de las actividades sustantivas de sus áreas, en lugar de dedicar tiempo de revisión de los estados financieros para realizar una validación de datos contra los de la DGPOP. 5. Integrar información financiera para establecer parámetros de control y seguimiento con la información de otras áreas como Recursos Humanos, Recursos Materiales y Contabilidad. Una de las ventajas del uso de aplicaciones para la inteligencia de negocios es precisamente el poder definir parámetros de medición y darles un seguimiento a través del SIE. Por esta razón, es necesario que la solución propuesta permita dar seguimiento a los siguientes parámetros: 78

92 Presupuesto ejercido contra presupuesto comprometido por contrato. Presupuesto ejercido por unidad administrativa. Disponibilidad presupuestal contra presupuesto ejercido por mes. Ejercicio del presupuesto por proveedor. 6. Integrar información histórica de la operación anual de la Secretaría. La información histórica de la Secretaría permite evaluar cuales fueron los resultados obtenidos por ejercicio fiscal en comparación con el presupuesto asignado. También deberá permitir dar seguimiento a parámetros como: Presupuesto asignado contra presupuesto ejercido en obras multi anuales. Comparación de proveedores participantes en contratos multi anuales. Comparativo del presupuesto asignado, modificado y ejercido entre ejercicios fiscales. 7. Conocer en cualquier momento, la posición actual de la organización con respecto a proveedores de servicios, presupuestos, proyectos nuevos y proyectos concluidos. El seguimiento a los proveedores es otra de las preocupaciones de la alta gerencia de la Secretaría. Identificar en cualquier momento los proveedores y los proyectos en los que participan a nivel nacional tiene como objetivo poder evaluar el avance de las actividades, el presupuesto asignado y el ejercido. 8. Simplificar la consolidación de la información de todas las unidades administrativas de la Secretaría, así como la generación de la amplia variedad de reportes que se necesitan elaborar Análisis de requerimientos Qué problema empresarial se resolverá con la construcción del data mart y con la implementación del SIE? De hecho, existen diversos problemas que se resolverán con la implementación de la solución. A grandes rasgos son: 79

93 No contar con información oportuna para la mejor toma de decisiones. El sistema deberá integrar la información de los movimientos del presupuesto de manera rápida y concisa. Que permita identificar y analizar claramente parámetros de medición que son básicos para determinar el presupuesto para un proyecto, la asignación o movimiento de presupuesto de una unidad a otra o las posibilidades de reducir o ampliar el presupuesto de acuerdo al ejercicio del mismo por unidad administrativa. Tener que buscar la conciliación de las unidades administrativas de la Secretaría para llegar a un reporte único del estado del ejercicio y otros documentos presupuestales. El sistema deberá permitir consolidar la información de todas las fuentes institucionales que contengan datos para la medición del ejercicio del presupuesto sin necesidad de tener que buscar el acuerdo entre todas las áreas. Actualmente, cada unidad administrativa utiliza diversos programas de software con los cuales llevan el control de su presupuesto. Algunos de estos programas son el Sistema Integral de Administración, el Sistema de Contabilidad, el Sistema para el Registro y Seguimiento para la Construcción de Carreteras, el Sistema de Recursos Humanos y el Sistema de Recursos Materiales. Todas estas aplicaciones contienen información oficial sobre los movimientos presupuestales por cada capítulo de gasto (forma en que se controla el presupuesto dentro del gobierno federal). Al contar con fuentes diversas y distribuidas por diferentes áreas administrativas tanto normativas como operativas, se presenta el problema de tener que solicitar que las áreas se pongan de acuerdo en la información que presentan al momento de tener que generar los estados financieros de toda la Secretaría. Actividad que representa un desgaste excesivo en tiempo y recursos, ya que en muchas ocasiones es necesario reunir a los participantes por medio de videoconferencias o en forma presencial en la DGPOP trayendo a los responsables de las operaciones de los estados por varios días, hasta que finalmente se llegue a un acuerdo. No contar con un tablero de control que permita la publicación inmediata de la información que se genera al interior de la Secretaría y que es necesaria para la toma de decisiones a niveles estratégicos de la organización. El sistema deberá servir como base para desplegar un tablero de control que contenga y que actualice la información en línea sobre los diferentes parámetros de medición financiera como la asignación, el ejercicio y la disponibilidad presupuestal por unidad administrativa, entre otros parámetros. 80

94 Cuáles son los objetivos empresariales que ayudará a alcanzar la solución propuesta? La Secretaría de Comunicaciones y Transportes estableció en su Programa Sectorial de Comunicaciones y Transportes las estrategias y las líneas de acción que definirán su desempeño, en cumplimiento con los objetivos del Plan Nacional de Desarrollo (PND) del mismo ciclo. En ese sentido, ha planteado la necesidad de llevar a cabo una verdadera modernización administrativa y mejora de su gestión. Por lo que ha establecido como uno de sus objetivos primordiales, el siguiente: Desarrollar y administrar con políticas de calidad los recursos humanos, financieros, materiales y las tecnologías de la información con el objeto de que la operación de la SCT sea transparente, eficiente y eficaz Por esta razón, se considera que el proyecto, una vez implementado, ayudará a cumplir con ese objetivo, ya que contará con los elementos tecnológicos necesarios que garanticen la transparencia de la información financiera contenida en él. A su vez, será una herramienta que permita medir la eficiencia y la eficacia con la que trabaja la Secretaría en la búsqueda de lograr sus demás objetivos, proporcionando información que retroalimente a los niveles estratégicos de la organización para tomar las decisiones adecuadas, logrando con ello entrar en un ciclo de mejora continua y de calidad. Es importante mencionar que el data mart que se construya, solamente contendrá la información financiera de la Secretaría en gasto de inversión (capítulo de gasto 6000). Se planea que en etapas de desarrollo posteriores, se construyan los data mart necesarios para consolidar la información de las áreas de recursos humanos y de recursos materiales. En la figura 3.1, se presenta un diagrama de contexto en el que se muestra el diseño de la construcción de los diferentes mercados de datos que finalmente integrarán la información de los sistemas administrativos hacia un data warehouse institucional. La consolidación de la información almacenada en el Sistema para la Construcción y Conservación de Carreteras (SIRASEF) y en el Sistema Integral de Administración (SIA), contemplan el alcance del presente trabajo. 81

95 El data mart de infraestructura carretera contendrá información financiera de la Secretaría de Comunicaciones y Transportes referente al capítulo 6000 (gasto de inversión). Figura 3.1. Construcción de los diferentes data mart para la SCT (diseño propio) Descripción funcional del SIE Actualmente, se encuentran en funcionamiento diversos sistemas institucionales que soportan la operación diaria de la Secretaría. Dos de ellos son el Sistema Integral de Administración (SIA) y el Sistema para la Construcción y Conservación de Carreteras (SIRASEF). El SIRASEF es, a grandes rasgos, el sistema mediante el cual se realiza la gestión de todo lo referente al capítulo de gasto En la base de datos de ese sistema se almacena y procesa la información referente a licitaciones de obra pública, el seguimiento de las obras de construcción y conservación de infraestructura carretera y la gestión de pagos. Los dueños normativos del SIRASEF son la Dirección general de Carreteras Federales (DGCF) y la Dirección General de Conservación de Carreteras (DGCC). El dueño tecnológico es la Unidad de Tecnologías de la Información y Comunicaciones (UTIC). Las Direcciones normativas indican a la UTIC las políticas y procedimientos sobre los que deberá operar el SIRASEF. Por otro lado, el SIA es el sistema encargado de controlar las operaciones concernientes al ejercicio del presupuesto de todos los capítulos del gasto (del 1000 al 6000) del presupuesto asignado a la SCT. 82

96 Ambos Sistemas se encuentran en operación desde el año de 1990 y sus bases de datos almacenan una gran cantidad de información. Figura 3.2. Modelo de referencia propuesto para el Sistema de Información Ejecutivo de Infraestructura (diseño propio) El modelo de referencia que se muestra en la figura 3.2., es un bosquejo en el cual se ejemplifica el funcionamiento del Sistema de Información Ejecutivo a desarrollar. Como ya se ha comentado en esta y otras secciones, se utilizarán las bases de datos del SIA y SIRASEF para extraer la información necesaria que se depositará en el data mart de obra pública. La extracción de información de estos sistemas se hará por medio de procesos por lotes (archivos bat) que se conectaran a las fuentes de datos (bases de datos relacionales) y que extraerán la información y la dejarán en archivos planos (archivos de texto). La extracción de información se realizará todos los días a la una de la mañana. Adicional a la extracción de datos y previo a la carga de información al data mart, será necesario transformar la información en la estructura dimensional requerida para el almacenamiento de los datos. Para ello, se elaborarán un conjunto de programas denominados reglas de carga, las cuales prepararán al data mart actualizando sus dimensiones. Una vez preparada la estructura dimensional del data mart, se ejecutará un proceso de carga de los datos extraídos hacia los archivos planos. Técnicamente, la carga de datos se realiza en los miembros de dimensión de nivel cero dentro del 83

97 data mart (nivel inferior dentro de cada dimensión). Por lo que al final de la carga de los datos, se ejecutará un proceso que permitirá consolidar la información a los diferentes niveles del data mart. Después de realizar el proceso de extracción, transformación y consolidación de datos hacia el data mart, el usuario podrá consultar su información por medio de herramientas de reporteo por web y herramientas cliente-servidor. Se proporcionará un conjunto de reportes y tableros con indicadores estratégicos predefinidos por los usuarios que, en la actualidad, integran usando diferentes fuentes de datos. Esto último representa para el usuario un trabajo artesanal, ya que tiene que reunir datos de los sistemas en operación, de sus controles internos, de reportes de otras áreas y de trabajos de campo para preparar informes y otros documentos oficiales. También se le proporcionará al usuario final, una herramienta que le permitirá por medio de Excel, conectarse directamente al data mart para realizar análisis más complejos de información. Con esto se busca combinar el conocimiento que la mayoría de los usuarios tienen sobre el manejo de Excel y el poder que proporciona esta herramienta en el análisis de datos, con las ventajas que tiene contar con un data mart que consolida la información de diversas fuentes de datos Descripción de los procesos desarrollados El desarrollo de un data warehouse o de un data mart, parte del diseño del repositorio de datos, el cual puede ser implementado utilizando una base de datos relacional o un motor de base de datos diseñado específicamente para procesamiento dimensional. Para el desarrollo del data mart de este trabajo, se utilizó una motor de base de datos del segundo tipo. A continuación se detallan los procesos desarrollados para la construcción del data mart de infraestructura, el cual será el repositorio de datos del Sistema de Información Ejecutivo. Almacenamiento dimensional y fuentes de datos Se utilizó el motor de base de datos OLAP (online analytical processing) Oracle Essbase System 9, el cual es una herramienta desarrollada para el análisis financiero basado en la integración de información de múltiples sistemas. Sobre esta plataforma se construyó el data mart que contiene la información física y financiera de la infraestructura carretera, y que es el insumo necesario para la determinación de parámetros, tendencias y excepciones que se pueden presentar 84

98 en la operación cotidiana de la SCT. Información necesaria para la toma de decisiones estratégicas de la organización. Sin embargo, un problema que se presentó para la integración de la información entre el data mart y las fuentes de datos es que esas fuentes están desarrolladas sobre el RDBMS Progress versión 9.1.C. Esta última no tiene una conexión nativa hacia el Oracle Essbase. Por lo cual, se desarrollaron programas de extracción de información para su posterior carga hacia el data mart. Técnicamente es posible establecer una conexión por ODBC entre las dos bases de datos y desarrollar programas en SQL para extraer los datos desde Progress hacia Oracle Essbase. Pero esta actividad se dejó para una segunda etapa con el fin de asegurar primero que el desarrollo del SIE cumpla con las expectativas y con la aceptación del usuario final, antes de invertir mayores recursos y esfuerzo en este proyecto. Extracción de datos Una ventaja que se tuvo en el desarrollo de la tecnología necesaria para conectar las dos bases de datos (Progress y Oracle Essbase), fue que las dos fuentes de datos a utilizar están desarrolladas sobre la misma plataforma de base de datos. Por lo cual, no fue necesario desarrollar diferentes programas de extracción para diferentes ambientes como llega a ocurrir cuando se trata de implementar un data mart. Como se puede apreciar en la figura 3.2., las dos fuentes de datos a utilizar fueron el Sistema Integral de Administración (SIA) y el Sistema para el Seguimiento Físico y Financiero (SIRASEF). Ambas bases de datos desarrolladas sobre Progress. De acuerdo con los requerimientos de información planteados, el tipo de información a extraer de las fuentes de datos se centró en los aspectos siguientes. Información del avance físico al que se comprometió cada proveedor en un contrato. Información del avance físico ejecutado por cada proveedor. Información de las ampliaciones y reducciones a los contratos registrados. Información del presupuesto original, modificado y disponible asignado a la SCT en materia de gasto de inversión. Información de los pagos realizados a los proveedores. Catálogo de programas y proyectos presupuestales. Catálogo de programas operativos. 85

99 Catálogo de corredores carreteros. Catalogo de tipos de contratos. Los programas de extracción fueron desarrollados en un 4GL de Progress ver C. Estos programas extraen la información de las fuentes de datos y la guardan temporalmente en archivos planos o archivos de texto como registros con campos delimitados por el símbolo pipe ( ), para que posteriormente mediante programas llamados reglas de carga en Oracle Hyperion Essbase, transformen e integren la información en el data mart. En la figura 3.3 se muestra la sección de exportación de datos de uno de los programas de extracción utilizados para obtener información de las fuentes de datos. Cada una de las líneas exporta un dato hacia un archivo de texto. En este ejemplo, cada línea de código representa lo siguiente: 1. El comando EXPORT extrae los datos especificados en las líneas 2 a la 17 y los envía a un archivo de texto. Los campos exportados se describen a continuación. 2. Año al que corresponde la obra. 3. Clave del programa de obra 4. Proyecto de presupuesto con el que se hizo el pago del contrato. 5. Número de la obra exportada. 6. Símbolo utilizado para omitir campo en regla de carga durante la integración de datos posterior. 7. Número del contrato de obra. 8. Fuente de financiamiento utilizada. 9. Unidad administrativa donante del presupuesto. 10. Unidad administrativa responsable del ejercicio del presupuesto. 11. Programa de presupuesto. 12. Etiqueta que representa la métrica a la cual corresponde el dato que se va a importar al data mart. 13. Año en el que se realizó el pago del contrato exportado. 14. Mes en el que se realizó el pago del contrato exportado. 15. Día en el que se realizó el pago del contrato exportado. 16. Importe del pago realizado. 17. Actividad institucional con el que se hizo el pago del contrato. 18. Esta línea indica el fin del proceso de exportación. Una vez que este programa de extracción de información es ejecutado, genera un archivo de texto con los datos indicados arriba. En la figura 3.4 se muestra una parte del archivo generado después de la corrida del programa. 86

100 Figura 3.3 Sección de exportación de datos de uno de los programas utilizados para extraer datos desde las fuentes de datos para el data mart construido (diseño propio) En la figura 3.4, se podrá observar que no existe una relación aparente entre los datos e incluso puede parecer que no tienen significado alguno respecto a un cubo de información. Sin embargo, en la sección integración y transformación que se encuentra más adelante, se le dará sentido a los datos contenidos en este archivo con respecto al data mart que se va a construir, mediante las denominadas reglas de carga. Figura 3.4 Muestra de los datos extraídos por la sección del programa de la figura 3.3, después de la ejecución del mismo (diseño propio) Por otro lado, los programas de extracción de datos se diseñaron de tal forma que solo se obtuvieran tuplas con datos diferentes de nulo, aunque también es posible 87

101 omitir o transformar estos valores durante el proceso de transformación de los datos. También se trató de eliminar inconsistencias en el formato de los campos de fecha obteniendo el mes, día y año como campos independientes a fin de que posteriormente, en el proceso de transformación y carga, este tipo de datos sean cargados al cubo de información en forma correcta. Integración y transformación de los datos Esta fase consiste en integrar la información obtenida en el paso anterior, hacia un repositorio de datos coherente. En este trabajo se utilizará como repositorio del Sistema de Información Ejecutivo de Infraestructura una base de datos dimensional. Es importante tener en cuenta que antes de iniciar con el proceso de integración de datos, es necesario preparar la estructura dimensional de la base de datos, a fin de que la importación de la información desde las fuentes de datos sea transparente y libre de errores. La construcción de la base de datos se explica más adelante en la sección 3.6 Diseño físico de la base de datos. Para llevar a cabo la integración de datos, se elaboraron programas que en la herramienta de implementación utilizada (Oracle Hyperion Essbase) se denominan reglas de carga, los cuales permiten definir la manera en la que se importará la información. Algunas de estas reglas de carga modifican la estructura de la base de datos. Por medio de reglas de carga, pueden agregarse valores, es decir, números a a la base de datos dimensional desarrollada (desde bases de datos relacionales para el presente trabajo). Pero si los datos no se encuentran en el formato correcto, entonces se necesita desarrollar reglas de carga para esos valores. La estructura de la base de datos, puede también ser actualizada en forma manual o por medio de reglas de carga. De esta forma, se pueden agregar dimensiones y miembros de dimensión dinámicamente. Las reglas de carga son un conjunto de operaciones que se ejecutan sobre los datos para validarlos y transformarlos antes de ser integrados a la base de datos. Generalmente se crea una regla de carga por cada dimensión. Lo que hacen las reglas de carga en Essbase es leer los datos a ser importados, los cambia con base en las reglas establecidas y los integra a la base de datos. Es importante tener en cuenta que las fuentes de datos no se modifican. 88

102 El proceso de transformación puede consistir en cualquier de las siguientes acciones o un conjunto de ellas: Ignorar campos o cadenas de la fuente de datos. Cambiar el orden de los campos moviendo, uniendo, dividiendo o creando nuevos campos a partir de los existentes en la fuente de datos. Mapeo de los datos desde el origen hacia la base de datos. Cambiar los valores de los datos provenientes de las fuentes de datos escalando o adicionando los valores existentes en la base de datos. Omitir o modificar valores nulos provenientes de la fuente de datos. Omitir registros inválidos para continuar con el proceso de integración de datos. Agregar nuevas dimensiones y miembros a la base de datos. Modificar dimensiones y miembros existentes en la base de datos. Continuando con el ejemplo del archivo de texto de la figura 3.4, describiré el proceso de construcción de la regla de carga que se deberá utilizar para transformar los datos antes de su integración a la base de datos. Cabe mencionar que este archivo contiene datos relacionados con el presupuesto ejercido por los Estados por el pago de los trabajos realizados a los contratistas en la construcción y conservación de carreteras del país. Para integrar la información de la fuente de datos (en este caso el archivo de texto), se debe especificar la relación uno a uno entre los campos que se encuentran en la fuente de datos contra las dimensiones en la base de datos. Esta relación se especifica en las reglas de carga y funciona cada vez que se requiera importar nuevos datos desde la misma fuente de datos, sin tener que modificar la estructura de la fuente ni la de la regla de carga. Esta asociación campodimensión es obligatoria y no se pueden integrar datos si no se especifica la relación de uno a uno entre el origen de los datos y la base de datos dimensional. Pero antes de especificar esta relación, es necesario preparar los datos para su asociación con la base de datos y posteriormente su integración. El primer paso es abrir el archivo de texto (fuente de datos) dentro del editor de reglas de carga (ver figura 3.5). 89

103 Figura 3.5 Apertura del archivo en el editor de reglas de carga de Essbase con información de ejemplo (definición de una regla de carga en Essbase) Es necesario especificar en la regla de carga que los archivos de texto que se lean con la misma, van a estar delimitados por pipes, ya que como podrá observarse en la figura anterior, los registros los interpreta en principio como un solo campo (Field 1). En la figura 3.6, puede observarse la aplicación de esta operación. Note que después de haber aplicado el delimitador especificado, el archivo se despliega en 16 campos (Field 1 a Field 16). Aunque los campos ya están delimitados, los datos aun no están listos para poder ser integrados a la base de datos. Aquí inicia el proceso de transformación de los datos. Para ajustar la estructura del archivo al formato requerido para la base de datos, se cambiará el orden de algunos campos moviendo, juntando, dividiendo o creando nuevos campos a partir de los existentes. Primera operación: deshabilitar campos que no se utilizarán para integrar datos a la base de datos. La primera operación que se va a realizar es deshabilitar los campos 1 y 5, ya que no se utilizarán para el proceso de integración de datos. La figura 3.7 muestra el resultado de haber deshabilitado estos campos en la regla de carga. Segunda operación: transformar los datos de algunos campos para su asociación con alguna dimensión o miembro de dimensión de la base de datos. Con excepción del campo 15, todos los demás campos estarán asociados con una dimensión de la base de datos y como se comentó anteriormente, deberá haber un campo por cada dimensión a fin de que exista un cruce de todas las 90

104 dimensiones y en la celda que represente la intersección de las mismas, se cargue el valor contenido en el campo 15. Si no se cumple esta condición de relación campo-dimensión, entonces se presentará un error al momento de validar la regla de carga de datos. Con base en lo anterior, es necesario adicionar prefijos a algunos campos con el fin de poder asociarlos con un miembro de alguna de las dimensiones de la base de datos. A continuación se mencionan estas operaciones: Figura 3.6 Ejemplo de delimitación de campos del archivo de texto en una regla de carga (definición de una regla de carga en Essbase) Se adicionará el prefijo PO al campo 2 separado por un punto para su asociación con algún miembro de la dimensión Programa Operativo (ver figura 3.21 Implementación de la dimensión Programa Operativo). Al campo 7 se adicionará el prefijo F para asociarlo con alguno de los miembros de la dimensión Financiamiento (ver figura 3.24 Implementación de la dimensión Financiamiento). El prefijo UD se adicionará al campo 8 para asociarlo con algún miembro de la dimensión Unidad Donante (ver figura 3.23 Implementación de la dimensión Unidad Donante). Se adicionará el prefijo CSCT al campo 9 para su asociación con algún miembro de la dimensión Centro SCT (ver figura 3.17 Implementación de la dimensión Centro SCT). Al campo número 10 se adicionará el prefijo PP para asociarlo con uno de los miembros de la dimensión Programa de Presupuesto (ver figura 3.22 Implementación de la dimensión Programa de Presupuesto). 91

105 Figura 3.7 Resultado de haber deshabilitado los campos 1 y 5 en la regla de carga (definición de una regla de carga en Essbase) Al campo 12 se adicionará el prefijo A para poderlo asociar con un miembro de la dimensión Año (ver figura 3.25 Implementación de la dimensión Año). Por último, se unirán los campos 13 y 14 y se les adicionará el prefijo M para asociar este campo con la dimensión Total Anual (ver figura 3.16 Implementación de la dimensión Total Anual). También se moverá de posición el campo 15 para unirlo con los campos 3, 4, 5, y 6 y asociar el campo que se obtenga con los miembros de la dimensión Proyecto (ver las figuras 3.18 y 3.19 Implementación de la dimensión Proyecto). Las transformaciones anteriores pueden verse en la imagen de la figura 3.8. En la imagen pueden observarse los campos modificados con los prefijos adicionados. Figura 3.8 Adición de prefijos a algunos campos para su asociación con dimensiones de la base de datos dimensional (definición de una regla de carga en Essbase) Tercera operación: Asociación con las dimensiones de la base de datos. Cada uno de los campos de datos (con excepción del campo 12 en la figura 3.8, ya que este campo contiene los valores que serán integrados a la base de datos en el cruce o 92

106 celda que se obtenga de la intersección de las dimensiones que le anteceden), deberá ser asociado a un miembro de cada dimensión de la base de datos. En la figura 3.9 se puede observar la asociación hecha de cada campo a una dimensión de la base de datos. Figura 3.9 Asociación de campos en la regla de carga con las dimensiones de la base de datos (definición de una regla de carga en Essbase) Cuarta operación: Especificación del campo de valores que serán integrados a la base de datos dimensional. Esta operación consiste en establecer en la regla de carga que el campo número 12 contiene los valores que deberán ser importados en la base de datos cuando la regla de carga sea ejecutada (ver figura 3.10). Cabe mencionar que los campos que contiene el archivo de datos solo hacen referencia a 9 de las 11 dimensiones de las cuales constará la base de datos. Las reglas de carga en Essbase permiten especificar las dimensiones o los miembros de dimensión a los que deberán asociarse los valores, cuando no está especificado en la fuente de datos. Dado que los valores que se están importando representan los pagos en pesos hechos por cada contrato, se especificará en la regla de carga que con respecto a la dimensión Avance los valores sean asociados al miembro Avance Financiero (ver figura 3.20 Implementación de la dimensión Avance). Y para la dimensión Dato, los valores se asociarán al miembro Real (ver figura 3.26 Implementación de la dimensión Dato). Las dos especificaciones anteriores se realizan en la regla de carga en un área de configuración denominada Configuración de datos de carga (ver figura 3.11). Los valores serán almacenados en una única celda. Para referirse a un valor específico en la base de datos dimensional, se deberán especificar sus miembros en cada dimensión. Es decir, se deberá hacer un cruce de dimensiones para acceder a un dato en particular. En otras palabras, es necesario generar el cuboide específico que permita acceder a un dato particular de la base de datos (ver computación de cuboides en la base de datos más adelante en este capítulo). 93

107 La celda en la que está almacenado cierto valor también puede ser expresado utilizando el operador de cruce de dimensiones (->). Una vez almacenados los valores en la base de datos y utilizando este operador, se puede decir que el valor (registro 1 en la regla de carga creada que se muestra en la figura 3.10) se encuentra almacenado en la celda referenciada por: PO.SPO -> 010-K0998 Obra:A Contrato: 9ACFA503W09 -> F1 -> UD210 -> CSCT621 -> PP0 -> Ejercido -> A2009 -> M-03_02 -> Avance Financiero -> Real. Figura 3.10 Especificación del campo que contiene los valores que serán importados a la base de datos (definición de una regla de carga en Essbase) Figura 3.11 Configuración de datos de carga a nivel de definición de encabezado de una fuente de datos (definición de una regla de carga en Essbase) Finalmente, se guarda la regla de carga para su ejecución posterior. El ejemplo de proceso de transformación anterior solamente sirvió para preparar un archivo de datos. Sin embargo, fue necesario elaborar 12 archivos adicionales con sus reglas de carga respectivas para preparar tanto la información como la estructura de la base de datos, ya que algunas dimensiones son actualizadas de manera dinámica mediante reglas de carga. El procedimiento es muy similar a la preparación que se hace de los datos para la importación de valores a la base de 94

108 datos, solo que la configuración se realiza para actualización de dimensiones en lugar de carga de datos. Computación de cuboides en la base de datos La computación de cuboides es un proceso que consiste en elegir la manera más adecuada de generar los cruces de información o agrupamientos necesarios para la consulta de información. Para ello es necesario importar la información desde la fuente de los datos hacia el data mart (base de datos dimensional) por medio de reglas de carga. Y posteriormente ejecutar un programa que realice los cálculos necesarios para desagregar la información hacia todos los niveles de dimensión o genere los cuboides de datos en forma total o parcial, según se requiera. Se explicará con mayor detalle las dimensiones que se definieron para el data mart de obra pública. Existen tres opciones para generar los agrupamientos de datos o cuboides 46 : 1. Sin generar agrupamientos. Esto significa no generar ningún cruce de información por anticipado, sino generar los cruces al vuelo, lo cual puede ser extremadamente lento a la hora de tratar de hacer una consulta de información. 2. Materialización total de cuboides. El resultado es la obtención de la enramada de cuboides total. Esta opción generalmente requiere enormes cantidades de memoria para almacenar todo los cuboides obtenidos. 3. Materialización parcial de cuboides. Consiste en elegir de manera selectiva el conjunto de cuboides que se desea obtener. Alternativamente se pueden computar el conjunto de cuboides que contienen aquellas celdas que satisfacen un criterio de búsqueda de un usuario. Nos podemos referir al caso anterior como la obtención de un subcubo de datos. La materialización parcial de cuboides representa una opción interesante entre espacio de almacenamiento y tiempo de respuesta. En el presente trabajo se siguen dos estrategias para materializar los posibles cruces de información o cuboides, según los requerimientos de los usuarios. En algunas ocasiones los usuarios requieren consultar la información de todos los Estados de la República. Por lo cual, se realiza un cómputo total de toda la enramada de cuboides y de esta manera los usuarios pueden obtener consultas de métricas como presupuesto ejercido a nivel nacional, compromisos registrados 46 Han, J. (2006). Data Mining: Concepts and Techniques. San Francisco, CA.: Morgan Kaufmann. P

109 por cada Estado del país o el presupuesto disponible para toda la Secretaria en el rubro de gasto de inversión. Pero por lo regular la consolidación de cuboides se realiza de manera parcial. Se computan los cuboides solo para los Estados del país de los cuales se necesita consultar su información. En el siguiente ejemplo se realiza un cálculo para obtener un subcubo de datos del Estado de Aguascalientes (clave 621), con base en la métrica Ejercido Total del año Para ello se utiliza el comando FIX, el cual es un comando de cálculo de Oracle Hyperion Essbase. Los comandos de cálculo se definen en un script para instruir a Essbase a ejecutar un determinado cálculo diferente al default, el cual hace un cálculo total de las dimensiones y sus niveles 47. FIX(CSCT621,EjercidoTotal,A2009) CALC DIM (UnidadDonante,TotalAnual,Financiamiento,ProgramaPresup,ProgramaOperativo, "Proyecto Obra-Tramo",Avance,Dato); ENDFIX; Por otro lado, la instrucción CALC ALL le indica al sistema computar el total de posibles subconjuntos del conjunto de dimensiones {centro de trabajo, tiempo, avance, dato, año, financiamiento, métricas, programa operativo, programa de presupuesto, centro sct, proyecto}, incluyendo el subconjunto vacío. Análisis y reportes Fue necesario también diseñar y desarrollar una suite de reportes y gráficas estadísticas que muestran los parámetros y las tendencias que el usuario debe analizar. Para desarrollar esta suite de reportes, se utilizó otra herramienta de Oracle llamada Oracle Workspace el cual es un software que permite elaborar de forma rápida y flexible una consulta hacia el data mart de obra pública. Esta suite de reportes puede ser consultada desde la web utilizando cualquier navegador disponible. 47 Hyperion Essbase Technical Reference. Hyperion Solutions Corporation

110 Diseño conceptual del SIE En el desarrollo de un sistema de información basado en el modelo relacional, se utilizarían diagramas basados en la notación del modelo entidad-relación para identificar y diseñar la relación entre los datos de la organización. Para diseñar un data mart, se utiliza un modelo dimensional. Pero al igual que en el modelo entidad-relación, se debe partir del análisis de las necesidades de información y requerimientos del usuario. Como sabemos, el diseño lógico de un sistema es conceptual. No se necesita adentrar mucho en aspectos técnicos aún. Solo se requiere definir el tipo de información que se manejará. En este proyecto, se utilizó el modelo de estrella para diseñar el repositorio de datos del Sistema de Información Ejecutivo. El modelo lógico resultante contiene un conjunto de entidades correspondientes a la tabla de hechos (fact table) y a tablas de dimensión (dimension tables). En la figura 3.12, puede observarse el diagrama de estrella obtenido. Contrato Día Obra Mes Estado Proyecto de presupuesto Trimestre Región Grupo de proyecto Tipo de contrato Tiempo Centro SCT Proyecto Año Número de año Métricas Dato Avance Periodicidad de los datos Tipo de avance Financiamiento Programa operativo Tipo de programa Periodo del programa Tipo de trabajo Tipo de recurso Centro de trabajo Programa de presupuesto Origen del recurso Tipo de centro de trabajo Tipo de programa Figura Modelo de estrella del SIE (diseño propio) 97

111 En la siguiente tabla se describe cada una de las entidades que se mencionan en la figura Etiqueta de Dimensión Métricas Tiempo Centro de trabajo Avance Financiamiento Programa operativo Programa de presupuesto Región Descripción Diferentes flujos de los recursos (por ej. Asignado, Modificado, Comprometido, etc.). Más adelante se detallan los elementos de esta dimensión. Dimensión de tiempo. Contiene el detalle diario de las operaciones y los acumulados trimestral y mensual. Direcciones Generales o entidades normativas que asignan el presupuesto. Se contempla la información de tres Direcciones de la Subsecretaría de Infraestructura las cuales son: Dirección General de Conservación de Carreteras (DGCC), Dirección General de Carreteras (DGC) y Dirección General de Servicios Técnicos (DGST). Avance físico y avance financiero de una obra Contiene todas las fuentes de financiamiento (por ej. Recursos fiscales, Recursos externos) Programas operativos al interior de cada unidad donante. Esta dimensión se agregó particularmente para la DGCC, ya que esa Dirección desagrega sus presupuestos en programas operativos. Forma parte de la clave presupuestal, mediante la cual se asigna el presupuesto. Para el año 2009, el programa presupuestal es cero. Aguascalientes a Zacatecas organizados por Región (por ej. noroeste, noreste, centro del país, centro occidente y sursureste) Proyecto presupuesto Año de Esta dimensión se utiliza para clasificar la información por grupos de proyecto. Cada grupo puede contener proyectos presupuestales asociados, los cuales a su vez se pueden subclasificar en obras. Y cada obra puede tener diferentes contratos. Permite guardar información histórica por ejercicio fiscal, a fin de hacer comparativos de la administración del presupuesto entre 98

112 diferentes años Dato Esta dimensión se construyó con la finalidad de hacer acumulados semanales de la información del presupuesto. La dimensión llamada métricas (o tabla de hechos), contiene atributos numéricos que representan los diferentes tipos de operación que se pueden aplicar al presupuesto de la Secretaría de Comunicaciones y Transportes. Por medio de los elementos de esta dimensión, se pueden realizar las operaciones necesarias para responder a preguntas como el presupuesto de una obra o el presupuesto comprometido para un contrato, etc. Dada la importancia de los atributos de esta dimensión, a continuación se describe cada uno de ellos. Es importante mencionar que algunos de estos atributos están diseñados para almacenar información, mientras que otros utilizan fórmulas para calcular algún dato a partir de los primeros. Presupuesto original. Almacena la información correspondiente al presupuesto original asignado a la SCT. Ampliaciones al presupuesto. Almacena los movimientos de ampliación al presupuesto ya autorizados por la SHCP y por la DGPOP. Reducciones al presupuesto. Almacena los movimientos de reducción al presupuesto ya autorizados por la SHCP y por la DGPOP. Presupuesto modificado. Es la suma del presupuesto original más las ampliaciones menos las reducciones. En el cubo es una miembro de dimensión que calcula este dato mediante la siguiente fórmula: Original + Ampliaciones Reducciones Presupuesto comprometido original. Almacena la información correspondiente al compromiso original (sin ampliaciones ni reducciones) de un contrato, registrado por cada obra en el Sistema SIRASEF. Ampliaciones al presupuesto comprometido. Guarda la información de las tarjetas de modificación (ampliaciones) que se registran en el SIRASEF por cada contrato. 99

113 Reducciones al presupuesto comprometido. Guarda la información de las tarjetas de modificación (reducciones) que se registran en el SIRASEF por cada contrato. Presupuesto comprometido modificado. Es un elemento de dimensión que calcula el compromiso total (la suma del compromiso original de un contrato más las ampliaciones menos las reducciones hechas al mismo), registrado por cada contrato en el SIRASEF. En el SIE, este cálculo se realiza mediante la siguiente fórmula: Comprometido + Ampliaciones por contrato Reducciones por contrato Presupuesto comprometido real. Es un elemento de dimensión que calcula el compromiso sin ejercer, por cada contrato de obra registrado en el SIRASEF. La fórmula mediante la cual se calcula este dato es: Modificado por contrato Ejercido en trámite - Ejercido Presupuesto ejercido en trámite. Almacena la información de los pagos que se encuentran en trámite en el Sistema Integral de Administración. Es decir, almacena los pagos que no están asociados a una cuenta por liquidar certificada en el SIA y que por lo mismo, no están registradas en el SIAFF (Sistema Integral de Administración de la Tesorería de la Federación). Presupuesto ejercido real. Guarda la información de los pagos realmente efectuados a los proveedores y que se encuentran asociados a una cuenta por liquidar ya registrada en el SIAFF. Presupuesto ejercido total. Es un elemento de dimensión que calcula el ejercido total por cada proyecto presupuestal o contrato de obra, mediante la siguiente fórmula: Ejercido en trámite + Ejercido Presupuesto disponible. Corresponde al disponible por cada proyecto presupuestal registrado en el Sistema Integral de Administración. En el SIE es un elemento de dimensión calculado que se obtiene de la siguiente forma: Modificado Compromiso real Ejercido - Ejercido en trámite 100

114 Porcentaje de presupuesto comprometido contra presupuesto modificado. Es un elemento de dimensión que calcula el porcentaje de recursos presupuestales o kilómetros comprometidos, contra el presupuesto total asignado o meta en kilómetros total a ejecutar. Porcentaje presupuesto ejercido contra presupuesto modificado. Es un elemento de dimensión que calcula el porcentaje de avance físico ejercido o pagos realizados, contra la meta en kilómetros a ejecutar o el presupuesto total asignado. Porcentaje de presupuesto ejercido contra presupuesto comprometido. Es un elemento de dimensión que calcula el porcentaje de pagos realizados, contra el presupuesto comprometido en un proyecto. Ahora bien, cada uno de los elementos en la dimensión de métricas no tendría ningún sentido si no se realiza un cruce de datos almacenados en esos elementos contra los de las otras dimensiones. A continuación se muestra la relación entre los elementos de la dimensión métricas contra los elementos de las otras dimensiones. También se indica el nivel contra el cual es necesario realizar este cruce de información para obtener el dato que se requiera. Esto último es importante mencionarlo porque el motor OLAP de Oracle Essbase, almacena los datos en los elementos de nivel cero de cada dimensión. Es decir, la estructura de un data mart construido dentro de esta herramienta, es similar a una estructura de datos de tipo árbol para cada dimensión. La información es almacenada en los elementos de más bajo nivel y ésta se acumula conforme se sube en la estructura del árbol respecto a los antecesores de cada elemento de dimensión hasta llegar al tope máximo, el cual es el elemento en la cima de una dimensión y este contiene la información acumulada de todos sus antecesores. Los elementos Original, Ampliaciones, Reducciones y Modificado, tendrán un cruce de información con: Nombre de la dimensión Nivel de detalle requerido Nivel o generación en la dimensión Total anual Mensual Nivel 1 Avance Financiero Nivel 0 101

115 Proyecto presupuestal Por grupo de proyecto Generación 2 Financiamiento Fuente de financiamiento Nivel 0 Unidad donante Unidad dueña de los recursos (DGC, DGCC o DGST) Nivel 0 Región Estados Nivel 0 Programa presupuestal Programa operativo Información por programa presupuestal. En el 2009 no hay programa presupuestal. Total en todos los programas operativos Nivel 0 Generación 1 Los elementos Comprometido y Disponible, tendrán un cruce de información con: Nombre de la dimensión Nivel de detalle requerido Nivel o generación en la dimensión Total anual Mensual Nivel 1 Avance Financiero y físico Nivel 0 Proyecto presupuestal Por grupo de proyecto, obra y por contrato Niveles 0, 1, 2 Financiamiento Fuente de financiamiento Nivel 0 Unidad donante Unidad dueña de los recursos (DGC, DGCC o DGST) Nivel 0 Región Estados Nivel 0 Programa presupuestal Información por programa presupuestal. En el 2009 no hay programa presupuestal. Nivel 0 Programa Total por programa operativo Nivel 0 102

116 operativo Los elementos de Ejercido y Ejercido en trámite, tendrán un cruce de información con: Nombre de la dimensión Nivel de detalle requerido Nivel o generación en la dimensión Total anual Diario Nivel 0 Avance Financiero y físico Nivel 0 Proyecto presupuestal Por grupo de proyecto, obra y por contrato Niveles 0, 1, 2 Financiamiento Fuente de financiamiento Nivel 0 Unidad donante Unidad dueña de los recursos (DGC, DGCC o DGST) Nivel 0 Región Estados Nivel 0 Programa presupuestal Información por programa presupuestal. En el 2009 no hay programa presupuestal. Nivel 0 Programa operativo Total por programa operativo Nivel 0 Es importante mencionar que se pueden generar una cantidad mayor de cruces de información entre las dimensiones y entre los diferentes niveles que las conforman. Cada cruce de información que se realice, dará como resultado una consulta diferente. Sin embargo, los cruces de dimensiones arriba mencionados son los mínimos necesarios para cubrir los requerimientos de información que las áreas usuarias esperan obtener del Sistema de Información Ejecutivo. En la figura 3.13, se puede apreciar la implementación de la dimensión Métricas, en la estructura del data mart del SIE. 103

117 Figura 3.13 Implementación de la dimensión Métricas (diseño propio) Y, cuál es el total de cuboides, o group-by, que pueden ser computados para este cubo de once dimensiones? Para responder a esta pregunta primero vamos a obtener el total de niveles por cada dimensión (incluyendo el nivel más alto o 0-D). En la siguiente tabla se puede observar el total de niveles por dimensión: Número de dimension Nombre de la dimensión Niveles de la dimensión 1 Centro de trabajo 2 2 Tiempo 4 3 Avance 2 4 Dato 2 5 Año 2 6 Financiamiento 3 7 Metricas 2 8 Programa operativo 4 9 Programa de presupuesto 2 10 Centro SCT 3 11 Proyecto 5 Aplicando la ecuación (1.1) del capítulo 1, tendremos que el número total de cuboides que se pueden obtener para este cubo de datos es de 46,080 cuboides Parámetros de información que los usuarios pueden consultar El data mart permitirá a los usuarios finales consultar una serie de parámetros de información con los cuales podrán evaluar la forma en la que los estados o Centros SCT ejercen el presupuesto asignado. Dichos parámetros se enlistan a continuación. Nombre del parámetro Presupuesto asignado a la SCT destinado a la inversión en Unidad de medida Pesos Descripción Muestra el presupuesto asignado a cada Estado en el Presupuesto de Egresos de la Federación (PEF). 104

118 infraestructura carretera Presupuesto modificado Pesos Indica el presupuesto disponible por cada Estado, después de ampliaciones y reducciones al presupuesto aplicados por la SHCP. Presupuesto Pesos Indica el presupuesto contratado comprometido en por cada Estado para la construcción construcción de carreteras. Presupuesto ejercido Pesos Este indicador muestra el presupuesto que ha sido pagado a los contratistas por la ejecución de sus servicios. Presupuesto Pesos Indica el presupuesto contratado comprometido en por cada Estado para la conservación de conservación de carreteras. carreteras Presupuesto disponible Pesos Muestra el presupuesto disponible o Número de kilómetros a ejecutar en construcción de carreteras Número de kilómetros a ejecutar en conservación de carreteras Número de kilómetros construidos Número de kilómetros a los cuales se les ha dado mantenimiento Kilómetros Kilómetros Kilómetros Kilómetros sin ejercer por cada Estado. Indica la cantidad de kilómetros de construcción carreteras que cada Estado ejecutará por ejercicio fiscal. Indica la cantidad de kilómetros de conservación de carreteras que cada Estado ejecutará por ejercicio fiscal. Indica la cantidad de kilómetros construidos por cada Estado del país. Indica la cantidad de kilómetros a los cuales se les ha dado mantenimiento por cada Estado del país. Presupuesto en trámite de pago Presupuesto comprometido en conservación de carreteras por programa operativo Presupuesto ejercido en conservación de carreteras por programa operativo Pesos Indica el presupuesto que se encuentra en trámite de pago a los contratistas en cada Estado del país. Pesos Indica el presupuesto contratado por cada Estado respecto a conservación de carreteras, por el concepto de programa operativo. Pesos Indica el presupuesto que ha sido pagado a los contratistas por la conservación de carreteras, por el concepto de programa operativo. 105

119 Estados con mayor presupuesto asignado por ejercicio fiscal Presupuesto ejercido semanal Porcentaje de presupuesto comprometido respecto al presupuesto asignado, en cuanto a construcción y modernización de carreteras Porcentaje de presupuesto ejercido respecto al presupuesto asignado en cuanto a construcción y modernización de carreteras Porcentaje de presupuesto ejercido respecto al presupuesto comprometido en cuanto a construcción y modernización de carreteras Porcentaje de presupuesto comprometido respecto al presupuesto asignado, en cuanto a caminos rurales y carreteras alimentadoras Porcentaje de presupuesto ejercido respecto al presupuesto asignado en cuanto a caminos rurales y carreteras alimentadoras Porcentaje de presupuesto ejercido respecto al presupuesto Pesos Muestra los nueve estados con mayor presupuesto para inversión en infraestructura carretera. Pesos Muestra el presupuesto que cada estado del país ha pagado a sus contratistas por la ejecución de obra de forma semanal. Porcentaje Este indicador muestra el porcentaje de dinero que cada Estado ha comprometió en comparación a su presupuesto asignado, para la construcción y modernización de carreteras. Porcentaje Este indicador muestra el porcentaje de dinero que cada Estado pagó a sus contratistas en comparación a su presupuesto asignado, después de la ejecución de obra pública para la construcción y modernización de carreteras. Porcentaje Este indicador muestra el porcentaje de dinero que cada Estado pagó a sus contratistas en comparación al dinero que comprometió para la construcción y modernización de carreteras. Porcentaje Este indicador muestra el porcentaje de dinero que cada Estado ha comprometió en comparación a su presupuesto asignado, para la construcción y mantenimiento de caminos rurales y carreteras alimentadoras. Porcentaje Este indicador muestra el porcentaje de dinero que cada Estado pagó a sus contratistas en comparación a su presupuesto asignado, después de la ejecución de obra pública para la construcción y mantenimiento de caminos rurales y carreteras alimentadoras. Porcentaje Este indicador muestra el porcentaje de dinero que cada Estado pagó a sus contratistas en 106

120 comprometido en cuanto a caminos rurales y carreteras alimentadoras Porcentaje de presupuesto comprometido respecto al presupuesto asignado, en cuanto a conservación y mantenimiento de carreteras federales Porcentaje de presupuesto ejercido respecto al presupuesto asignado en cuanto a conservación y mantenimiento de carreteras federales Porcentaje de presupuesto ejercido respecto al presupuesto comprometido en cuanto a conservación y mantenimiento de carreteras federales comparación al dinero que comprometió para la construcción y mantenimiento de caminos rurales y carreteras alimentadoras. Porcentaje Este indicador muestra el porcentaje de dinero que cada Estado ha comprometió en comparación a su presupuesto asignado, para la conservación y mantenimiento de carreteras federales. Porcentaje Este indicador muestra el porcentaje de dinero que cada Estado pagó a sus contratistas en comparación a su presupuesto asignado, después de la ejecución de obra pública para la conservación y mantenimiento de carreteras federales. Porcentaje Este indicador muestra el porcentaje de dinero que cada Estado pagó a sus contratistas en comparación al dinero que comprometió para la conservación y mantenimiento de carreteras federales Diseño de consultas empresariales Adicionalmente al diagrama de estrella de la figura 3.12, los modelos de consulta pueden ayudar a determinar la estructura del data mart que se va a construir. Los modelos de consulta que pueden observarse en las figuras 3.14 y 3.15, representan las consultas de información que los usuarios esperan obtener del SIE. 107

121 Figura 3.14 Molde de consulta empresarial de Presupuesto (diseño propio) Figura 3.15 Molde de consulta empresarial de Programa Operativo (diseño propio) 108

122 A continuación se listan ejemplos de consultas empresariales que se puede obtener del molde de la figura 3.14: 1. Presupuesto modificado anual de la DGC por Estado por grupo de proyecto por tipo de avance por tipo de financiamiento. 2. Presupuesto ejercido real anual de la DGC por región por proyecto de presupuesto. 3. Presupuesto modificado trimestral por Estado para la DGC. Para el molde de la figura 3.15, las consultas empresariales que se pueden obtener son: 1. Presupuesto modificado por contrato anual de la DGCC por Estado por programa operativo 2. Presupuesto modificado anual de la DGCC por Estado por programa operativo por tipo de financiamiento Herramienta que se utilizó para la implementación Para implementar ésta solución, se utilizó el software Oracle Essbase OLAP Server, la cual es una plataforma para la elaboración de informes, análisis, modelos y presupuestos. Este software permite el acceso de lectura/escritura de múltiples usuarios, capacidad de almacenamiento de datos a gran escala, realización de cálculos analíticos y consultas OLAP sofisticadas (proceso analítico on-line). Proporciona navegación multidimensional, intuitiva y con tiempos de respuesta rápidos y consistentes en entornos cliente-servidor. Soporta los sistemas operativos Windows NT, UNIX y AS/400. Integra datos desde múltiples orígenes tendientes a aplicaciones analíticas dentro de una arquitectura global de Data Warehouse o desde aplicaciones OLTP y orígenes de datos externos. Dentro del Data Warehouse, Essbase servirá como elemento de entrega de la información estratégica proporcionando un acceso compartido y un análisis de datos para las áreas de infraestructura de la Secretaría, mediante la utilización de herramientas estándares de la informática personal tales como hojas de cálculo, herramientas de consulta y los navegadores de Web. Oracle Essbase agrupa la información dentro de categorías denominadas dimensiones, tales como son el tiempo, la geografía, los productos, canales y escenarios. Dentro de cada dimensión, los datos se organizan jerárquicamente 109

123 (mediante miembros de dimensión), de forma que los usuarios pueden navegar desglosando la información desde datos resumidos a mayores niveles de detalle. 48 En el entorno generado con Web Analysis, que es una herramienta del grupo de software de Oracle dirigida al análisis y generación de reportes por la web y que fue básicamente sobre la que se desarrolló el ambiente de operación final (interfaz de usuario), los usuarios pueden rotar las dimensiones desde las filas a las columnas de un informe y segmentar los datos para retirar la información no esencial. Esta herramienta permite también la distribución de particiones por la red con una funcionalidad completa y total transparencia en la posición, lo cual permitirá el desarrollo de diversos cubos de información. Todas las operaciones OLAP incluyendo las de desglose, consultas, cálculos y cargas, pueden abarcar múltiples computadoras. Oracle Essbase es una plataforma tecnológica para dar soporte a varias categorías de aplicaciones analíticas, ya existentes y de nueva creación, dirigidas a la operativa táctica y estratégica de la Secretaría de Comunicaciones y Transportes. Se aprovechó una de las características más importantes de esta tecnología, la cual es que fue concebida para operar en entornos cliente-servidor con bases de datos centralizadas. 3.6 Diseño físico de la base de datos Como sabemos, el diseño lógico de un sistema de información solamente ilustra la manera en la que funcionará y la información que habrá de manejar. El diseño físico es la parte más importante en la construcción de un data mart o de un data warehouse, ya que aquí se determina cómo se estructurará la información y como se consolidará. Una vez definida y creada la estructura de la base de datos del data mart, los datos pueden ser extraídos desde las fuentes de datos y colocados en esa base de datos. Una vez recuperada la información, se pueden ejecutar los cálculos que sean necesarios y posterior a ello, toda la información consolidada y calculada puede ser consultada a través de tableros de control y de otro tipo de reportes. En Oracle Essbase, a la estructura de la base de datos construida se le llama Outline. 48 Hyperion Solutions Corporation. (2000). Hyperion Essbase Fundamentals Training. Sunnyvale, California: Hyperion Solutions Corporation. 110

124 Es importante mencionar que a diferencia de otras aplicaciones en las que para generar una estructura de base de datos OLAP es necesario utilizar sentencias de SQL para implementar la aplicación, Oracle Essbase facilita esta tarea a través de un generador de Outline en el cual el programador crea la estructura dimensional sin preocuparse por el uso de comandos Desarrollo del data mart Después de haber determinado la información que almacenará el data mart y obtener un diseño previo sobre las dimensiones de datos que procesará, su construcción es relativamente sencilla. Se podría decir que el trabajo se reduce a transcribir el modelo estrella presentado en la figura 3.12, utilizando para ello el motor de bases de datos OLAP Oracle Hyperion Essbase. A continuación se describe la implementación de cada dimensión del data mart. Es importante mencionar que no obstante lo simple que pudiera parecer la implementación que se presenta a continuación, es necesario contar con cierto nivel de conocimiento y experiencia en el manejo de este tipo de herramientas, a fin de obtener un buen nivel de desempeño o performance, una vez que la aplicación se libere a producción. Implementación de la dimensión Tiempo Esta dimensión contempla que la información pueda ser consultada por día, mes, trimestre o por el total anual (nivel más alto de la dimensión). Es recomendable utilizar también una dimensión que administre los años, a fin de que se tenga la habilidad de almacenar información histórica anual. De esta manera, se tendrá la posibilidad de realizar comparaciones entre la información de múltiples años. En la figura 3.16, se puede observar la implementación de esta dimensión. Cabe hacer mención que en la implementación de la dimensión se le dio el nombre Total Anual con el fin de hacer más representativo el dato para el usuario. 111

125 Figura Implementación de la dimensión Total Anual (diseño propio) En algunos elementos de la dimensión Total anual (y también en la estructura de otras dimensiones que se analicen más adelante), podrá observar la etiqueta Dynamic Calc. Esto significa que ese elemento no almacena la información en la base de datos. Lo que hace realmente es calcular los datos con base en la consolidación de los elementos inferiores de la dimensión. Es decir, los datos se almacenan en el nivel más bajo de la dimensión el cual corresponde a los días del mes. Posteriormente, la información se consolidada hacia los elementos superiores primero por mes, luego por trimestre y por último a nivel anual. Implementación de la dimensión Centro SCT Uno de los requerimientos de las áreas solicitantes es que el SIE proporcione información clasificada por región del país y a su vez subclasificada por estado o Centro SCT. Esto dará la facilidad de poder consultar la situación financiera de cualquier Estado de la República Mexicana en cualquier momento. Así mismo, se podrá conocer la situación de toda una región o de todo el país en un momento dado. La dimensión quedó implementada de la siguiente manera. En la figura 3.17, se puede observar la implementación de la dimensión Centro SCT. 112

126 Figura Implementación de la dimensión Centro SCT (diseño propio) En esta dimensión podrá observar que cuando se carguen datos a esta base de datos dimensional, la información se almacenará en el nivel más bajo de la dimensión, el cual es el nivel cero que corresponde a los estados o Centros SCT. Posteriormente, la información se consolidará a nivel Región y finalmente a nivel nacional. También se agregó el elemento de dimensión que tiene el alias Extranjero. Esto se hizo con la finalidad de tener preparada la estructura para que en el futuro se tenga contemplado este tipo de información, de ser necesario. Implementación de la dimensión Proyecto De acuerdo al modelo de estrella de la figura 3.12, para la construcción del SIE es necesario consolidar información de las obras y de los contratos por un concepto que dentro del presupuesto de la Secretaría (y en general para todo el gobierno federal) se le conoce como proyecto de presupuesto o proyecto de inversión. 113

127 Uno de los requerimientos de información fue que los contratos de obra se pudieran consultar por grupo de proyecto o por tipo de contrato. Por lo tanto, se generaron dos niveles de agregación en la estructura de esta dimensión, como se puede apreciar en la figura Figura Implementación de la dimensión Proyecto en los niveles de grupos de presupuesto y de tipo de contrato (diseño propio) Por otro lado, en la figura 3.19 se puede observar la estructura de la misma dimensión, pero a nivel de obra y de contrato de obra. La imagen muestra un proyecto de presupuesto o de inversión identificado como K0315 que pertenece al grupo de presupuesto G003, en el cual se agrupan todas las obras relacionadas a la construcción de carreteras. El proyecto K0315 corresponde a un proyecto de obra llamado Mitla Entronque Tehuantepec, para el Estado de Oaxaca. Y ese proyecto de presupuesto tiene 4 obras asignadas que pueden corresponder a diferentes tramos de construcción. Cada obra puede tener uno o más contratos. En la figura solo se despliega el contenido de la obra F , que tiene un solo contrato asignado con el número 8TCEA503W. Figura 3.19 Implementación de la dimensión Proyecto en los niveles de obra y de contrato (diseño propio) Implementación de la dimensión Avance La dimensión avance sirve para clasificar la información por avance físico o financiero. De esta forma, el usuario podrá analizar alguno de los dos tipos de información a través de un reporte o de un tablero de control, con solo elegir el tipo de avance que requiera consultar. La figura 3.20 muestra la manera en que se implementó esta dimensión dentro del data mart. 114

128 Figura 3.20 Implementación de la dimensión Avance (diseño propio) Como podrá observarse en la figura anterior, la dimensión avance tiene una marca llamada Label Only. Esto significa que esa dimensión solamente se utilizará para clasificar la información pero físicamente no almacenará datos. Implementación de la dimensión Programa Operativo Esta dimensión fue implementada por una necesidad que planteó el personal de la Dirección General de Conservación de Carreteras (DGCC). Esa Dirección subclasifica su información a un nivel de detalle mayor, ya que la conservación de carreteras implica acciones muy particulares que las otras dos Direcciones no manejan. En la figura 3.21 se puede observar la estructura definida para esta dimensión. Figura 3.21 Implementación de la dimensión Programa Operativo (diseño propio) Implementación de la dimensión Programa de presupuesto Para el ejercicio fiscal 2009, el presupuesto de la SCT no contempla el rubro de programa de presupuesto. Sin embargo, se decidió contemplar esta dimensión en la estructura del data mart, con el fin de prever que en próximos años se llegue a manejar, como sucedió en años pasados. La dimensión programa de presupuesto se implementó como se muestra en la figura

129 Figura 3.22 Implementación de la dimensión Programa de Presupuesto (diseño propio) Implementación de la dimensión Centro de trabajo Esta dimensión se utiliza para clasificar la información por Dirección General. A esta dimensión se le dio el nombre de Centro de Trabajo para utilizar el mismo concepto que se usa en los reportes del estado del ejercicio de la Secretaría. De esta forma, el usuario se siente más familiarizado con la información que va a visualizar en el SIE. La estructura de esta dimensión se puede apreciar en la figura Figura 3.23 Implementación de la dimensión Unidad Donante (diseño propio) Implementación de la dimensión Financiamiento La dimensión Financiamiento se utiliza para almacenar la información por el origen de los recursos financieros que se utilizan para ejecutar la obra pública. Estos recursos pueden tener dos origenes: Recursos fiscales internos y recursos externos a la Secretaría. Se puede apreciar en la figura 3.24 la manera en la que se implementó esta dimensión. Figura 3.24 Implementación de la dimensión Financiamiento (diseño propio) Implementación de la dimensión Año La dimensión Año se utiliza para poder almacenar información clasificada por ejercicio fiscal. La idea de implementar esta dimensión es darle al usuario la funcionalidad de poder hacer comparativos de la operación del presupuesto entre diferentes años. En la figura 3.25 se puede observar su implementación. 116

130 Figura 3.25 Implementación de la dimensión Año (diseño propio) Implementación de la dimensión Dato Esta dimensión se construyó con la finalidad de hacer acumulados semanales de la información del presupuesto. La estructura con la que se implementó se muestra en la figura Figura 3.26 Implementación de la dimensión Dato (diseño propio) 3.7 Interfaces gráficas para el usuario final En esta sección se describe la herramienta de reportes desarrollada para el usuario tomador de decisiones. Como herramienta de reporteo se utilizó una aplicación web que también forma parte de la plataforma de inteligencia de negocios de Oracle. Esta aplicación se llama Oracle Hyperion Web Analysis Studio y es una herramienta de análisis, presentación y reporteo para bases de datos multidimensionales y relacionales 49. Figura 3.27 Página de inicio de SIE de Infraestructura (diseño propio) 49 Oracle Corporation. (2007). Hyperion Web Analysis Studio Release Users Guide. Redwood, CA. p

131 La página de inicio y todas las páginas web del Sistema de Información Ejecutivo fueron desarrolladas utilizando Oracle Hyperion Web Analysis Studio. Cada una de las opciones que se muestran en la página de inicio de la figura 3.27, son ligas hacia el grupo de reportes de cada área. En las figuras 3.28, 3.29 y 3.30, se puede apreciar los reportes creados para cada grupo. Figura 3.28 Grupo de reportes para la Dir. Gral. de Carreteras Federales (diseño propio) Los reportes fueron diseñados e implementados de acuerdo a las necesidades de información que las áreas usuarias plantearon. Realmente, todos los reportes tienen acceso a la misma información ya que todos se conectan al mismo data mart de infraestructura. Sin embargo, el reporte que para un usuario puede ser visto en forma tabular, para otra área debe ser visto como una gráfica. Por lo que lo único que cambia de un reporte a otro, es la manera en la que se despliegan los datos y el nivel de detalle que cada usuario requería consultar. 118

132 Figura 3.29 Grupo de reportes para la Subsecretaría de Infraestructura (diseño propio) Figura 3.30 Grupo de reportes para la Dir. General de Conservación de Carreteras (diseño propio) 119

133 A continuación se muestran algunos de los reportes que pueden ser consultados por cada área. En la figura 3.31 se muestra uno de los tipos de reportes que pueden ser consultados por la Dirección General de Carreteras Federales. Se trata de un reporte tabular, en el que el usuario puede consultar por estado o por región, la información referente a la meta física, así como consultar algunos de los elementos de la dimensión métricas del data mart de Infraestructura Carretera. Figura 3.31 Reporte con información de muestra de obras por Estado de la Dir. Gral. de Carreteras (diseño propio) En la figura 3.32, se muestra otro reporte de la Dirección General de Carreteras. Este reporte muestra el presupuesto ejercido (información de ejemplo), como un porcentaje respecto al presupuesto asignado a cada Centro SCT en cada Estado del país. En color rojo, se muestran los Estados que han ejercido por debajo del 50 % de su presupuesto trimestral (en la gráfica se muestra el tercer trimestre del año) y en color verde, se muestran los Estados que han ejercido por encima del 50 % en el mismo periodo de tiempo. 120

134 El mapa que se despliega a la derecha, es solo una imagen (con extensión GIF) y los puntos rojos y verdes se actualizan en forma automática de acuerdo al semáforo del reporte tabular. Cabe mencionar que en este ejemplo solo se tomó un punto de referencia para crear un semáforo de la información. Sin embargo, podrían especificarse muchos más puntos de referencia o rangos. Figura 3.32 Reporte con información de muestra del presupuesto ejercido vs asignación presupuestal (presupuesto modificado) de la Dir. Gral. de Carreteras (diseño propio) En la figura 3.33, puede apreciarse otro tipo de reportes que los usuarios pueden consultar por medio del SIE de Infraestructura. En este reporte el usuario puede visualizar la consulta de tres métricas: Presupuesto ejercido, presupuesto ejercido en trámite y presupuesto disponible, por cada Centro SCT. 121

135 Figura 3.33 Reporte con información de muestra del presupuesto ejercido, ejercido en trámite y disponible de la Subsecretaría de Infraestructura (diseño propio) Finalmente, en la figura 3.34, se puede observar un reporte de la Dirección General de Conservación de Carreteras en el cual pueden consultar las métricas de comprometido original de contratos y presupuesto ejercido de contratos por programa operativo. Es importante mencionar que los reportes antes mencionados son solo ejemplos del tipo de consultas que los usuarios pueden hacer directamente sobre el data mart de Infraestructura Carretera. No son los únicos tipos de reportes que se pueden generar. Los usuarios pueden elaborar reportes según sus necesidades. Lo importante a destacar es que la fuente de información (SIE de Infraestructura) es única para todas las áreas de la Subsecretaría de Infraestructura y lo único diferente es la manera en la que cada usuario requiere visualizar los datos. 122

136 Figura 3.34 Reporte con información de muestra del presupuesto de inversión y metas de la Dir. Gral. de Conservación de Carreteras (diseño propio) Herramientas de análisis Adicionalmente al porta web mediante el cual los usuarios de la Subsecretaría de Infraestructura pueden acceder a los reportes prediseñados del SIE y hacer consultas al data marta de Infraestructura, la plataforma de Oracle Hyperion incluye un programa addin (clase), el cual representa un complemento para Microsoft Excel. Mediante este herramienta, los usuarios pueden hacer consultas directamente a la información del data mart y complementar el potencial que ofrece la base de datos dimensional, con las funciones y herramientas que contiene Excel. De esta forma, los usuarios pueden elaborar plantillas o reportes predefinidos en esa aplicación de Microsoft y únicamente actualizar los datos cada vez que requieran generar la misma consulta. 123

137 En la figura 3.35, puede observarse un ejemplo de esta herramienta de análisis. Por default, cuando se establece la conexión hacia el data mart desde Excel, se despliegan los nombres de las dimensiones al nivel más alto (generación 1) de cada una de ellas. Para crear una consulta, el usuario debe llegar al nivel de profundidad de cada dimensión, según sus necesidades de consulta. Para ello, el usuario debe hacer drill down o roll up a cada dimensión y así lograr el nivel de profundidad deseado. También puede pivotear las dimensiones entre renglones y columnas a fin de establecer el formato de una consulta. Figura 3.35 Addin de Excel para realizar consultas al data mart de Infraestructura (diseño propio) En el ejemplo de la figura 3.36, puede apreciarse la manera en la que se puede utilizar la herramienta de análisis de datos de Excel, para generar consultas al data mart de Infraestructura Carretera. En la figura 3.36, se hizo drill down a la dimensión Centro SCT para desplegar la información de la región Centro Occidente del país. También se hizo drill down a la dimensión Proyecto para analizar la información del proyecto de presupuesto K1506 por cada Estado de esa región. Puede observarse también que se están consultando dos métricas: Presupuesto Modificado y Presupuesto Ejercido. Las dimensiones Programa Operativo, Centro de Trabajo, Total Anual, Dato, Año, Financiamiento y Programa, se están consultando a nivel de de dimensión. Es decir, no se están filtrando datos por ninguna de estas dimensiones. 124

138 En la figura 3.37 se esquematiza por medio de un cubo, la manera en la que se realiza el cruce de información mostrado en la figura El cruce se realiza entre las dimensiones tiempo, proyecto de presupuesto y región, para obtener un dato de la métrica presupuesto modificado (mostrado en negritas en la figura 3.37). Figura 3.36 Consulta con el addin de Excel al data mart de Infraestructura con información de muestra (diseño propio) En la figura 3.38, puede observarse otra de las herramientas de análisis que Oracle Hyperion proporciona para el análisis de información. Se trata de otro addin pero para Microsoft Power Point, conocida como Smart View. Con esta herramienta de análisis, los usuarios pueden elaborar plantillas o insertar reportes o consultas elaboradas con Web Analisys Studio, directamente en una diapositiva de Power Point. Esta funcionalidad permite que cuando un usuario requiere tener al día una presentación, simplemente debe abrir el archivo de Power Point, conectarse al data mart de Infraestructura Carretera y actualiza los datos. 125

139 Proyecto Tiempo Enero Febrero Mazo K K K Zacatecas SLP Nayarit Región Figura 3.37 Cruce entre las dimensiones tiempo, proyecto de presupuesto y región, para obtener un dato de la métrica presupuesto modificado (diseño propio). Figura 3.38 Addin de Power Point para elaborar plantillas de consulta al data mart de Infraestructura (diseño propio) 126

140 3.8 Seguridad de la información Como en todo sistema de información computarizado, la seguridad de la información es un aspecto muy importante. En el caso del SIE de Infraestructura, existen dos esquemas de seguridad que deben ser protegidos. 1) Acceso a la base de datos multidimensional. 2) Acceso a los reportes prediseñados que conforman al SIE. El primero se refiere al control de acceso a la base de datos o data mart de Infraestructura. La información puede ser consultada desde la aplicación del Sistema de Información Ejecutivo o desde las herramientas de análisis (addin de Excel y de Poder Point). Por lo que en este rubro se deben controlar los accesos de lectura, escritura, administración del data mart o ejecución de cálculos. El segundo control se refiere a la definición de privilegios para que los usuarios puedan acceder a un determinado conjunto de reportes, de acuerdo a sus necesidades de información. Como se explicó en el punto 3.7 Interfaces gráficas para el usuario final, se generaron grupos de reportes por cada área usuaria del sistema. En este sentido, es necesario definir privilegios de acceso por grupo de reportes. Con respecto al primer punto, la visualización de la información almacenada en el data mart está controlada por un sistema de control de accesos por grupos de usuario, lo cual impide que personas no autorizadas realicen modificaciones o simplemente tengan acceso a la información. El control de accesos por grupos de usuarios se controla desde la consola de administración del motor OLAP. A esta consola de administración se le conoce como Analytic Administration Services (ver figura 3.39). 127

141 Figura 3.39 Consola de administración de usuarios (diseño propio) En la consola de administración se definen grupos de trabajo y a cada grupo se le asignan los privilegios de lectura o escritura hacia el data mart. Es importante mencionar que cada grupo de usuarios puede tener acceso a más de un data mart con diferente tipo de privilegios de lectura, escritura, administración o cálculo. En la figura 3.40 se presenta la ventana de administración para el grupo de usuarios de la Dirección General de Conservación de Carreteras (DGCC). Se puede observar que los usuarios que tengan acceso al data mart de Infraestructura (nombrado Infra09), tendrán acceso de solo lectura a la información (Read). 128

142 Figura 3.40 Definición de privilegios de acceso por grupo de usuarios (diseño propio) Por otro lado, el control de acceso a los grupos de reportes por cada área usuaria del sistema, se realiza por medio de otra herramienta de la misma plataforma de inteligencia de negocios de Oracle Hyperion, llamada Workspace (ver figura 3.41). En el Workspace se establecen los privilegios de acceso a los grupos de reportes que cada usuario puede visualizar. Eso se define de acuerdo al área a la que pertenece el usuario o sus necesidades de consulta de información. 129

143 Figura 3.41 Control de acceso a grupo de reportes por medio de Workspace (diseño propio) En la figura 3.42, puede observarse la definición de acceso que se le dio al grupo de usuarios de la Dirección General de Conservación de Carreteras (DGCC). Puede visualizarse que a este grupo solamente se le dio privilegios de consulta (vista) de cuatro posibles opciones (sin acceso, vista, modificación o control total). Esta es la forma en la que se controla el acceso a la información del Sistema de Información Ejecutivo de Infraestructura. Los privilegios de acceso se asignan a nivel de base de datos y a nivel de aplicación. 130

144 Figura 3.42 Definición de privilegios de acceso al grupo de reportes de la DGCC (diseño propio) 131

145 Capitulo 4 Impacto de la propuesta de solución. El propósito de este trabajo fue diseñar una solución de software basada en tecnología de inteligencia de negocios (business intelligence) y su implementación en la Secretaría de Comunicaciones y Transportes, particularmente enfocada a la administración del presupuesto de gasto de inversión que se destina a la construcción y conservación de carreteras federales. Este tipo de presupuesto es ejercido por las unidades administrativas representativas de la Secretaría en los Estados, conocidas como Centros SCT y que tienen entre otras de sus funciones la construcción, modernización y conservación de infraestructura carretera, aeroportuaria, portuaria y de comunicaciones del país. Este trabajo se llevo a cabo analizando las necesidades de información del personal de mando de la Dirección General de Carreteras, de la Dirección General de Conservación de Carreteras y de la Dirección General de Servicios Técnicos. Estas Direcciones Generales están a cargo de la Subsecretaría de Infraestructura de la SCT. La medición del impacto que tuvo la implementación del Sistema de Información Ejecutivo de Infraestructura, es el tema tratado en este capítulo. Se describe también las pruebas de funcionamiento utilizadas antes de implementar el sistema en el ambiente de producción. 4.1 Desempeño de la aplicación desarrollada Esta sección explica aspectos sobre el desempeño de la aplicación desarrollada como espacio en disco y requerimientos de memoria. Para ello necesitamos entender primero las unidades de almacenamiento que Essbase utiliza para determinar el tamaño de la base de datos desarrollada. Esto lo analizaremos a continuación en el punto Elementos básicos de la arquitectura (dimensiones dispersas y densas) La mayoría de las aplicaciones multidimensionales tienen dos características: Los datos están uniformemente distribuidos. Los datos no existen en la mayoría de las combinaciones de miembros de dimensión. Por ejemplo, los productos de una compañía no se venden en todas las ciudades de un país. 132

146 Essbase maximiza el funcionamiento en estos casos dividendo las dimensiones estándar en dos tipos: dimensiones densas y dimensiones dispersas. Esto le permite a Essbase resolver el problema de los datos que no están uniformemente distribuidos. Essbase acelera la recuperación de datos al mismo tiempo que minimiza la memoria utilizada y los requerimientos de espacio en disco. La mayoría de las bases de datos multidimensionales son dispersas: lo que significa que carecen de valores de datos para la mayoría de las combinaciones de los miembros de dimensión. Por ejemplo, en una base de datos de Ventas que cuente con las dimensiones Producto y Mercado, en donde Producto represente los tipos de productos que vende una empresa y Mercado represente la región geográfica en los cuales los productos son vendidos. La combinación de estas dos dimensiones generaría celdas sin valores o valores nulos, debido a que no todos los productos se venden en todos los mercados. Por lo tanto, las dimensiones Mercado y Producto son dimensiones dispersas. La mayoría de las bases de datos multidimensionales también contienen dimensiones densas. Una dimensión densa es una dimensión con una alta probabilidad de que una o más celdas sean ocupadas con valores en cada combinación de dimensiones. Siguiendo nuestro ejemplo de la base de datos de Ventas, supongamos que también tiene la dimensión Año. Esta dimensión puede representar el tiempo en meses. Debido a que la venta de un producto siempre tendrá relacionado el mes en el que se efectuó, entonces también es muy probable que siempre exista al menos un valor al combinar la dimensión Año con las dimensiones Producto y Mercado. Por lo tanto, la dimensión Año sería una dimensión densa. Essbase utiliza dos tipos de estructuras internas para almacenar los datos: bloques de datos y el sistema de indexación. 50 Essbase crea un bloque de datos para cada combinación única de dimensiones dispersas (siempre que exista al menos un valor para la combinación generada). El bloque de datos representa a todas las dimensiones densas por su combinación con las dispersas. 50 Hyperion Solutions Corporation. ( ). Analytic Services Database Administrator's Guide. Sunnyvale, CA. 133

147 Entonces se crea una entrada de índice para cada bloque de datos. El índice representa las combinaciones de las dimensiones dispersas. Contiene una entrada para cada combinación única de dimensiones dispersas para las cuales existe al menos un valor de datos. En la figura 4.1, las dimensiones Producto y Mercado son dimensiones dispersas. Si existe un dato para Producto 1 en Mercado 1, entonces se creará un bloque de datos y una entrada de índice para la combinación de los miembros dispersos Producto 1 -> Mercado 1. Pero si Producto 1 no es vendido en Mercado 2, entonces no se creará un bloque de datos ni una entrada de índice para la combinación de dimensiones dispersas Producto 1 -> Mercado 2. Figura 4.1 Ejemplo de dimensiones dispersas (diseño propio). Puede considerarse que cada valor único de datos existe en una celda dentro de un bloque de datos. Cuando Essbase busca un valor, usa el índice para localizar el bloque de datos apropiado como se muestra en la figura 4.2. Después, ya estando dentro del bloque, localiza la celda que contiene el valor buscado. La entrada de índice provee un apuntador hacia el bloque de datos. El índice recupera datos dispersos de manera eficiente porque solo incluye apuntadores a bloques de datos existentes. Índice 2 5 Bloques de datos Figura 4.2 Representación de bloques de datos y del índice que almacena los apuntadores a cada bloque (diseño propio) Cada bloque representado en la figura 4.2 puede contener uno o más valores, según la combinación de las dimensiones densas que contenga el bloque. Supongamos que adicionalmente a la dimensión densa Año, la base de datos también tenga las dimensiones densas Métricas y Escenario. Como ya se 134

148 mencionó anteriormente, un bloque de datos se genera para cada combinación única de miembros de las dimensiones dispersas Producto y Mercado (siempre que exista al menos un valor para la combinación generada). Cada uno de esos bloques va a contener las celdas generadas por la combinación de las dimensiones densas Año, Métricas y Escenario, como se puede observar en la figura 4.3. Es importante mencionar que las celdas generadas pueden o no contener valores. Sin embargo, definiendo una configuración de dimensiones dispersas y densas apropiada, es menos probable que se generen celdas con valores nulos, lo cual representa una optimización de la base de datos en cuanto a espacio de almacenamiento y uso de memoria. Figura 4.3 Representación de un bloque de datos (diseño propio) Cada bloque de datos es un arreglo multidimensional que contiene una localización fija para cada posible combinación de dimensiones densas. Essbase ordena las celdas en un bloque de datos, de acuerdo al orden de los miembros de las dimensiones densas en la base de datos. Supongamos que la base de datos se definió de acuerdo al orden en el listado de dimensiones densas y dispersas de la figura

149 Figura 4.4 Base de datos con dimensiones dispersas y densas (Analytic Services Database Administrator s Guide) La figura 4.5 es una representación del árbol de dimensiones de la figura 4.4. El bloque de datos que se muestra es el que se obtiene mediante la combinación de los miembros de dimensión dispersos d22 y e3 (d22 -> e3). Dentro del bloque de datos, se señala con una flecha la celda que contiene el valor referenciado por la combinación de dimensiones densas A, b21 y c3 (A -> b21 -> c3). Figura 4.5 Bloque de datos que representa la combinación de dimensiones densas para d22 -> e3 (Analytic Services Database Administrator s Guide) Se crea un bloque de datos para cada combinación única de los miembros de las dimensiones dispersas D y E (siempre que exista al menos un valor para la combinación). Los bloques de datos, como el mostrado en la figura 4.5, pueden incluir celdas que no contengan valores. Un bloque de datos es creado si al menos existe un valor en el bloque. Essbase comprime los bloques de datos con valores nulos (missing values) en disco, expandiéndolos totalmente conforme se van trayendo hacia la memoria. La compresión de datos es opcional, pero se habilita por default cuando se construye una base de datos multidimensional. 136

150 Seleccionando cuidadosamente las dimensiones dispersas y densas, podemos asegurarnos de que los bloques no contengan demasiadas celdas vacías. Con esto se puede minimizar el espacio en disco y maximizar la ejecución de la aplicación. En la tabla 4.1, se muestra la configuración de dimensiones densas y dispersas definida para la base de datos que se desarrollo en este trabajo. Podrá observarse también que se agregó la columna Atributo de almacenamiento, la cual contiene los siguientes valores, según la dimensión de que se trate: Almacenar dato. La dimensión almacena sus valores físicamente en la base de datos, utilizando espacio en disco. Cálculo dinámico. No utiliza espacio en disco duro puesto que sus miembros obtienen sus valores en tiempo de ejecución. El valor no se calcula hasta que un usuario lo solicita y después el valor es desechado. 51 Sólo etiqueta. No utiliza espacio en disco duro puesto que sus miembros se utilizan como una forma de clasificar los valores almacenados. Número de dimension Nombre de la dimensión Configuración Atributo de almacenamiento 1 Centro de trabajo Dispersa Almacenar dato 2 Tiempo Densa Almacenar dato 3 Avance Dispersa Solo etiqueta 4 Dato Dispersa Solo etiqueta 5 Año Dispersa Almacenar dato 6 Financiamiento Dispersa Almacenar dato 7 Métricas Densa Solo etiqueta 8 Programa operativo Dispersa Almacenar dato 9 Programa de presupuesto Dispersa Almacenar dato 10 Centro SCT Dispersa Almacenar dato 11 Proyecto Dispersa Almacenar dato Tabla 4.1 Configuración de las dimensiones de la base de datos desarrollada (diseño propio) Estimación de espacio en disco. Antes de estimar el espacio requerido en disco para la base de datos construida, debemos conocer cuantas dimensiones incluye la base de datos, qué tan densas 51 Hyperion Solutions Corporation. ( ). Analytic Services Database Administrator's Guide. Sunnyvale, CA. 137

151 o dispersas son las dimensiones, el número de miembros en cada dimensión y cuántos de los miembros son miembros almacenados en disco (ver tabla 4.1). Para determinar el tamaño estimado de la base de datos, es necesario primero calcular algunos factores como: el número potencial de bloques de datos, el número de bloques existentes y el tamaño del bloque de datos expandido. A continuación se mencionan también las características del servidor de la base de datos en la cual se está ejecutando la aplicación. Características del servidor de base de datos. Las características del servidor en el que se está ejecutando la base de datos, son las siguientes: Procesador: 2 procesadores Core 2 Duo 2.80 GHz. Memoria: 8 Gb. Almacenamiento en disco duro: 68 Gb. Sistema operativo: Windows 2003 Cálculo del número potencial de bloques de datos. El número potencial de bloques de datos es el número máximo de posibles bloques que se generarán en la base de datos. Para determinar este valor, se asumirá que existen valores de datos para todas las combinaciones de los miembros de dimensión almacenados. 1. Usando el listado de la tabla 4.1, identificaremos las dimensiones dispersas y el número de miembros de dimensión cuyo atributo de almacenamiento sea Almacenar dato. En la tabla 4.2, se muestra el resultado de este análisis. Nombre de la dimensión Número de miembros almacenados Centro de trabajo 5 Avance 2 Dato 2 Año 3 Financiamiento 5 Programa operativo 34 Programa de presupuesto 3 Centro SCT 44 Proyecto 1795 Tabla 4.2 Dimensiones dispersas cuyo atributo de almacenamiento es Almacenar dato (diseño propio) 138

152 2. Multiplicar el número de miembros almacenados obtenidos en el punto anterior. Número potencial de bloques de datos = 5*2*2*3*5*34*3*44*1,795 = 2,416,788,000 Número de bloques existentes. En comparación con el número de bloques potenciales que se pueden crear, el termino bloques existentes se refiere a aquellos bloques de datos que Essbase realmente crea. Recordemos que para que se genere un bloque, debe existir al menos un valor para una combinación de miembros almacenados de dimensiones dispersas. Debido a que muchas combinaciones pueden resultar en valores nulos, el número de bloques existentes es generalmente mucho menor que el número potencial de bloques de datos. Para estimar el número de bloques de datos existentes, se realiza lo siguiente: 1. Estimar un factor de densidad de la base de datos que represente el porcentaje de combinaciones de dimensiones dispersas con miembros almacenados, que tengan valor. Este factor de densidad lo obtendremos de un parámetro que Essbase proporciona, una vez que se ingresa la estructura de la base de datos y se realiza la configuración de dimensiones densas y dispersas. En este caso, el factor de densidad calculado fue de 1% (porcentaje máximo de bloques existentes). 2. Multiplicar este porcentaje contra el número potencial de bloques de datos. Número de bloques existentes =.01 (densidad estimada) * 2,416,788,000 (número potencial de bloques de datos) = 24,167,880 Tamaño de bloque de datos expandido. El tamaño potencial de los bloques de datos se basa en el número de celdas en el bloque y el número de bytes usados por cada celda. El número de celdas en un bloque se basa en el número de miembros almacenados en las dimensiones densas. Se usan 8 bytes para almacenar cada intersección de datos en un bloque. Para determinar el tamaño de un bloque expandido, se ejecutan las siguientes tareas. 1. Usando el listado de la tabla 4.1, identificaremos las dimensiones densas y el número de miembros de dimensión cuyo atributo de almacenamiento sea Almacenar dato. En la tabla 4.3, se muestra el resultado de este análisis. 139

153 Nombre de la dimensión Número de miembros almacenados Tiempo 379 Tabla 4.3 Dimensiones densas cuyo atributo de almacenamiento es Almacenar dato (diseño propio) 2. Multiplicar el número de miembros almacenados obtenidos en el punto anterior. Número total de celdas = 379*8 = 3, Multiplicar el resultado anterior por 8 bytes para determinar el tamaño de bloque expandido. Tamaño de bloque expandido = 3,032 * 8 = 24,256 bytes Estimación de espacio en disco. Para estimar el espacio en disco que ocupará la implementación de la base de datos, es necesario calcular el espacio de almacenamiento en disco requerido para los archivos de datos, el tamaño de los archivos de índice y el tamaño de la estructura de la base de datos definida (outline). Tamaño de los archivos de datos. Para calcular el espacio requerido para almacenar archivos de datos, se utilizan los siguientes factores: Número de bloques existentes. 72 bytes por cada bloque generado. Tamaño en bytes del bloque de datos expandido. Con base en estos factores, se aplica la siguiente fórmula: Espacio requerido para los archivos de datos = Número de bloques existentes * (72 bytes por bloque + tamaño en bytes de bloque de datos expandido). Para la base de datos implementada, el cálculo es el siguiente: Espacio requerido para los archivos de datos = 24,167,880 * ( ,256) = 587,956,184,640 bytes = 547 Gb 140

154 Archivo de índice. El cálculo para el espacio requerido del archivo de índice, utiliza los siguientes factores: Número de bloques existentes. 112 bytes. Tamaño de una entrada en el índice. Para calcular el tamaño del índice de la base de datos, incluyendo todos los archivos de índice, se utiliza la siguiente fórmula: Tamaño de índice de la base de datos = número de bloques existentes * 112 bytes Para la base de datos implementada, el cálculo es el siguiente: Tamaño de índice de la base de datos = 24,167,880 * 112 = 2,706,802,560 bytes = 2.5 Gb Tamaño de la estructura de la base de datos definida (outline). El outline es el área donde se almacena la estructura de la base de datos y es un componente que requiere de almacenamiento en disco y en memoria (el espacio requerido de memoria se calcula más adelante). Se calcular con base en los siguientes factores: El número de miembros en el outline. El tamaño, en caracteres, de los nombres de los miembros y alias. Para estimar el tamaño del archivo del outline, se realiza el siguiente cálculo: Multiplicar el número de miembros almacenados en todas las dimensiones por un factor que indique el tamaño de los nombres de miembro y de sus alias. Este factor puede estar entre 350 y 450 bytes. Para la base de datos implementada se usara un factor de 450 bytes, ya que se utilizaron alias básicamente en los miembros de la dimensión Proyecto para describir los proyectos de obra a ejecutar. Estas descripciones suelen ser grandes. Tamaño de almacenamiento del outline = número de miembros almacenados en todas las dimensiones * factor del tamaño de nombres de miembros y de sus alias. Para la base de datos implementada, el cálculo es el siguiente: Tamaño de almacenamiento del outline = 2,281 * 450 = 1,026,450 bytes = 1 Mb 141

155 4.1.3 Estimación de espacio en memoria. Para calcular el espacio requerido de memoria para ejecutar la aplicación, se utilizaran otros cálculos realizados en la sección anterior. Tamaño del outline usado en memoria. Para calcular el espacio en memoria utilizado por el outline, se utilizan los siguientes factores: El número de miembros en el outline. El tamaño, en caracteres, de los nombres de los miembros y alias. Para estimar el espacio en memoria requerido por el outline, se realiza el siguiente cálculo: Multiplicar el número de miembros almacenados en todas las dimensiones por un factor que indique el tamaño de los nombres de miembro y de sus alias. Este factor puede estar entre 300 y 400 bytes. Para la base de datos implementada se usara un factor de 400 bytes, ya que se utilizaron alias básicamente en los miembros de la dimensión Proyecto para describir los proyectos de obra a ejecutar. Estas descripciones suelen ser grandes. Tamaño de memoria para el outline = número de miembros almacenados en todas las dimensiones * factor del tamaño de nombres de miembros y de sus alias. Para la base de datos implementada, el cálculo es el siguiente: Tamaño de memoria para el outline = 2,281 * 400 = 912,400 bytes = 891 Kb Número de celdas en un bloque lógico. El término bloque lógico se refiere a un bloque de datos expandido en memoria. Para determinar el número de celdas en un bloque lógico, se multiplica el número de miembros de cada dimensión densa (incluyendo los cálculos dinámicos pero se excluyen las que son Solo etiqueta ). Revisando la tabla 4.1, se tienen solo dos dimensiones densas, tiempo y métricas. Tiempo es una dimensión densa cuyo atributo de almacenamiento es Almacenar dato y tiene 379 miembros (ver tabla 4.3). Sin embargo, métricas es de tipo Solo etiqueta. Por lo que el cálculo del número de celdas en un bloque lógico para la base de datos implementada, es el siguiente: Número de celdas en un bloque lógico =

156 Área de memoria para estructuras de datos. Para cada aplicación en tiempo de ejecución, se asigna un espacio de memoria basada en los siguientes factores: Número de miembros en el outline. Número de celdas en un bloque lógico. Número de hilos (threads) en el servidor. Se usa la siguiente fórmula para calcular el tamaño en bytes del área de memoria requerida para procesar la estructura de datos de que consta la base de datos implementada: Número de hilos * ((número de miembros en el outline * 26 bytes) + (número de celdas en un bloque de datos * 36 bytes)) Para la base de datos implementada se utiliza por default 1,024 hilos (para plataformas de 64 bits). 1,024 * ((2,281 * 26 bytes) + (379 celdas * 36 bytes)) = 74,700,800 bytes = Mb 4.2 Pruebas de funcionamiento Una vez diseñado e implementado el data mart, fue necesario realizar una serie de pruebas de carga de información hacia el mismo. Como se explicó en el punto Descripción de los procesos desarrollados, la información se extrae de las fuentes de datos hacia archivos planos y posteriormente se carga al data mart mediante programas llamados reglas de carga que sirven para estructurar los datos antes de poder ser importados (ver figura 4.6). Cada dato a importar a la base de datos, deberá tener un cruce de información con cada una de las dimensiones que la conforman. Es decir, una vez importada la información, cada dato almacenado puede ser recuperado solamente si se hace un cruce de información con todas las dimensiones que conforman la estructura de la base de datos. Las reglas de carga sirven para estructurar la información y ajustarla a la base de datos multidimensional. 143

157 Figura 4.6 Ejemplo de regla de carga de información hacia la base de datos (definición de regla de carga en Essbase) Al inicio de la implementación puede resultar complicado pensar en dimensiones de base de datos, porque generalmente estamos acostumbrados a manejar bases de datos relacionales. Sin embargo, el manejo de una base de datos multidimensional es un concepto muy diferente al diseño de una relacional que solo con la práctica puede lograrse. Para importar información y determinar si el diseño planteado en el punto Diseño conceptual del SIE analizado en el capítulo anterior, cumple con las necesidades de información planteadas al inicio del proyecto, fue necesario construir catorce reglas de carga para lograr importar la información de los archivos planos y transformarlos a la estructura que requiere la base de datos multidimensional del data mart. Se generaron reglas de carga para importar información de los siguientes rubros: Avances físicos y financieros, comprometidos y ejercidos. Modificaciones al presupuesto de los proyectos de obra. Presupuesto original, modificado y disponible de proyectos de gasto de inversión (capítulo de gasto 6000). 144

158 Catalogo de obras, de proyectos presupuestales, de programas operativos y de tipos de contratos. Una vez construidas las reglas de carga, se ejecuta la importación de datos mediante la ejecución de un scrip que contiene instrucciones de un lenguaje de programación nativo de Oracle Hyperion Essbase llamado ESSCMD (essbase command). El scrip utilizado se muestra en la figura 4.7. Figura 4.7 Scrip de importación y ejecución de cálculo de la base de datos multidimensional del data mart (diseño propio) Finalmente, por medio de un archivo log que la misma base de datos genera, se puede detectar si hubo algún problema durante la importación de los datos o si ésta se concluyo sin ningún error. En la figura 4.8, se muestra un ejemplo del archivo log generado para una importación sin errores. El último paso en las pruebas de funcionamiento del data mart, fue desarrollar un conjunto de reportes mediante los cuales los usuarios pudieran verificar la calidad de la información. Parte de esos reportes desarrollados son los que se ejemplifican en el punto 3.7 Interfaces gráficas para el usuario final, analizado en el capítulo anterior. Después de haber hecho las pruebas de rendimiento de la base de datos y una vez que los usuarios verificaron la calidad de la información mediante el conjunto de reportes que conforman el Sistema de Información Ejecutivo de Infraestructura, 145

159 se procedió a automatizar los procesos de extracción, transformación y carga de datos y el SIE fue liberado a producción para su uso cotidiano. Figura 4.8 Archivo log generado por la base de datos, durante la importación de información al data mart de Infraestructura Carretera (Oracle Hyperion Essbase) Cabe mencionar que además de tener acceso al Sistema de Información Ejecutivo, los usuarios utilizan las herramientas de análisis explicadas en el punto Herramientas de análisis, tratado al final del capítulo Medición de la calidad del software elaborado Después de haber hecho las pruebas de funcionamiento del Sistema de Información Ejecutivo de Infraestructura y una vez que fue implementado, era necesario determinar su impacto en un ambiente de producción. Para ello, se aplicó un cuestionario de evaluación para medir diferentes aspectos sobre la calidad del software desarrollado y la satisfacción de los usuarios en su operación. Se diseño un formato de respuesta (cuestionario) de tipo Likert (ver anexo 1). Cuando se responde a un elemento de un cuestionario elaborado con la técnica 146

160 de LIkert, se hace especificando el nivel de acuerdo o desacuerdo con la pregunta o reactivo que se esté aplicando. Para la presentación de los resultados obtenidos, utilicé uno de los cuatro usos que se le pueden dar a un cuestionario que tiene por objetivo evaluar la satisfacción de los clientes. Se llama resumen de los datos con estadísticas descriptivas. 52 Un cuestionario confiable tendría muy poco valor práctico si la información obtenida no fuera comprensible. El cuestionario aplicado presenta doce reactivos, pero se diseño para medir seis aspectos de la calidad del software. Los aspectos de la calidad del software que se desea medir y su relación con las preguntas del cuestionario, se mencionan a continuación: 1. Servicio (preguntas 1 y 2) 2. Confiabilidad (preguntas 3 y 4) 3. Valor práctico (preguntas 5 y 6) 4. Facilidad de revisión (preguntas 7 y 8) 5. Flexibilidad (preguntas 9 y 10) 6. Satisfacción global (preguntas 11 y 12) El cuestionario fue aplicado a treinta usuarios del Sistema de Información Ejecutivo de Infraestructura. Esta cantidad de usuarios corresponde al total de usuarios que utilizan el software en Oficinas Centrales de la SCT. Los datos resultantes de la aplicación de este cuestionario se muestran en la figura 4.9. Se puede observar que se han calculado también el promedio aritmético y la desviación estándar de cada pregunta. La media indica la tendencia predominante de los datos, en tanto que la desviación estándar describe la dispersión de los datos. La ecuación que se utilizó para obtener la media, es la siguiente: 52 Hayes, B. E. (2006). Cómo medir la satisfacción del cliente. México: Alfaomega. P

161 La fórmula que se utilizó para el cálculo de la desviación estándar es: Elementos de satisfacción Cliente Media Desviación estandar Figura 4.9 Datos resultantes de la aplicación del cuestionario para evaluar la calidad del software desarrollado (diseño propio) 4.4 Análisis de los resultados obtenidos Se podría decir que los datos que se visualizan en la tabla de la figura 4.2, son datos en bruto que realmente no ayudan a determinar de forma precisa la calidad 148

162 del software desarrollado. Son un conjunto de datos que dan una idea sobre el aspecto general del desempeño de la aplicación. Sin embargo, es necesario resumir los datos aun más para determinar de manera más clara la calidad del Sistema de Información Ejecutivo de Infraestructura. Una forma de resumir los datos consiste en emplear índices de resumen que describan los aspectos importantes de los datos. Los índices de resumen que describen una muestra de datos se llaman estadísticos. 53 Los estadísticos que resumen los elementos de un conjunto de datos reflejan la tendencia principal de éstos y la dispersión de los datos. A continuación se muestran las puntuaciones resumen de cada uno de los aspectos a medir para determinar la calidad del software desarrollado en los seis rubros indicados en el punto 4.2. Tales puntuaciones representan el promedio de las respuestas a cada pregunta dentro de cada aspecto específico. Por cada aspecto a medir, se muestra una gráfica con la cual se trata de dar una interpretación de la puntuación resumen y una breve descripción del resultado obtenido. 1. Servicio Servicio Media 4.02 Desviación estandar 0.79 Lo que se puede apreciar de la gráfica es que los usuarios en promedio consideran que el software les proporciona un buen servicio, ya que les 53 Ibid., p

163 ayuda en su trabajo porque cumple con las especificaciones necesarias para realizarlo. 2. Confiabilidad Confiabilidad Media 3.98 Desviación estandar 0.74 Se puede observar que los usuarios en su mayoría, pueden confiar en la operación y en la información que el software les proporciona, ya que les da la facilidad de ejecutar las funciones del sistema con precisión y exactitud. 3. Valor práctico Valor práctico Media 4.18 Desviación estandar 0.74 Prácticamente la mayoría de los encuestados opinaron que el software es fácil de operar y que sus funciones son fáciles de comprender. 150

164 4. Facilidad de revisión Facilidad de revisión Media 4.00 Desviación estandar 0.75 En promedio, la mayoría de los usuarios opinaron que fue rápido y sencillo verificar la funcionalidad del software. Esto hace pensar que es fácil de usar y de aprender. Sin embargo, será necesario investigar los aspectos que no hacen al software lo suficientemente amigable en su operación. 5. Flexibilidad Flexibilidad Media 4.18 Desviación estandar 0.85 Los resultados para medir la flexibilidad en la operación del software desarrollado, hacen pensar que será sencillo para los usuarios utilizar la el sistema para generar consultas y reportes de sus áreas. Es importante 151