T E S I S

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
II
III
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
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
Índice
Relación de cuadros, gráficas e ilustraciones....................................................................... IX
Glosario ........................................................................................................................................ 1
Introducción ................................................................................................................................. 3
Capitulo 1 Inteligencia de negocios. ................................................................................... 6
1.1
Sistemas de Información ejecutivos .............................................................................. 8
1.1.1
Características de los Sistemas de Información Ejecutivos ............................ 11
1.1.2
Factores de éxito de un Sistema de Información Ejecutivo ............................. 12
1.1.3
Beneficios de un Sistema de Información Ejecutivo ......................................... 13
1.1.4
Desarrollo de un Sistema de Información Ejecutivo ......................................... 14
1.1.5
Como mejoran los SIE el proceso de toma de decisiones .............................. 16
1.2
Concepto de data warehouse ....................................................................................... 17
1.2.1
Características de un data warehouse ................................................................ 19
1.2.2
Implementación de un data warehouse en la organización ............................. 20
1.2.3
Personal que participa en la implementación de un data warehouse ............ 23
1.2.4
Arquitectura para la construcción de un data warehouse ................................ 25
1.2.5
Diferencia entre un data warehouse y una base de datos relacional ............ 28
1.2.6
El data warehouse como un sistema de misión crítica ..................................... 31
1.2.7
Relación de un SIE con un data warehouse ...................................................... 34
1.2.8
Ventajas y desventajas en el uso de un data warehouse ................................ 36
1.3
Concepto de data mart .................................................................................................. 37
1.3.1
Construcción de un data mart............................................................................... 37
1.3.2
Requerimientos para la construcción de un data mart ..................................... 40
1.3.3
Data mart distribuido .............................................................................................. 44
1.3.4
La complejidad de transformar datos en información en una solución de data
warehousing ............................................................................................................................ 45
1.4
Modelo de datos multidimensional .............................................................................. 46
VI
1.4.1
Modelo de estrella .................................................................................................. 52
1.4.2
Modelado de consultas empresariales ................................................................ 53
1.5
Minería de datos (data mining) ..................................................................................... 54
Capitulo 2 La Subsecretaría de Infraestructura de la SCT ........................................... 62
2.1
La Subsecretaría de Infraestructura ............................................................................ 63
2.2
La Dirección General de Carreteras (DGC) ............................................................... 64
2.3
La Dirección General de Conservación de Carreteras (DGCC) ............................. 65
2.4
La Dirección General de Servicios Técnicos (DGST)............................................... 65
2.5
Información a analizar en las áreas involucradas .................................................... 66
Capitulo 3 Diseño y desarrollo de la propuesta de solución ......................................... 71
3.1
Planteamiento del problema ......................................................................................... 72
3.2
Objetivos de este proyecto............................................................................................ 73
3.3
Metodología utilizada ..................................................................................................... 74
3.4
Análisis FODA de la solución ....................................................................................... 75
3.5
Diseño lógico del Sistema de Información Ejecutivo de Infraestructura ................ 75
3.5.1
Requerimientos de información............................................................................ 75
3.5.2
Análisis de requerimientos .................................................................................... 79
3.5.3
Descripción funcional del SIE ............................................................................... 82
3.5.4
Descripción de los procesos desarrollados ........................................................ 84
3.5.5
Parámetros de información que los usuarios pueden consultar ................... 104
3.5.6
Diseño de consultas empresariales ................................................................... 107
3.5.7
Herramienta que se utilizó para la implementación ........................................ 109
3.6
Diseño físico de la base de datos .............................................................................. 110
3.6.1
3.7
Desarrollo del data mart ...................................................................................... 111
Interfaces gráficas para el usuario final .................................................................... 117
3.7.1
Herramientas de análisis ..................................................................................... 123
VII
3.8
Seguridad de la información ....................................................................................... 127
Capitulo 4 Impacto de la propuesta de solución. .......................................................... 132
4.1
Desempeño de la aplicación desarrollada................................................................ 132
4.1.1
Elementos básicos de la arquitectura (dimensiones dispersas y densas) .. 132
4.1.2
Estimación de espacio en disco. ........................................................................ 137
4.1.3
Estimación de espacio en memoria................................................................... 142
4.2
Pruebas de funcionamiento ........................................................................................ 143
4.3
Medición de la calidad del software elaborado ........................................................ 146
4.4
Análisis de los resultados obtenidos ......................................................................... 148
Conclusiones ........................................................................................................................... 153
Bibliografía ............................................................................................................................... 156
Anexo I ..................................................................................................................................... 158
VIII
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) .............................................................................................................................................. 22
Figura 1.2 Arquitectura de referencia del data warehouse (Gill, H. S.) ................................. 26
Figura 1.3 Ciclo de madurez de la tecnología (Gill, H. S.) ....................................................... 33
Figura 1.4 Flujo de información entre un SIE y un data warehouse (diseño propio) ........... 34
Tabla 1.1 Ventajas y desventajas del uso de un data warehouse (diseño propio) .............. 36
Figura 1.5. Proceso de transformación de datos en información en una solución de data
warehousing (diseño propio) ........................................................................................................ 45
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) .................................................................................. 48
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) .............................................................................................................................................. 48
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)................... 49
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
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)................. 50
Figura 1.9 Modelo de estrella (diseño propio) ........................................................................... 53
Figura 1.10. Modelo de molde de consulta (Gill, H. S.) ............................................................ 53
Figura 1.11. La minería de datos como un paso en el proceso de descubrimiento de
conocimiento (Han, Jiawei) .......................................................................................................... 55
Figura 1.12. Arquitectura general de un sistema de minería de datos (Han, Jiawei) .......... 58
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
IX
Figura 2.2. Proceso de ejercicio del presupuesto en obra pública (diseño propio) ............. 68
Tabla 3.1 Análisis FODA para la implementación del SIE (diseño propio) ........................... 77
Figura 3.1. Construcción de los diferentes data mart para la SCT (diseño propio) ............. 82
Figura 3.2. Modelo de referencia propuesto para el Sistema de Información Ejecutivo de
Infraestructura (diseño propio) ..................................................................................................... 83
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) .... 87
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) ................................................................. 87
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) ............................... 90
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) ......................................................................... 91
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) ......................................................................... 92
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) ..................... 92
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)............................................................... 93
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) ............................................... 94
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) ............................................. 94
Figura 3.12. Modelo de estrella del SIE (diseño propio) .......................................................... 97
Figura 3.13 Implementación de la dimensión Métricas (diseño propio) .............................. 104
Figura 3.14 Molde de consulta empresarial de Presupuesto (diseño propio) .................... 108
Figura 3.15 Molde de consulta empresarial de Programa Operativo (diseño propio) ....... 108
Figura 3.16. Implementación de la dimensión Total Anual (diseño propio) ........................ 112
Figura 3.17. Implementación de la dimensión Centro SCT (diseño propio) ....................... 113
X
Figura 3.18. Implementación de la dimensión Proyecto en los niveles de grupos de
presupuesto y de tipo de contrato (diseño propio) .................................................................. 114
Figura 3.19 Implementación de la dimensión Proyecto en los niveles de obra y de contrato
(diseño propio) .............................................................................................................................. 114
Figura 3.20 Implementación de la dimensión Avance (diseño propio) ................................ 115
Figura 3.21 Implementación de la dimensión Programa Operativo (diseño propio) ........ 115
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) ................. 116
Figura 3.24 Implementación de la dimensión Financiamiento (diseño propio) ............. 116
Figura 3.25 Implementación de la dimensión Año (diseño propio) ...................................... 117
Figura 3.26 Implementación de la dimensión Dato (diseño propio) ..................................... 117
Figura 3.27 Página de inicio de SIE de Infraestructura (diseño propio) .............................. 117
Figura 3.28 Grupo de reportes para la Dir. Gral. de Carreteras Federales (diseño propio)
......................................................................................................................................................... 118
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) .............................................................................................................................. 119
Figura 3.31 Reporte con información de muestra de obras por Estado de la Dir. Gral. de
Carreteras (diseño propio) .......................................................................................................... 120
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) .... 121
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) .................... 122
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) ................................................ 123
Figura 3.35 Addin de Excel para realizar consultas al data mart de Infraestructura (diseño
propio) ............................................................................................................................................ 124
Figura 3.36 Consulta con el addin de Excel al data mart de Infraestructura con información
de muestra (diseño propio) ......................................................................................................... 125
XI
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). ............................. 126
Figura 3.38 Addin de Power Point para elaborar plantillas de consulta al data mart de
Infraestructura (diseño propio) ................................................................................................... 126
Figura 3.39 Consola de administración de usuarios (diseño propio) ................................... 128
Figura 3.40 Definición de privilegios de acceso por grupo de usuarios (diseño propio) ... 129
Figura 3.41 Control de acceso a grupo de reportes por medio de Workspace (diseño
propio) ............................................................................................................................................ 130
Figura 3.42 Definición de privilegios de acceso al grupo de reportes de la DGCC (diseño
propio) ............................................................................................................................................ 131
Figura 4.1 Ejemplo de dimensiones dispersas (diseño propio). ........................................... 134
Figura 4.2 Representación de bloques de datos y del índice que almacena los
apuntadores a cada bloque (diseño propio) ............................................................................. 134
Figura 4.3 Representación de un bloque de datos (diseño propio) ..................................... 135
Figura 4.4 Base de datos con dimensiones dispersas y densas (Analytic Services
Database Administrator’s Guide) ............................................................................................... 136
Figura 4.5 Bloque de datos que representa la combinación de dimensiones densas para
d22 -> e3 (Analytic Services Database Administrator’s Guide) ............................................ 136
Tabla 4.1 Configuración de las dimensiones de la base de datos desarrollada (diseño
propio) ............................................................................................................................................ 137
Tabla 4.2 Dimensiones dispersas cuyo atributo de almacenamiento es “Almacenar dato”
(diseño propio) .............................................................................................................................. 138
Tabla 4.3 Dimensiones densas cuyo atributo de almacenamiento es “Almacenar dato”
(diseño propio) .............................................................................................................................. 140
Figura 4.6 Ejemplo de regla de carga de información hacia la base de datos (definición de
regla de carga en Essbase) ........................................................................................................ 144
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) ....................................................................... 145
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) ........... 146
Figura 4.9 Datos resultantes de la aplicación del cuestionario para evaluar la calidad del
software desarrollado (diseño propio) ....................................................................................... 148
XII
XIII
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
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
Base de datos
multidimensional
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
Clasificador por
objeto del gasto
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-Octubre2000).
Fuente de datos
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
Información no
estructurada
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. 236.
Abadal Falgueras, E. (2001). Sistemas y servicios de información digital. Barcelona: Universidad de
Barcelona. p. 44.
3
Laudon, K. C., & Laudon, J. P. (2004). Sistemas de Información Gerencial.8va. ed. México: Prentice Hall. p.
235.
4
Diccionario de informática e internet: Computer and internet Technology Definitions in Spanish. (2004).
Boston, Massachusetts: Thomson. p. 47.
5
Joaquim, L. (2004). Tecnologías del texto y del habla. Barcelona: Universidad de Barcelona. p. 14.
2
Metadato
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
ODBC
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
OLAP (On Line
Analytical
Processing)
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
Proceso de
negocio
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
RDBMS
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. 293.
Kroenke, D. (2003). Procesamiento de bases de datos. México: Prentice Hall. p. 441.
8
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. 139.
9
Arjona Torres, M. (1999). Dirección estratégica. Un enfoque práctico. Madrid: Diaz de Santos. p. 43.
10
Diccionario de informática e internet: Computer and internet Technology Definitions in Spanish. (2004).
Boston, Massachusetts: Thomson. p. 164.
7
2
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
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
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
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
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. 290.
Laudon, K. (2004). Sistemas de información gerencial: Administración de la empresa digital. México:
Prentice Hall.
12
7
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).13
13
McLeod Jr., Raymond (2000). Sistemas de información gerencial, 7ª ed. Prentice Hall Hispanoamericana, S.
A. México. P. 444.
8
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. 34.
9
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.
68.
10
globales de la institución, datos externos (incluida información acerca de la
competencia) y datos mundiales (con el uso de fuentes como Internet).
1.1.1 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 siguientes16:
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
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.
1.1.2 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
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.
1.1.3 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
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.
1.1.4 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, son17:
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
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
diferenciadas según los usuarios.
de
actualización
y
vistas
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
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.
1.1.5 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
siguientes18:
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. 37-38.
16
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. 292.
17
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
una herramienta de este tipo se requiere una combinación de técnicas,
habilidades, intuición y experiencia por parte de los usuarios.
1.2.1 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
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
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
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
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 siguiente20:
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. 24
23
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
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.
1.2.4 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
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
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 son21:
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. 38.
27
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.
1.2.5 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
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 siguiente23:
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. 290.
23
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. 5.
29
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
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.
1.2.6 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
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 1.324, 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. 20.
32
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
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
Inf ormación
externa a la
organización
Sistema de Inf ormación Ejecutivo
Control de métricas, variables y parámetros
Análisis de inf ormación de: Estados del presupuesto, reportes f inancieros,
consultas de ingresos y egresos, reportes de nómina y plantilla de personal
Análisis
multidimensional
Datawarehouse – Inf ormación actual e histórica
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
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
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.
1.2.8 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
Revisión del modelo de
transacciones, almacenamiento
Integrador de sistemas
Información
consolidada,
consistente, histórica, válida
datos,
objetos,
limpia, Diseño complejo y multidisciplinar
Enfoque al análisis complejo y eficiente
Reestructuración de los sistemas operacionales
Automatizable
Alto costo
Normalizador
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
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áfica25.
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.
1.3.1 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. 541.
37
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
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
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.
1.3.2 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 final26.
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. 22.
40
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
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. 4-29.
42
¿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
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
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
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
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
Localización = "Baja California"
Tipo de trabajo
Tiempo (trimestre) Reconstrucción de puentes Reconstrucción de tramos
1mer trimestre
4777
6580
2do trimestre
8000
15000
3er trimestre
2500
0
4to trimestre
3800
2300
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.
Tiempo (trimestre)
1mer trimestre
2do trimestre
3er trimestre
4to trimestre
Localización = "Nayarit"
Localización = "Baja California"
Tipo de trabajo
Tipo de trabajo
Reconstrucción de puentes
Reconstrucción de tramos Reconstrucción de puentes Reconstrucción de tramos
2250
1250
4750
6580
12000
0
8000
15000
23000
1570
2500
0
1800
300
3800
2300
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
Nayarit
1ro
2250
1250
2do
12000
0
3ero
23000
4to
1800
ió
ac
liz
ca
Lo
1570
n
Baja
California
4750
Baja California
6580
Nayarit
300
Trimestre
Trimestre
Reconstrucción Reconstrucción
de tramos
de puentes
1ro
2250
1250
2do
12000
0
3ero
23000
1570
1800
300
0
00
15
0
00
23
Reconstrucción Reconstrucción
de tramos
de puentes
4to
1ro
4750
6580
Reconstrucción Reconstrucción
de tramos
de puentes
2do
8000
15000
3ro
2500
0
4to
3800
2300
Trimestre
Tipo de trabajo
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”
n
ió
ac
liz
ca
Lo
Centro de trabajo = “CT3”
Baja
California
Nayarit
1ro
Trimestre
Centro de trabajo = “CT2”
2250
1250
2do
3ero
4to
Reconstrucción Reconstrucción
de tramos
de puentes
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
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.
0-D cuboide
Todo
Tiempo
Tiempo,
tipo de trabajo
Tiempo,
localización
Tiempo,
tipo de trabajo,
localización
Tipo de
trabajo
Tiempo,
centro de trabajo
Tiempo,
tipo de trabajo,
centro de trabajo
Localización
Tipo de trabajo,
localización
Centro de
trabajo
Tipo de trabajo,
centro de trabajo
Tiempo,
localización,
centro de trabajo
1-D cuboide
Localización,
centro de trabajo
Tipo de trabajo,
localización,
centro de trabajo
Tiempo,
tipo de trabajo,
localización,
centro de trabajo
2-D cuboide
3-D cuboide
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. 113.
50
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)
es30
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
510 ≈ 9.8 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. 139.
51
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.
1.4.1 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. 31
31
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
http://www.oracle.com/technology/global/lad-es/pub/articles/08-jul/o38olap.html
52
Figura 1.9 Modelo de estrella (diseño propio)
1.4.2 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 1.10. 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
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.33
1.5 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 datos34.
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. 122.
34
Han, J. (2006). Data Mining: Concepts and Techniques. San Francisco, CA.: Morgan Kaufmann. P. 146.
54
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 1.11. La minería de datos como un paso en el proceso de
descubrimiento de conocimiento (Han, Jiawei)
35
Ibid, p. 5.
55
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. 7.
56
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
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 1.12. 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
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 datos37.
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,000.00 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. 147.
59
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
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
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
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 Infraestructura38
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
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
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
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 avance42. 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
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
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
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. 290.
69
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.44
44
Laudon, K. (2004). Sistemas de información gerencial: Administración de la empresa digital. México:
Prentice Hall. p. 316.
70
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
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
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
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. 83-84.
74
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á.
3.5.1 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
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
Tabla 3.1 Análisis FODA para la implementación del SIE (diseño propio)
Fortalezas (F)
1.
2.
3.
4.
1.
2.
3.
4.
1.
2.
Integración de sistemas institucionales.
Alta disponibilidad de la información.
Orientado a la toma de decisiones alineado a la
estrategia de negocio.
Consolidar la información de diversas fuentes.
Debilidades (D)
1.
2.
3.
4.
Poca integración de sistemas internos y externos.
Re-análisis de modelos de datos, objetos, transacciones,
almacenamiento.
Diseño complejo y multidisciplinar.
Se requieren sistemas, aplicaciones y almacenamiento específico.
Adquisición de nuevas
tecnologías y herramientas.
Integración de sistemas
departamentales.
Renovación tecnológica.
Enfoque al análisis para
una mejor toma de
decisiones.
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.
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.
Costos crecientes.
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.
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
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.
3.5.2 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
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
¿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 2007-2012 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
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)
3.5.3 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 6000. 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
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
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.
3.5.4 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
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
Catálogo de corredores carreteros.
Catalogo de tipos de contratos.
Los programas de extracción fueron desarrollados en un 4GL de Progress ver. 9.
1. 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
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
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
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
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
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
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
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
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
391000.99 (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:A010040100 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
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 cuboides46:
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. 140.
95
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 2009. 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. 1991-2002.
96
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
Estado
Mes
Proyecto de
presupuesto
Región
Trimestre
Grupo de
proyecto
Tipo de
contrato
Centro SCT
Tiempo
Proyecto
Año
Número de
año
Dato
Periodicidad
de los datos
Avance
Tipo de
avance
Métricas
Financiamiento
Programa
operativo
Tipo de
recurso
Origen del
recurso
Centro de
trabajo
Programa de
presupuesto
Tipo de
centro de
trabajo
Tipo de
programa
Tipo de
programa
Periodo del
programa
Tipo de
trabajo
Figura 3.12. Modelo de estrella del SIE (diseño propio)
97
En la siguiente tabla se describe cada una de las entidades que se mencionan en
la figura 3.12.
Etiqueta de
Dimensión
Descripción
Métricas
Diferentes flujos de los recursos (por ej. Asignado, Modificado,
Comprometido, etc.). Más adelante se detallan los elementos de
esta dimensión.
Tiempo
Dimensión de tiempo. Contiene el detalle diario de las
operaciones y los acumulados trimestral y mensual.
Centro de
trabajo
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
Avance físico y avance financiero de una obra
Financiamiento
Contiene todas las fuentes de financiamiento (por ej. Recursos
fiscales, Recursos externos)
Programa
operativo
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.
Programa de
presupuesto
Forma parte de la clave presupuestal, mediante la cual se asigna
el presupuesto. Para el año 2009, el programa presupuestal es
cero.
Región
Aguascalientes a Zacatecas organizados por Región (por ej.
noroeste, noreste, centro del país, centro occidente y sursureste)
Proyecto
de Esta dimensión se utiliza para clasificar la información por grupos
presupuesto
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.
Año
Permite guardar información histórica por ejercicio fiscal, a fin de
hacer comparativos de la administración del presupuesto entre
98
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
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
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
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
Información por programa
presupuestal. En el 2009 no
hay programa presupuestal.
Nivel 0
Programa
operativo
Total en todos los programas
operativos
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
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
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
1
2
3
4
5
6
7
8
9
10
11
Nombre de la dimensión
Centro de trabajo
Tiempo
Avance
Dato
Año
Financiamiento
Metricas
Programa operativo
Programa de presupuesto
Centro SCT
Proyecto
Niveles de la
dimensión
2
4
2
2
2
3
2
4
2
3
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.
3.5.5 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
Unidad de
medida
Presupuesto asignado a Pesos
la SCT destinado a la
inversión
en
Descripción
Muestra el presupuesto asignado a
cada Estado en el Presupuesto de
Egresos de la Federación (PEF).
104
infraestructura carretera
Presupuesto modificado
Pesos
Presupuesto
Pesos
comprometido
en
construcción
Presupuesto ejercido
Pesos
Presupuesto
Pesos
comprometido
en
conservación
de
carreteras
Presupuesto disponible
Pesos
Número de kilómetros a Kilómetros
ejecutar en construcción
de carreteras
Número de kilómetros a Kilómetros
ejecutar en conservación
de carreteras
Número de kilómetros Kilómetros
construidos
Número de kilómetros a Kilómetros
los cuales se les ha
dado mantenimiento
Presupuesto en trámite Pesos
de pago
Presupuesto
Pesos
comprometido
en
conservación
de
carreteras por programa
operativo
Presupuesto ejercido en Pesos
conservación
de
carreteras por programa
operativo
Indica el presupuesto disponible por
cada
Estado,
después
de
ampliaciones y reducciones al
presupuesto aplicados por la SHCP.
Indica el presupuesto contratado
por
cada
Estado
para
la
construcción de carreteras.
Este
indicador
muestra
el
presupuesto que ha sido pagado a
los contratistas por la ejecución de
sus servicios.
Indica el presupuesto contratado
por
cada
Estado
para
la
conservación de carreteras.
Muestra el presupuesto disponible o
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.
Indica el presupuesto que se
encuentra en trámite de pago a los
contratistas en cada Estado del
país.
Indica el presupuesto contratado
por cada Estado respecto a
conservación de carreteras, por el
concepto de programa operativo.
Indica el presupuesto que ha sido
pagado a los contratistas por la
conservación de carreteras, por el
concepto de programa operativo.
105
Estados
con
mayor Pesos
presupuesto
asignado
por ejercicio fiscal
Presupuesto
ejercido Pesos
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
Porcentaje
Porcentaje
Porcentaje
Porcentaje
Porcentaje
de Porcentaje
presupuesto
ejercido
respecto al presupuesto
Muestra los nueve estados con
mayor presupuesto para inversión
en infraestructura carretera.
Muestra el presupuesto que cada
estado del país ha pagado a sus
contratistas por la ejecución de obra
de forma semanal.
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.
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.
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.
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.
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.
Este
indicador
muestra
el
porcentaje de dinero que cada
Estado pagó a sus contratistas en
106
comprometido en cuanto
a caminos rurales y
carreteras alimentadoras
Porcentaje
de Porcentaje
presupuesto
comprometido respecto
al presupuesto asignado,
en
cuanto
a
conservación
y
mantenimiento
de
carreteras federales
Porcentaje
de Porcentaje
presupuesto
ejercido
respecto al presupuesto
asignado en cuanto a
conservación
y
mantenimiento
de
carreteras federales
Porcentaje
de Porcentaje
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.
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.
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.
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.
3.5.6 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
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
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.
3.5.7 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
(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
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.
3.6.1 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
Figura 3.16. 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
Figura 3.17. 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
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 3.18.
Figura 3.18. 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 F201820138, 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
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 3.22.
115
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
3.23.
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
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 3.26.
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 relacionales49.
Figura 3.27 Página de inicio de SIE de Infraestructura (diseño propio)
49
Oracle Corporation. (2007). Hyperion Web Analysis Studio Release 9.3.1 Users Guide. Redwood, CA. p. 19.
117
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
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
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
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
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
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)
3.7.1 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
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
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 3.36. 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
Febrero
Ti
em
po
Mazo
Proyecto
Enero
K1506
289.10 13500
2520
K1507
100.50
2800
1500
K1508
350
589.30
970
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
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
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
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
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
Figura 3.42 Definición de privilegios de acceso al grupo de reportes
de la DGCC (diseño propio)
131
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 4.1.1.
4.1.1 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
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. (1991-2000). Analytic Services Database Administrator's Guide.
Sunnyvale, CA.
133
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
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 4.4.
135
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
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
1
2
3
4
5
6
7
8
9
10
11
Nombre de la dimensión
Centro de trabajo
Tiempo
Avance
Dato
Año
Financiamiento
Métricas
Programa operativo
Programa de presupuesto
Centro SCT
Proyecto
Configuración
Dispersa
Densa
Dispersa
Dispersa
Dispersa
Dispersa
Densa
Dispersa
Dispersa
Dispersa
Dispersa
Atributo de
almacenamiento
Almacenar dato
Almacenar dato
Solo etiqueta
Solo etiqueta
Almacenar dato
Almacenar dato
Solo etiqueta
Almacenar dato
Almacenar dato
Almacenar dato
Almacenar dato
Tabla 4.1 Configuración de las dimensiones de la base de datos
desarrollada (diseño propio)
4.1.2 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. (1991-2000). Analytic Services Database Administrator's Guide.
Sunnyvale, CA.
137
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
Centro de trabajo
Avance
Dato
Año
Financiamiento
Programa operativo
Programa de presupuesto
Centro SCT
Proyecto
Número de miembros
almacenados
5
2
2
3
5
34
3
44
1795
Tabla 4.2 Dimensiones dispersas cuyo atributo de almacenamiento
es “Almacenar dato” (diseño propio)
138
2. Multiplicar el número de miembros almacenados obtenidos en el punto
anterior.
Número potencial
2,416,788,000
de
bloques
de
datos
=
5*2*2*3*5*34*3*44*1,795
=
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
Nombre de la dimensión
Tiempo
Número de miembros
almacenados
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,032.
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 * (72 + 24,256) =
587,956,184,640 bytes = 547 Gb
140
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
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 = 379.
142
Á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 = 71.24
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 3.5.4 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
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
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
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
3.7.1 Herramientas de análisis, tratado al final del capítulo 3.
4.3 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
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. 112.
147
La fórmula que se utilizó para el cálculo de la desviación estándar es:
Cliente
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Media
Desviación
estandar
Elementos de satisfacción
5
6
7
4
3
4
5
4
2
5
4
3
5
4
2
2
2
3
4
5
5
5
4
4
4
4
4
4
4
4
4
4
2
4
5
3
4
5
4
4
5
3
3
3
4
3
4
4
5
5
4
5
5
5
4
4
5
4
3
5
4
4
3
4
5
4
4
5
5
5
5
4
4
5
4
4
5
4
3
4
3
4
5
4
4
4
4
4
4
4
5
5
4
1
4
5
3
4
2
5
4
5
4
4
4
3
5
3
4
5
4
2
4
4
3
4
4
5
4
4
4
4
5
4
2
4
4
3
4
2
5
4
5
4
5
5
3
5
3
4
4
5
3
4
4
3
4
4
5
5
5
4
4
4
4
3
4
4
3
3
2
4
5
4
4
4
4
4
4
3
3
5
4
3
5
4
4
3
4
5
4
5
5
4
4
4
4
5
4
3
3
2
5
5
4
3
5
4
4
4
3
4
4
5
4
4
4
4
3
4
4
4
5
5
4
5
4
3.97
4.07
3.93
4.03
4.10
4.27
0.80
0.77
0.73
0.75
0.70
0.77
8
4
4
4
4
3
5
5
4
4
4
4
5
5
4
4
4
5
4
4
4
5
3
4
5
4
5
4
4
5
4
9
4
4
2
4
3
5
5
4
4
4
4
3
5
5
4
5
5
4
3
4
5
4
3
5
4
5
5
4
5
5
10
4
4
2
4
2
5
5
4
4
5
4
3
5
4
4
4
5
5
5
4
2
4
5
5
4
5
4
4
5
5
11
4
4
3
5
3
5
4
4
4
4
5
4
4
4
4
4
5
5
4
4
4
5
5
5
5
5
5
4
5
5
12
4
4
4
5
3
5
4
4
4
4
5
5
4
4
4
5
5
5
5
5
4
5
5
5
5
5
5
4
5
5
3.77
4.23
4.20
4.17
4.37
4.53
0.84
0.56
0.79
0.90
0.60
0.56
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
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
Desviación estandar
4.02
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. 114
149
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
4. Facilidad de revisión
Media
Desviación estandar
Facilidad de revisión
4.00
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
mencionar que, como se explicó en el capítulo anterior, se diseñó un set de
reportes por cada área, de acuerdo a sus necesidades de información
planteadas al inicio del proyecto.
Sin embargo, la herramienta de reporteo que se les proporcionó (Oracle
Hyperion Web Analysis), permite a los usuarios generar nuevas consultas o
reportes. Lo más importante es que existe una única fuente de información
para todas las áreas de la Subsecretaría de Infraestructura Carretera.
6. Satisfacción global
Satisfacción global
Media
4.45
Desviación estandar
0.59
En promedio, la mayoría de los usuarios opinaron que están muy
satisfechos con el software desarrollado, ya que satisface sus expectativas.
Considero que este resultado responde prácticamente al objetivo de este
capítulo.
El impacto que tuvo la implementación de un sistema de información basado en
tecnología de inteligencia de negocios, está ayudando en gran medida a satisfacer
una necesidad de obtener información de manera rápida y precisa, además de ser
una única fuente de información para el capítulo de gasto 6000 (gasto de
inversión), para toda la dependencia.
152
Conclusiones
Con base en lo expuesto, se concluye que la tecnología de inteligencia de
negocios, puede ser aplicable a empresas públicas o privadas. Por lo general, en
libros y revistas se habla sobre el éxito que la inteligencia de negocios (o business
intelligence por sus siglas en ingles), ha tenido en empresas privadas. Sobre todo
en áreas como finanzas, mercadotecnia, compras o ventas.
Por ejemplo, en el área de mercadotecnia se dice que esta tecnología puede
ayudar a los mercadólogos a encontrar nuevos nichos de mercado. O que en las
áreas de ventas, la inteligencia de negocios permite identificar necesidades de los
clientes.
Sin embargo, no hace poco tiempo que las empresas públicas o de gobierno,
comenzaron a almacenar su información en bases de datos por medio de
sistemas computarizados. Por lo que no cabe ninguna duda de que la tecnología
de inteligencia de negocios disponible actualmente, facilita en gran medida la
consolidación y el análisis del gran volumen de datos que llegan a manejar las
empresas públicas, como por ejemplo la Secretaría de Comunicaciones y
Transportes.
Logros alcanzados
Se cumplió el objetivo principal de este trabajo, el cual era diseñar y construir una
herramienta de software, que ayudara al personal de la Secretaría de
Comunicaciones y Transportes a analizar y a conocer en forma precisa y en
cualquier momento, la información física y financiera de las obras de construcción
y de mantenimiento de carreteras federales, que se llevan a cabo en toda la
República Mexicana.
Durante el desarrollo del trabajo, se identificaron las principales fuentes de datos
que las áreas de la Subsecretaría de Infraestructura, utiliza para recabar
información y tomar decisiones. Se trata del Sistema Integral de Administración
(SIA) y del Sistema para el Registro, Administración y Seguimiento Físico y
Financiero de Carreteras (SIRASEF) los cuales son dos de los sistemas de
información institucionales cuyo uso es de carácter oficial y obligatorio para las
áreas de la Subsecretaría de Infraestructura. De ahí que se pueda afirmar que la
información de la cual se alimenta la data mart o base de datos de infraestructura,
sea muy confiable para el personal al cual está dirigido el Sistema de Información
Ejecutivo de Infraestructura.
153
Se diseñó y construyó el data mart de infraestructura utilizando como repositorio
de datos una base de datos multidimensional. Este tipo de bases de datos están
diseñadas para consolidar grandes volúmenes de información y facilitar el análisis
de la misma a los usuarios finales que deben tomar decisiones con base en ella.
Cabe mencionar que a diferencia de las bases de datos relacionales, el uso y
explotación de una base de datos multidimensional está dirigido a la alta gerencia
de una organización, ya que solo almacena información consolidada sobre algún
tópico en particular y no almacena grandes volúmenes de datos como lo es el
detalle de la información que los sistemas de información transaccionales
procesan diariamente, derivado de la operación cotidiana de las áreas usuarias.
Como última fase del proyecto y con base en el análisis de las necesidades de
información planteadas por los usuarios, se diseñaron e implementaron una serie
de interfaces gráficas que muestran los parámetros de control que los usuarios
necesitan conocer a diario.
Adicionalmente, se le entregaron a los usuarios herramientas de análisis que
forman parte la infraestructura de la tecnología de inteligencia de negocios que se
utilizó para desarrollar el software. Estas herramientas les permiten a los usuarios
diseñar en cualquier momento sus propias consultas y reportes ejecutivos sin
depender de las áreas técnicas, lo cual representa otra ventaja de utilizar BI para
la explotación de la información por los usuarios.
Por lo tanto, se puede concluir que en una empresa de características tan grandes
y variables como lo es una empresa pública, si se tiene al personal capacitado y
con la madurez suficiente para tomar decisiones en base al análisis de la
información disponible, entonces la inversión en tecnología será aprovechada en
su totalidad.
Como sabemos, el proceso de toma de decisiones no solo se lleva a cabo
utilizando tecnología. La información puede estar almacenada en medios
electrónicos o en papel. Pero si el personal de una organización no está
acostumbrado a analizar su información para tomar decisiones, entonces la
tecnología será aprovechada solo en parte.
Mejoras a futuro
El desarrollo del Sistema de Información Ejecutivo de Infraestructura, es sólo una
de las muchas aplicaciones que será necesario construir para conformar un
Sistema de Información Ejecutivo Financiero a nivel corporativo.
Es decir, el SIE de infraestructura que fue desarrollado en el presente trabajo
contiene la información del clasificador por objeto del gasto 6000, el cual
154
corresponde a inversión en infraestructura carretera. Es importante recordar que
las fuentes de datos para el SIE de Infraestructura fueron el Sistema para el
Registro y Seguimiento para la Construcción de Carreteras (SIRASEF) y el
Sistema Integral de Administración (SIA). De éste último, solo se extrae la
información concerniente al clasificador de gasto 6000.
El siguiente paso será construir aplicaciones similares que consoliden la
información de otros sistemas institucionales que ya están desarrollados y que
fueron diseñados para administrar la información de los demás capítulos de gasto,
como son:
el clasificador de gasto 1000 correspondiente a servicios personales y
del 2000 al 5000 correspondientes a recursos materiales,
hasta cubrir la totalidad de los datos contenidos en el Sistema Integral de
Administración (SIA), de tal forma que los usuarios de la Dirección General de
Programación, Organización y Presupuesto (DGPOP), también cuenten con la
totalidad de la información financiera consolidada en un solo Sistema de
Información Ejecutivo de toda la Secretaría.
155
Bibliografía
Abadal Falgueras, E. (2001). Sistemas y servicios de información digital. Barcelona: Universidad de
Barcelona.
Arjona Torres, M. (1999). Dirección estratégica. Un enfoque práctico. Madrid: Diaz de Santos.
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.
Diccionario de informática e internet: Computer and internet Technology Definitions in Spanish.
(2004). Boston, Massachusetts: Thomson.
Dirección General de Carreteras Federales. (s.f.). Carreteras Federales. Recuperado el 04 de Agosto
de 2009, de http://dgcf.sct.gob.mx/index.php?id=985
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.
Dirección General de Conservación de Carreteras. (Febrero de 2009). Manual de Organización. D.
F., México.
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.
Dirección General de Servicios Técnicos. (Noviembre de 2008). Manual de Organización. D. F.,
México.
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.
Han, J. (2006). Data Mining: Concepts and Techniques. San Francisco, CA.: Morgan Kaufmann.
Hayes, B. E. (2006). Cómo medir la satisfacción del cliente. México: Alfaomega.
Hyperion Solutions Corporation. (1991-2000). Analytic Services Database Administrator's Guide.
Sunnyvale, CA.
Hyperion Solutions Corporation. (2000). Hyperion Essbase Fundamentals Training. Sunnyvale, CA.
Hyperion Solutions Corporation. (1999). Hyperion Essbase: Partitioning Training. Sunnyvale, CA.
Joaquim, L. (2004). Tecnologías del texto y del habla. Barcelona: Universidad de Barcelona.
Kendall. (1997). Análisis y diseño de sistemas. 3ra ed. México: Prentice Hall.
Kroenke, D. (2003). Procesamiento de bases de datos. México: Prentice Hall.
156
Laudon, K. C., & Laudon, J. P. (2004). Sistemas de Información Gerencial.8va. ed. México: Prentice
Hall.
Laudon, K. (2004). Sistemas de información gerencial: Administración de la empresa digital.
México: Prentice Hall.
Martínez Coll, J. C. (2003). Las flechas, economía del tiempo y la información. Málaga: Editado por
el autor.
Martínez Posadas, S. (Abril de 2009). Comunicación Organizacional. Recuperado el 21 de Mayo de
2009, de TURevista Digi.U@T:
http://www.turevista.uat.edu.mx/Volumen%203%20Numero%204/refcomunicacion%20organizacional.htm
McLeod Jr, R. (2000). Sistemas de información gerencial, 7a ed. México: Prentice Hall
Hispanoamericana, S. A.
Mosley, D., Megginson, L., & Pietri, P. (2005). La práctica del Empowerent, desarrollo de equipos
de trabajo y motivación. Cengage Learning Editores.
Oracle Corporation. (2007). Hyperion Web Analysis Studio Release 9.3.1 Users Guide. Redwood,
CA.
Pablos Heredero, C. d. (2004). Ilustraciones de la aplicación de las tecnologías de información en la
empresa española. Barcelona: ESIC.
Pastor, J. (2001). Dirección y gestión de los sistemas de información en la organización. Barcelona:
UOC.
Pastor, J. (2001). Usos de los sistemas de información en la organización. Barcelona: UOC.
Peralta, V., & Ruggia, R. (s.f.). Universidad de la República. Recuperado el 14 de 04 de 2009, de
Implementación de herramientas CASE que asistan en el Diseño de Data Warehouses:
http://www.fing.edu.uy/inco/grupos/csi/esp/Publicaciones/2001/tr0120-vp.pdf
SHCP. Subsecretaría de Egresos. Unidad de Política y Control Presupuestal. (13-Octubre-2000).
Clasificador por objeto del gasto para la Administración Pública Federal. México, D. F.
Subsecretaría de Infraestructura. (Febrero de 2009). Manual de Organización. D. F., México.
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
http://www.oracle.com/technology/global/lad-es/pub/articles/08-jul/o38olap.html
157
Anexo I
Cuestionario de evaluación de la satisfacción de los usuarios del Sistema de
Información Ejecutivo de Infraestructura.
158