UNIVERSIDAD CENTRAL DE VENEZUELA

FACULTAD DE CIENCIAS
ESCUELA DE COMPUTACIÓN
CENTRO DE INVESTIGACIÓN DE SISTEMAS DE INFORMACIÓN

DESARROLLO DE UNA SOLUCIÓN DE

INTELIGENCIA DE NEGOCIO PARA EL APOYO
A LA TOMA DE DECISIONES EN EL ÁREA
VENTAS DE EMPRESAS DEL SECTOR SALUD

Trabajo Especial de Grado presentado ante la ilustre

Universidad Central de Venezuela por el(la)
Br. Andrés Castrillo
Br. Diana Dugarte
Tutora: Prof(a). Lic. Brenda López
Octubre 2011

1
 ACTA

Quienes suscriben, miembros del Jurado designado por el Consejo de Escuela de

Computación, para examinar el Trabajo Especial de Grado presentado por los
Bachilleres Castrillo, Andrés. C.I. 16.971.122, Dugarte, Diana. C.I. 17.490.185,
con el título: “Desarrollo de una Solución de Inteligencia de Negocio para el
Apoyo a la Toma de Decisiones en el Área de Ventas de Empresas del Sector
Salud”, a los fines de optar al título de Licenciado en Computación, dejen
constancia de lo siguiente:

Leído como fue, dicho trabajo por cada uno de los miembros del jurado, se fijó el día
27 de Octubre de 2011 a la 10:00am, para que sus autores lo defendieran en forma
pública, lo que hicieron en el Aula PB3 de la Escuela de Computación, mediante una
presentación oral de su contenido, luego de lo cual respondieron las preguntas
formuladas. Finalizadas la defensa pública del Trabajo Especial de Grado, el jurado
decidió aprobarlo.

En fe de lo cual se levanta la presente Acta, en Caracas a los 27 días del mes de

Octubre del año dos mil once dejándose también constancia de que actuó como
Coordinador del Jurado la Profesora tutor Brenda López.

Prof. Brenda López (Tutor)

Prof. Concettina Di Vasta (Jurado) Prof. Renny Hernández (Jurado)

FECHA: 27-10-2011

2
 AGRADECIMIENTOS

Andrés Castrillo.

Agradezco primero que todo a Dios por TODO, sin el no hubiéramos podido
culminar ninguna de las diferentes etapas de la carrera.
A mi familia, que me han apoyado siempre, sin importar en que parte del mundo
estuvieran, estuvieron ahí para darme consejos.
A la profesora Brenda López que nos guió durante el desarrollo de este trabajo, pero
sobretodo al grupo completo de Tian, que en todo momento nos dieron su apoyo
tanto para el uso de sus espacios como para darnos consejos, así no fuera en hora
de oficina, estuvieron ahí horas extras o vía Skype para ayudarnos en los problemas
que nos fueron surgiendo durante la realización del trabajo.
Quiero agradecer a todos mis amigos que me acompañaron durante la carrera,
empezamos muchos, terminamos pocos, pero igual siempre estuvimos juntos y
seguimos en contacto aunque por diversas circunstancias ya no estemos todos
sentados en el mismo lugar hablando y echando broma, espero que pronto nos
reunamos nuevamente.
Quiero agradecerle a Diana, que durante toda la carrera ha estado conmigo para
apoyarme en las diferentes materias, estudiando y haciendo proyectos juntos,
logrando que ambos alcanzáramos esta meta, de verdad que le deseo una vida muy
feliz con Jamie ahora que se van a casar.
Y por último pero no menos importante, le agradezco enormemente a la Universidad
Central de Venezuela, que gracias a sus métodos propios y únicos, nos ha dado las
herramientas necesarias para que nos formáramos como profesionales capaces de
enfrentar y superar diferentes retos.
Este Trabajo Especial de Grado está dedicado a José Rafael Castrillo Cabrera,
Yolanda Mendoza, Lucila Flores y Marco Antonio Briceño, mis cuatro abuelos que
en todo momento han estado conmigo presencial y espiritualmente.

3
Diana Dugarte.

Agradezco principalmente a Dios por permitirme una vez más alcanzar mis metas y
por no dejarme sola.
Agradezco a mi Familia por su acostumbrado apoyo, especialmente a mi hermana
María Fernanda por su compañía en todo momento y por sus sabios consejos.
Agradezco a la Familia Hernández-Jaramillo, quienes siempre me brindaron una
mano amiga en todo momento, especialmente a mi futuro esposo Jamie Hernández
por su apoyo incondicional.
Agradezco al grupo Tian por el tiempo y espacios prestados para el desarrollo
profesional durante mi etapa final de la carrera, muchas gracias por todo el apoyo.
Agradezco a nuestra tutora Brenda López por todo su apoyo y por todo el
conocimiento que nos brindo para nuestro desarrollo profesional.
Agradezco al Profesor Franky Uzcategui por sus sabios consejos y por toda la
ayuda prestada.
Agradezco especialmente a Andrés por su paciencia y su amistad durante todo este
tiempo y que espero se siga manteniendo sin importar los caminos próximos a
tomar.
Agradezco a todos mis amigos quienes con su compañía alegraron este camino
académico y lo hicieron gratificante.
Y por último a nuestra casa de estudios la Universidad Central de Venezuela, en
especial a la Facultad de Ciencias y sus integrantes quienes colaboraron en mi
desarrollo académico y profesional.
Este trabajo especial de grado está dedicado especialmente a Decidaira Jaramillo.

4
 RESUMEN

La demanda actual en los servicios de atención médica que existe en el país y la

competencia entre empresas del sector salud para ofrecer el mejor servicio y
calidad, genera la necesidad de medir eficientemente los procesos que la
componen, determinar posibles fallas y poder optimizar los procesos para así
aumentar la rentabilidad de los servicios y productos ofrecidos. Generalmente,
dichas instituciones cuentan con mecanismos básicos para la elaboración y análisis
estadísticos de los datos, en muchos de los casos son cargados manualmente en
hojas de cálculo trayendo como consecuencia un alto índice de errores de
transcripción, adicionalmente el gran volumen de datos que se registran hacen una
tarea difícil y poco eficiente para la obtención de indicadores de gestión de los
productos y servicios ofrecidos. Es por esto que el objetivo de este Trabajo Especial
de Grado consiste en el diseño y construcción de una solución de inteligencia de
negocio para obtener indicadores de gestión relevantes en las empresas del sector
salud con el fin de dar apoyo a la toma de decisiones estratégicas en el área de
ventas.

PALABRAS CLAVES:
Inteligencia de Negocio, Almacén de Datos, Sector Salud, Indicadores de Gestión,
Metodología Ralph Kimball.

5
 ÍNDICE

INTRODUCCIÓN .......................................................................................... 13
CAPÍTULO 1: PROBLEMA DE INVESTIGACIÓN. ....................................... 15
1.1- Planteamiento del problema............................................................... 15
1.2.- Solución planteada ............................................................................ 16
1.3.- Objetivos ........................................................................................... 18
1.3.1.- General ....................................................................................... 18
1.3.2.- Específicos ................................................................................. 18
1.4. Justificación e importancia ................................................................. 19
1.5.- Alcance ............................................................................................. 19
CAPÍTULO 2: MARCO CONCEPTUAL. ....................................................... 20
2.1.- Procesamiento de Transacciones en Línea (OLTP) vs Procesamiento
Analítico en Línea (OLAP) ......................................................................... 20
2.1.1.- On-Line Transaction Processing ................................................ 20
2.1.2.- On-Line Analytical Processing .................................................... 21
2.1.3.- OLTP vs. OLAP .......................................................................... 21
2.2.- Inteligencia de Negocio ..................................................................... 22
2.2.1.- Arquitectura de una solución BI. ................................................. 23
2.2.2.- Características de una solución BI ............................................. 26
2.2.3.- Beneficios de BI .......................................................................... 26
2.3.-Almacén de Datos (Datawarehouse) ................................................. 28
2.3.1.- Características de un Almacén de datos .................................... 28
2.3.2.- Bodegas de Datos (Datamarts) .................................................. 30
2.3.3.- Bodegas de Datos Vs Almacén de datos ................................... 31
2.4.- Modelo Dimensional .......................................................................... 32
2.4.1.- Hecho ......................................................................................... 32
2.4.2.- Dimensión................................................................................... 32
2.4.3.- Jerarquía .................................................................................... 33
2.4.4.- Cubo ........................................................................................... 33
2.4.5.- Celda .......................................................................................... 34
2.4.6.- Tabla de Hechos (FactTable) ..................................................... 34

6
 2.4.7.- Tabla Dimensión ......................................................................... 35
2.4.8.- Tipos de esquemas .................................................................... 36
2.5.- Indicadores de gestión de ventas en el Sector Salud ....................... 39
2.5.1.- Empresas del sector salud ......................................................... 39
2.5.2.- Unidades de Atención................................................................. 40
2.5.3.- Conceptos Facturables ............................................................... 42
2.5.4.- Protocolos................................................................................... 43
2.5.5.- Presupuestos clínicos ................................................................. 43
2.5.6.- Responsable de pago ................................................................. 43
2.5.7.- Proceso de Atención al Paciente ................................................ 44
2.5.8.- Indicadores de gestión................................................................ 46
2.6.- Herramientas de BI .......................................................................... 47
2.6.1. - Oracle Business Intelligence Suite ............................................ 48
CAPÍTULO 3: MARCO METODOLÓGICO. .................................................. 55
3.1.- Metodología de Ralph Kimball - Ciclo de Vida del Modelo de Negocio.
.................................................................................................................. 55
3.1.1.- Planificación del proyecto. .......................................................... 55
3.1.2.- Definición de los requerimientos del negocio. ............................ 57
3.1.3.- Diseño técnico de la arquitectura. .............................................. 57
3.1.4.- Selección de productos e instalación.......................................... 59
3.1.5.- Diseño del Modelo Dimensional. ................................................ 59
3.1.6.- Diseño Físico. ............................................................................. 63
3.1.7.- Diseño y construcción de procesos ETC. ................................... 63
3.1.8.- Especificación y desarrollo de aplicaciones analíticas................ 63
3.1.9.- Integración y despliegue. ............................................................ 64
3.1.10.- Mantenimiento y crecimiento. ................................................... 64
CAPÍTULO 4: MARCO APLICATIVO ............................................................ 66
4.1.- Planificación del proyecto.................................................................. 66
4.2.- Definición de los requerimientos del negocio. ................................... 66
4.3.- Diseño de la arquitectura. ................................................................. 69
4.4.- Selección de productos e instalación. ............................................... 70
4.5.- Diseño del Modelo Dimensional ........................................................ 71
4.5.4.- Modelo Entidad Relación – Base de Datos intermedia: .............. 79

7
 4.6.- Diseño Físico. ................................................................................... 81
4.7.- Diseño y construcción de procesos ETC........................................... 88
4.7.1.- Proceso ETC de la fuente a la base de datos Intermedia........... 88
4.7.2.- Proceso ETC de la base de datos intermedia al almacén de datos
............................................................................................................... 89
4.8.- Especificación y desarrollo de aplicaciones analíticas ...................... 93
4.9.- Integración y despliegue ................................................................... 94
4.10.- Cuadros Analíticos .......................................................................... 98
4.11.- Mantenimiento y crecimiento ......................................................... 107
CONCLUSIONES ....................................................................................... 108
RECOMENDACIONES ............................................................................... 110
REFERENCIAS BIBLIOGRÁFICAS............................................................ 111
ANEXOS ..................................................................................................... 114

8
 ÍNDICE DE FIGURAS
Figura 1. Arquitectura de la solución BI .................................................................. 16
Figura 2. Arquitectura de una Solución BI ............................................................... 23
Figura 3. Proceso ETL ............................................................................................ 24
Figura 4. Características de un almacén de datos .................................................. 29
Figura 5. Representación de una Bodega de Datos ................................................ 30
Figura 6. Ejemplo de representación lógica de una jerarquía ................................. 33
Figura 7. Ejemplo de una representación lógica de un Cubo .................................. 34
Figura 8. Tabla de Hechos ...................................................................................... 35
Figura 9. Tabla Dimensión ...................................................................................... 35
Figura 10. Diagrama en estrella del Hecho Ventas ................................................. 36
Figura 11. Esquema en copo de nieve.................................................................... 37
Figura 12. Esquema Constelación .......................................................................... 38
Figura 13. Proceso de Admisión/Cargas/Facturación ............................................. 45
Figura 14 Oracle BI Enterprise Edition Vs Oracle BI Standard Edition One ............ 49
Figura 15. Componentes de Oracle BI Standard EditionOne. ................................. 49
Figura16. Oracle Database Standard Edition One . ¡Error! Marcador no definido.50
Figura 17. Oracle Warehouse Builder ..................................................................... 51
Figura18. Oracle Business Intelligence Server ...... ¡Error! Marcador no definido.52
Figura 19. Business Intelligence Interactive Dashboards ...................................... 53
Figura 20. Oracle Business Intelligence Answers ................................................... 54
Figura 21. Oracle Business Intelligence Publisher .................................................. 54
Figura 22. Ciclo de Vida del Modelo de Negocio por Kimball. ................................. 55
Figura 23. Diseño Técnico de la Arquitectura ......................................................... 69
Figura 24. Ejemplo de proceso de identificación de granularidad ........................... 71
Figura 25. Ejemplo de identificación de dimensiones .............................................. 72
Figura 26. Relaciones jerárquicas identificadas ...................................................... 73
Figura 27. Representación gráfica del hecho ventas con sus dimensiones............. 74
Figura 28. Representación gráfica del hecho Presupuesto con sus dimensiones y
atributos.................................................................................................................. 75
Figura 29. Hecho Ventas ........................................................................................ 76

9
Figura 30. Hecho Presupuesto ............................................................................... 76
Figura 31. Representación del modelo dimensional ................................................ 77
Figura 32. Modelo Dimensional extendido .............................................................. 78
Figura 33. Modelo entidad relación de la base de datos intermedia ........................ 81
Figura 34. Estructuras de la base de datos intermedia implementadas .................. 81
Figura 35. Asistente de creación de dimensiones ................................................... 82
Figura 36. Asignación de atributos con el asistente ................................................ 83
Figura 37. Definición de jerarquías con el asistente ................................................ 83
Figura 38. Definiendo los atributos por jerarquías ................................................... 84
Figura 39. Asistente de creación de cubos ............................................................. 85
Figura 40. Definiendo las dimensiones para el cubo ............................................... 86
Figura 41. Definiendo las medidas y atributos del cubo .......................................... 87
Figura 42. Diagrama del proceso ETC de la base de datos intermedia................... 88
Figura 43. Centro de diseño OWB 10g ................................................................... 89
Figura 44. ETC de la dimensión Cliente .................................................................. 90
Figura 45. ETC de la dimensión Producto .............................................................. 90
Figura 46. ETC de la dimensión Localidad.............................................................. 91
Figura 47. ETC de la dimensión Diagnostico .......................................................... 91
Figura 48. ETC para el cubo de Ventas .................................................................. 92
Figura 49. ETC para el cubo de Presupuesto ......................................................... 93
Figura 50. Oracle BI Administration Tool ................................................................ 95
Figura 51. Capa Física............................................................................................ 96
Figura 52. Capa del Modelo de Negocio y mapeo .................................................. 97
Figura 53. Capa de presentación ............................................................................ 98
Figura 54. Resumen de indicadores ....................................................................... 99
Figura 55. Indicador referente al análisis de las ventas por unidad de atención .... 100
Figura 56. Indicador referente al análisis detallado de las ventas por unidad de
atención ................................................................................................................ 100
Figura 57. Indicador referente a las ventas por tipo de cliente. ............................. 101
Figura 58. Indicador referente a las ventas por tipo cliente Seguro....................... 101
Figura 59. Indicador referente a las ventas por tipo de cliente Autopagante. ........ 102
Figura 60. Indicador referente a las ventas por concepto facturable ..................... 102
Figura 61. Indicador referente a la desviación porcentual de las ventas por mes . 103

10
Figura 62. Indicador referente a los Top 10 por concepto facturable..................... 103
Figura 63. Indicador referente al Top 10 por tipo Cliente ...................................... 104
Figura 64. Indicador referente a la diferencia entre Facturado y Presupuestado .. 105
Figura 65. Indicador referente a la cantidad de Presupuestos por Unidad de
Atención ............................................................................................................... 106
Figura 66. Indicador referente al monto facturado Vs su costo ............................. 106

11
 ÍNDICE DE TABLAS

Tabla 1. OLTP Vs OLAP ......................................................................................... 22

Tabla 2. Bodega de Datos Vs Almacén de datos .................................................... 31
Tabla 3. Indicadores de ventas ............................................................................... 68
Tabla 4. Indicadores de comparación de ventas ..................................................... 69
Tabla 5. Perspectivas identificadas ......................................................................... 72
Tabla 6. Atributos de las entidades ......................................................................... 80

12
 INTRODUCCIÓN

Dada la demanda actual de servicios de atención médica que existe en el país y la

competencia entre las empresas del sector salud para ofrecer el mejor servicio,
surge la necesidad de medir los procesos involucrados en cada una de las áreas del
negocio especialmente en aquellos que involucran el mercadeo y ventas de los
productos y servicios ofrecidos. A pesar de la gran cantidad de información que
recopilan diariamente, en muchos casos procesados a través de sistemas
transaccionales, generalmente las empresas no saben con certeza por qué no se
están alcanzando los objetivos planteados y toman decisiones gerenciales basadas
en la experiencia, uso de indicadores poco fiables e intuición.

Algunas empresas hoy día cuentan con mecanismos básicos para la elaboración de
indicadores y análisis estadísticos de los datos. En la mayoría de los casos son
cargados manualmente en hojas de cálculo por empleados de la empresa y que
pueden contener errores debido al factor humano.

La inteligencia de negocio nos brinda tecnologías, estrategias y herramientas que

permiten analizar la información de las empresas u organizaciones a partir de
diferentes perspectivas, obteniendo así una visión global del funcionamiento de los
procesos, detección inmediata de posibles fallas en la operatividad y para así de
esta manera aplicar correctivos necesarios.

Es por eso que el objetivo de este Trabajo Especial de Grado consiste en el diseño
y construcción de una solución de inteligencia de negocio para obtener indicadores
de gestión relevantes en las empresas del sector salud con el fin de dar apoyo a la
toma de decisiones estratégicas en el área de ventas.

Este documento está compuesto por unos capítulos los cuales describen el
problema planteado, conceptos necesarios dentro del desarrollo de la solución de
inteligencia de negocio, así como también la metodología usada y la descripción de
su implementación. A continuación se describe de forma general estos capítulos.

13
Capítulo 1: Define el problema de investigación así como los objetivos generales y
específicos a cumplir en este Trabajo Especial de Grado. Se explica la solución y
arquitectura implementada para alcanzar los objetivos planteados.

Capítulo 2: Describe los conceptos mínimos necesarios para entender los procesos
involucrados en el análisis, diseño y construcción de una solución de inteligencia de
negocio. Adicionalmente, define conceptos relacionados con el área de ventas el
sector salud y herramientas tecnológicas que apoyan a la construcción de la
solución de Inteligencia de Negocio (BI por sus siglas en ingles que significa
Business Intelligence) .

Capítulo 3: En este capítulo se presenta la metodología escogida para desarrollar la

solución de inteligencia de negocio planteada. Se define y describe cada paso
involucrado en los procesos de construcción de la solución.

Capítulo 4: Este capítulo describe la adaptación de los pasos de la metodología

seleccionada para el desarrollo de la solución de inteligencia de negocio propuesta.

Finalmente se presenta conclusiones y recomendaciones de la investigación.

14
CAPÍTULO 1: PROBLEMA DE INVESTIGACIÓN.

1.1- Planteamiento del problema

La alta gerencia de las empresas del sector salud (empresas del sector salud se
definirá en el marco conceptual) tienen la necesidad de medir los procesos del
negocio para aumentar su competitividad con respecto a la ventas de los servicios y
productos ofrecidos, el tema es que la mayoría de las empresas de salud se
enfrentan con ciertas dificultades al momento de elaborar y analizar los reportes
estadísticos que les ayuden en este proceso de medición del negocio.

Poseen una gran cantidad de datos que es almacenada y actualizada diariamente a

través de sistemas transaccionales, ocasionando lentitud en la toma de decisiones y
así mismo, afectan en las operaciones diarias de los sistemas transaccionales.

Usualmente los reportes que se utilizan para el apoyo a la toma de decisiones son
realizados por el departamento de informática y son cargados en hojas de cálculo,
retardando el proceso de generación de información gerencial. Además el proceso
de análisis y estudio de los indicadores de gestión, es manual y es posible encontrar
errores de transcripción o mala utilización de alguna fórmula.

El proceso de elaboración de los reportes operativos y gerenciales tiene como

desventaja una estrecha dependencia del departamento de informática y además,
una demora desde el momento de la solicitud hasta la entrega de la información.

Las herramientas que algunas empresas del sector salud utilizan no permiten una
representación gráfica lo suficientemente flexible como para hacer comparaciones,
elaborar consultas a la medida y hacer estudios predictivos de los resultados de los
análisis rápidamente.

15
1.2.- Solución planteada
Dada la situación actual y problemas que presentan las empresas del sector salud,
se propuso la construcción de una solución de Inteligencia de Negocio para obtener
un conjunto de indicadores de gestión relevantes y necesarios para dar soporte a la
toma de decisiones gerenciales y estratégicas, en empresas del sector salud.

Como se puede observar en la Figura 1, la solución propuesta está compuesta por:

datos fuentes, base de datos intermedia, procesos de extracción, transformación y
carga (ETC), almacén de datos y cuadros de mandos analíticos y reportes que dan
soporte a los indicadores de gestión.

Figura 1. Arquitectura de la solución BI (Kendall & Kendall, 2005)

Debido a que cada empresa del sector salud maneja sus procesos diarios de formas
diferentes, se plantea un área intermedia encargada de centralizar los datos
referentes al área de ventas, con la finalidad de estandarizar los datos provenientes
de las distintas fuentes de datos para posteriormente ser almacenados en el
almacén de datos. Esta base de datos intermedia es una base de datos relacional
que sigue un modelo de ventas genérico.

El siguiente componente es un almacén de datos encargado de soportar los datos

provenientes de la base de datos intermedia pero estructurado desde el punto de
vista del negocio, a través del diseño de un modelo dimensional genérico que
permita obtener los indicadores de gestión relevantes del área de ventas utilizando
la metodología seleccionada.

16
En la solución se tienen dos procesos ETC: el primero es el encargado de extraer,
transformar y cargar los datos fuentes a la base de datos intermedia, y el segundo
es el encargado de la extracción, transformación y carga de los datos de la base de
datos intermedia al almacén de datos. Con los datos cargados en el almacén de
datos, estos están disponibles para el análisis mediante el uso de las herramientas
de explotación y publicación.

Por último las consultas y cuadro de mando que permiten visualizar los indicadores
de gestión del área de ventas para las empresas del sector salud.

17
1.3.- Objetivos
A continuación se presentan los objetivos que se desean alcanzar con el trabajo
especial de grado.

1.3.1.- General
Desarrollar una solución de Inteligencia de Negocio (comúnmente conocida como BI
por sus siglas en ingles de Business Intelligence) orientada a la gestión de ventas
de empresas del sector salud, con el fin de apoyar la toma de decisiones precisas y
a tiempo.

1.3.2.- Específicos
A continuación se describirán los objetivos específicos:
Estudiar el área de negocio, para recopilar y definir los requerimientos del
área de ventas de empresas del sector salud.
Definir un conjunto de indicadores de gestión del área de ventas necesarios
para la toma de decisiones.
Diseñar el modelo entidad relación de la base de datos intermedia.
Diseñar el modelo dimensional que soporte los indicadores de gestión
propuestos utilizando la metodología de Ralph Kimball.
Construir la base de datos intermedia en base al modelo entidad relación de
ventas.
Construir el almacén de datos.
Diseñar, construir y ejecutar los procesos de extracción, transformación y
carga (ETC), desde los datos fuentes a la base de datos intermedia.
Diseñar, construir y ejecutar los procesos de extracción, transformación y
carga (ETC), desde la base de datos intermedia al almacén de datos.
Diseñar, desarrollar y desplegar las consultas analíticas y los cuadros de
mandos asociados a los indicadores de gestión correspondientes a la
solución de BI.
Realizar pruebas para validar la efectividad de la solución.

18
1.4. Justificación e importancia
Las empresas del sector salud cuentan con una gran cantidad de datos
provenientes de los procesos diarios los cuales almacenan usualmente en sistemas
transaccionales. Actualmente para dar soporte a las decisiones gerenciales, algunas
de estas empresas hacen uso de los datos directamente de los sistemas
transaccionales lo que ocasiona una mala utilización de los recursos, tanto de los
equipos como del personal, ya que deben solicitarle al departamento de sistema que
elaboren los distintos reportes que necesiten. Es por esto que se plantea esta
solución para las empresas del sector salud en el área de ventas que permita la
obtención de un conjunto de indicadores de gestión claves del área de ventas para
así dar soporte a las decisiones gerenciales.

Con la construcción de la solución de inteligencia de negocio se ofrece un sistema

de información alternativo que permita monitorear los procesos de ventas a través
de indicadores de gestión, mediante una interfaz usable y sencilla, de manera que la
toma de decisiones se realice de una forma más rápida y eficiente. Además, con
esta solución se permite monitorear las metas en cuanto a las ventas que se
propongan en las empresas del sector salud bajo las diferentes perspectivas que se
ofrecen.

1.5.- Alcance
La solución de BI a desarrollar tomará en consideración un conjunto de indicadores
propios del área de gestión de ventas de empresas del sector salud (estos
indicadores están identificados y explicados en el marco aplicativo), utilizando los
datos un área intermedia como base para el llenado del almacén de datos y
siguiendo la metodología de Kimball para su construcción. Finalmente, utilizando las
herramientas propias de Oracle Business Intelligence Standard Edition One para
crear la solución.

19
CAPÍTULO 2: MARCO CONCEPTUAL.

El propósito de este capítulo es presentar algunas bases conceptuales que sirven

de fundamento para desarrollar soluciones de inteligencia de negocios como lo son
el procesamiento de transacciones en línea (OLTP por sus siglas en inglés On-Line
Transaction Processing) y el procesamiento analítico en línea (OLAP por sus siglas
en inglés On-Line Analytical Processing), aspectos relacionados con la inteligencia
de negocio, almacenes y bodegas de datos, así como concepto relevantes para el
diseño de un modelo dimensional.

Se definirán conceptos involucrados con los procesos de ventas de diversas

empresas del sector salud así como indicadores de gestión y sus tipos y algunos
ejemplos de éstos relacionados con este sector.

Así mismo se exponen las características de la plataforma tecnológica Oracle

Business Intelligence utilizada para el análisis, diseño, construcción e
implementación de la solución del caso de estudio particular.

2.1.- Procesamiento de Transacciones en Línea (OLTP) vs

Procesamiento Analítico en Línea (OLAP)
Para el desarrollo de una solución de inteligencia de negocio es importante tener
claro los conceptos y diferencias entre los sistemas OLTP y las tecnologías OLAP.
Es por esto que a continuación se definen estos conceptos y se hace una breve
comparación entre ellos.

2.1.1.- On-Line Transaction Processing

Sistemas diseñados para el manejo de datos, tanto para su almacenamiento como
para su rápida recuperación. Comúnmente asociados con los sistemas manejadores
de base de datos. Estos sistemas suelen están diseñados bajo la arquitectura
cliente – servidor.

20
2.1.2.- On-Line Analytical Processing
OLAP son tecnologías para el análisis de grandes volúmenes de datos con el fin de
generar información útil para el usuario. Son usados frecuentemente para la toma
de decisiones en las empresas a través de la manipulación de los datos
corporativos.

Según (Ponniah, 2001), OLAP es “una categoría de tecnología de software, que

permite a los analistas, gerentes y ejecutivos, obtener una mejor percepción de los
datos, a través de un acceso rápido, consistente e interactivo, en una variedad de
vistas posibles de la información que ha sido transformada, para reflejar la
dimensionalidad real de la empresa de una manera que entienda el usuario”.

2.1.3.- OLTP vs. OLAP

La diferencia entre OLTP y OLAP se pueden observar en características tales como
la integración de datos, el acceso y manipulación de los datos por parte de los
usuarios, las tareas de los administradores en estos sistemas, las características de
las transacciones y como se ven los datos en el tiempo. En la Tabla 1, se muestra
una comparación bajo ciertos criterios:

OLTP OLAP
Comúnmente no integradas Debe ser integrada
Cada tema de negocios puede Toda la información referente a un
tener información en diferentes tema, tiene una única fuente
Integración

sistemas
Diferentes plataformas de Posee un solo servidor lógico
hardware warehouse

21
 Los usuarios son los que Los usuarios solo realizan

Acceso y Manipulación
de datos por parte de
insertan, actualizan y borran los consultas
datos

usuarios

Manipulan los datos a nivel de Cargan y acceden a los datos en

Administradores

registros forma masiva

Transacciones y procedimientos Validaciones antes de la carga
almacenados de validación a
nivel de registros

Se manejan gran cantidad de Pocas transacciones al día

Transacciones

transacciones por día

Si la transacción se realizo con Si la carga termina exitosamente
éxito se asegura consistencia de se tiene consistencia asegurada de
los datos que intervinieron todo el conjunto de datos.

No existe un historial Está compuesta por fotografías de

Tiempo

explícitamente las bases de datos transaccionales

Tabla 1. OLTP Vs OLAP

2.2.- Inteligencia de Negocio

La Inteligencia de Negocios (comúnmente conocida como BI) es un conjunto de
conceptos, métodos y tecnologías que emplean procesos centrados en el usuario;
los cuales, permiten la exploración de los datos, la apreciación de relaciones entre
los mismos y las tendencias que se puedan deducir con los datos que se manejen
en la organización (Moss & Atre, 2003).

BI es un conjunto de metodologías, tecnologías y aplicaciones, que permiten reunir,

depurar y transformar los datos del negocio, en conocimiento para dar soporte a la

22
toma de decisiones. Es por esto, que BI se basa más en la creatividad y habilidad
de utilizar los datos de la empresa, que en la tecnología que se aplique.

2.2.1.- Arquitectura de una solución BI.

Toda solución de BI está compuesta, como se muestra en la Figura 2 básicamente
por 4 componentes, los cuales se describen a continuación:

Figura 2. Arquitectura de una Solución BI.(Inmon, 1999)

Fuentes de datos: son los datos que se obtienen de los procesos diarios y
que se requieren para el análisis del negocio, estos pueden ser extraídos de
diferentes lugares: de procedencia externa a la organización o pueden ser
los mismos datos arrojados por los procesos operacionales de la
organización.
Proceso de Extracción, Transformación y Carga (ETL o ETC): consiste
en la extracción de los datos provenientes de las distintas fuentes
disponibles, la adaptación de los mismos según un formato o estándar
requerido para su almacenamiento y la carga en otro repositorio de
almacenamiento.
En la Figura 3 se muestra un esquema de un proceso ETC.

23
 Figura 3. Proceso ETL (Inmon, 1999)

Extracción: es el proceso a través del cual se logran alcanzar u obtener los

datos que se encuentran en la fuente. La extracción es un proceso complejo
debido a que se puede extraer los datos de diversas fuentes, como de
sistemas operacionales o transaccionales, como también de simples hojas
de cálculo.
El proceso de extracción debe conocer el diseño de los datos del sistema de
origen, de tal manera que pueda ser capaz de seleccionar sólo los datos que
necesite. Las fuente de datos contendrán muchos datos que son o no
relevantes para el almacén de datos, es por esto que debe ser capaz de
obtener solo lo relevante, sin importar el nivel de detalle, un registro completo
o simplemente un campo en específico de un registro.
En la actualidad, es muy común en el proceso de extracción, el
almacenamiento temporal, de una versión de los datos extraídos en un área
denominada área de ensayo (staging area). Esto con el fin de, en caso de
tener problemas al cargar los datos en el almacén de datos o durante la
transformación de los mismos, no tener que realizar todo el proceso de
extracción de nuevo.
Transformación: es el proceso donde se valida si un registro será o no
almacenado en el almacén de datos. La integración de los datos que
provienen de diversas fuentes también es realizada aquí. En el proceso de
transformación son aplicadas diversas funciones a los datos con el fin de
transformarlos en la forma deseada, estos cambios pueden ser simples
conversiones de enteros a caracteres o viceversa, como también el cálculo
de algún valor a partir de los datos obtenidos.
Durante este proceso se deben eliminar cualquier tipo de inconsistencia que
se pueda estar acarreando de los sistemas operacionales. Así que, se debe

24
ser capaz de especificar cuáles son los valores correctos para cada campo,
para así asegurar que solo se estará trabajando con datos confiables y
consistentes.
Carga: Es el proceso mediante el cual, se almacenan los datos obtenidos en
la fase anterior. Este proceso también puede incluir la tarea de mantener
índices y restricciones de integridad.
Existen básicamente tres tipos de carga, las cuales son (Ponniah, 2001):
- Carga Inicial: el almacén de datos se encuentra vacío por ser la
primera vez que se cargaran los datos, así que se almacenan todos
los datos en sus respectivas tablas
- Carga Incremental: carga de datos a medida que van ocurriendo
cambios en los mismos y dentro de los tiempos de carga planificado
- Refrescamiento total (Full refresh): se borra el contenido de todas o
de ciertas tablas y son cargadas nuevamente con datos más
recientes.
Dado que el proceso de carga toma una buena cantidad de tiempo, y que
además, durante la tarea de carga no se puede tener en uso el almacén de
datos, se debe programar un horario donde se pueda realizar esta tarea sin
interferir con los usuarios. Quizás en algunos ambientes será conveniente
realizar pequeñas cargas en cortos periodos de tiempo, aminorando así el
tiempo que demore los grandes volúmenes de carga, pero quizás en otros
casos, será mejor realizar las cargas en periodos de tiempo más largos, para
así interrumpir lo menos posible a los usuarios
Área de almacenes de datos: en esta área se almacenan los datos
producto de los procesos ETC y que se requieren para el análisis. Pueden
ser almacenados en diversos tipos de repositorio, pero comúnmente se
almacenan en un área conocida como almacén de datos, o en diversos
almacenes de datos independientes, conocidos como bodegas de datos,
esto por las características que poseen para el almacenamiento masivo de
datos y su fácil acceso a ellos.
Herramientas de acceso: Se encarga de hacer posible la comunicación de
manera fácil y entendible para el usuario con los datos. Las herramientas de
acceso también son conocidas como área de presentación, en el cual se

25
 encuentran las diferentes herramientas que hacen de interfaz entre el cliente
y el conjunto de datos, y pueden ser tan simples como una herramienta de
consulta ad hoc o tan complejas como la minería de datos sofisticadas o
aplicaciones de modelado.

2.2.2.- Características de una solución BI

Una solucion BI debe cumplir con las siguientes características:
Visión unificada de los datos: Todos los datos deben estar localizados en un
único repositorio de datos, sin importar el tipo de datos o la fuente de donde
provenga, para así dar la sensación de que los datos estan centralizados.
Creación personalizada de informes y consultas: permite el desarrollo de
consultas y reportes a la medida sobre información contenida en los
Almacenes de Datos y/o datamarts.
Vistas gráficas e interactivas para la presentación de información analítica: A
través de cuadros de mandos integrales y estratégicos se facilita la
visualización de los indicadores de negocio.
Capacidad de procesamiento de grandes volumenes de datos: las
soluciones de BI permiten realizar consultas comparando los datos actuales
con los históricos.

2.2.3.- Beneficios de BI
Los beneficios de una solución BI se pueden ver reflejados en (Roy, 2005):

Permite medir la situación actual de la organización. Las organizaciones

manejan toneladas de información generada por sus diferentes operaciones diarias,
el problema es que no se usa esa información para conocer el status en que se
encuentra la organización. La organización debe ser consciente de los datos
arrojados para medir cuantitativamente los resultados.

Permite toma de decisiones rápidas en base a hechos reales. Con frecuencia

las decisiones son tomadas basándose en datos erróneos que son acarreados de
los sistemas transaccionales, haciendo que se tomen decisiones incorrectas. Los
datos deben estar organizados de tal manera, que permitan a un usuario consultar

26
en detalle y desarrollar informes productivos que arrojen información y conocimiento
sobre el negocio

Brinda una Visión unificada y compartida de los datos. Es frecuente que en una
empresa exista una gran cantidad de fuentes de datos, como lo son: bases de
datos, bodega de datos o hasta sencillas hojas de cálculo. Con una buena
aplicación de una solución BI, se logra integrar todos estos datos bajo un mismo
formato, agregarles un contexto (metadata) para así obtener información y luego
conocimiento a partir de ellos. Además, otro beneficio es el acceso rápido a estos en
cualquier momento. (Juliet, 2010)

Ayuda a alcanzar los objetivos del negocio. Ayuda a la empresa a focalizarse y a

alcanzar sus objetivos principales sin desviarse. Para ello, debe primero diseñar sus
indicadores claves de rendimientos.

Ayuda a incrementar los ingresos y disminuye costos. Las empresas con una
buena aplicación de soluciones BI, alcanzan niveles de prestaciones económicas
más elevadas. Son capaces de modificar sus ofertas y niveles de servicios, para
ajustarse mejor a las necesidades de sus clientes.

27
2.3.-Almacén de Datos (Datawarehouse)
Según (Inmon, 1999) “Un Datawarehouse es una colección de datos integrados, no
volátiles, orientados a temas y cambiantes en el tiempo, que son usados para la
toma de decisiones estratégicas”.

Un almacén de datos es un repositorio de información con datos históricos

obtenidos generalmente de los sistemas transaccionales de la empresa. El principal
objetivo de un Almacén de datos es centralizar1 los datos del negocio, sin importar
las fuentes de donde provengan estos, es decir, pueden ser de diversas bases de
datos las cuales pueden estar soportadas bajo diversos manejadores o simplemente
hojas de cálculo. Una vez obtenidos estos datos, deben ser accesibles por las
aplicaciones que dan soporte para el proceso de toma de decisiones gerenciales
(Wrembler & Koncilia, 2007).

Se debe entender que un almacén de datos es una mezcla compleja de procesos,

hardware, software, conocimiento de la institución y habilidades de integración de
sistemas, que proveen un ambiente y una infraestructura para cumplir con las
necesidades de las instituciones, en orden de realizar una mejor toma de decisiones
(Collins; Jackie, 2001).

2.3.1.- Características de un Almacén de datos

Según (Inmon, 1999), un almacén de datos se caracteriza por ser:
Integrado: los datos provienen de distintas fuentes (sistemas
transaccionales y/o fuentes externas) y son almacenados dentro de un
mismo repositorio, para así lograr la integración en aspectos como: la
convención de nombres, la codificación de estructuras y atributos físicos de
los datos, todos de forma consistente, y la uniformidad de variables, entre
otras consideraciones.

1
Cuando se dice centralizar los datos nos referimos a agrupar los datos en un mismo sistema, es importante
mencionar que existen Almacenes de Datos centralizados y distribuidos, pero ambos cumplen con la misma función
a groso modo, sólo que son dos formas de implementación diferentes.

28
 Temático: sólo los datos necesarios para el proceso de generación del
conocimiento del negocio se integran. Los datos se organizan por áreas
temáticas (Ventas, RRHH, Finanzas, entre otros) para facilitar su acceso y
entendimiento por parte de los usuarios finales.
Histórico: En un almacén de datos se almacenan fotografías del estado del
sistema transaccional correspondiente a un período de tiempo determinado.
Cada vez que se hace una carga de esta información, los datos anteriores
no son eliminados, se mantienen en el tiempo para así permitir
comparaciones y generar más conocimiento sobre el negocio.
No volátil: Los datos permanecen en el tiempo, es decir, no son eliminados
ni sustituidos. La actualización del almacén de datos incorpora los últimos
valores obtenidos desde el sistema transaccional, incrementando el
contenido del almacén de datos.

En la siguiente Figura 4 se ilustra lo antes descrito.

Figura 4. Características de un almacén de datos (Inmon, 1999)

29
2.3.2.- Bodegas de Datos (Datamarts)
Una bodega de datos es una forma simple de un almacén de datos que se centra en
un área temática (o área funcional), tales como ventas, finanzas o mercadeo. Las
bodegas son a menudo construidas y controladas por un solo departamento dentro
de una organización, dado su enfoque de un solo tema, obtienen por lo general los
datos de sólo unas pocas fuentes, la fuente puede ser de un sistema transaccional,
un almacén de datos central o de datos externos. Una bodega de datos es mucho
más pequeña y más flexible que un almacén de datos, dado que posee menor
volumen de datos (Todman, 2001). En la Figura 5 se muestra un ejemplo de bodega
de datos dentro de una organización

Figura 5. Representación de una Bodega de Datos (Todman, 2001)

Las Bodegas de Datos poseen las mismas características que poseen los
almacenes de datos: integración, temáticos, históricos y no volatilidad. Son
comúnmente usados bajo la premisa o estrategia de “divide y vencerás” para
ámbitos muy genéricos de un almacén de datos, que ocurre generalmente cuando el
almacén tiende a crecer muy rápidamente y los distintos departamentos requieren
solo de una porción de los datos contenidos en él.

30
2.3.3.- Bodegas de Datos Vs Almacén de datos
No existe una diferencia en cuanto a implementación o componentes entre las
Bodegas de Datos y los almacenes de datos. Al momento de establecer una
comparación se toman aspectos como el alcance, la orientación a temas, las
fuentes de datos que usan y el tiempo de implementación.

Los almacenes de datos tienen un alcance corporativo, es decir, modelan el negocio

completo, mientras que los datamarts modelan áreas de las organizaciones, como
las ventas, cobranza, recursos humanos, entre otros. También se pueden
diferenciar en cuanto a sus fuentes de datos, dado que los almacenes de datos
modelan el negocio completo, estos poseen una gran cantidad de fuentes de datos
en comparación a los datamarts que solo contendrán las fuentes correspondientes
al área temática a modelar. En la Tabla 2 se resumen estos aspectos.

Propiedad Almacén de Datos Datamarts

Alcance Corporativo Departamental
Temas Múltiples Enfocados
Fuentes de Datos Muchas Pocas
Tiempo de implementación Meses a Años Meses
Tabla 2. Bodega de Datos Vs Almacén de datos

31
2.4.- Modelo Dimensional
El modelo dimensional, es una técnica aplicada en el diseño lógico de almacenes
de datos, utilizada para modelar la información en base a indicadores de negocio
que podrán ser analizados desde diferentes perspectivas o dimensiones de análisis.
(Ponniah, 2001).

Los elementos que conforman al modelo dimensional son los siguientes: hecho,
dimensión, jerarquías, cubo, celda, así como tablas de dimensión y hecho. (Kimball
& Ross, 2002).

2.4.1.- Hecho
El hecho es el resultado medible por parte de la organización y es el punto central
para la toma de decisiones. Algunos ejemplos de hechos son: cantidad vendida,
costo abonado, costo vs ganancia, entre otros. Es esencial que el hecho posea
aspectos dinámicos con el fin de poder observar la evolución a través del tiempo del
mismo (Kimball & Ross, 2002).

2.4.2.- Dimensión
Según (Wrembler & Koncilia, 2007), una dimensión es: “una propiedad del hecho,
que posee un dominio finito y describe una de las vías de análisis. El conjunto de
dimensiones de un hecho determina el nivel de detalle de los datos. Gráficamente,
las dimensiones son representadas por una caja que posee su nombre y atributos,
además de estar unidas al hecho”.

Los atributos que conforman a la dimensión son de tipo cualitativo, siendo su

principal objetivo establecer el contexto del hecho. Cada uno de los atributos que
componen a una dimensión puede estar organizado en una o más jerarquías.
Ejemplo: Si la dimensión es producto, sus posibles atributos serian: tipo – categoría
– marca.

32
2.4.3.- Jerarquía
Una jerarquía define la posición relativa de un atributo con respecto a otros
pertenecientes a la misma dimensión. Representados bajo una relación de tipo
jerárquica o bien conocida como forma de árbol, donde los atributos serán
progresivamente más detallados si se recorre de manera descendente el árbol hasta
llegar a las hojas, quienes son los que tienen mayor nivel de detalle. (Moliner López,
2005),

Son muy esenciales, porque sin ellas los reportes estarían sobrecargados con
demasiados detalles, haciendo más difícil, o casi imposible, identificar los problemas
y oportunidades dentro del almacén de datos.

Un ejemplo de jerarquía se puede observar en la Figura 6

Figura 6. Ejemplo de representación lógica de una jerarquía (Kimball & Ross,

2002)

2.4.4.- Cubo
Un cubo es una representación compleja generada por la intersección de las
dimensiones enfocadas en el hecho a medir. Siendo también denominado
Hipercubo, ya que depende del número de dimensiones asociadas al hecho, esta
estructura permite visualizar de mejor manera el Modelo Dimensional. (Kimball &
Ross, 2002).
En la Figura 7 se muestra una representación del cubo.

33
 Figura 7. Ejemplo de una representación lógica de un Cubo (Kimball & Ross,
2002)

2.4.5.- Celda
Representa la posición formada por la intersección de cada uno de los elementos de
las dimensiones que forman el cubo. La celda puede contener cantidades nulas, uno
o varios datos. (Inmon, 1999)

2.4.6.- Tabla de Hechos (FactTable)

Una tabla de hechos es la tabla principal en un modelo dimensional, donde los
valores de las medidas de una organización están almacenados y que serán
necesarias para el análisis. (Kimball & Ross, 2002).

Generalmente una tabla de hechos posee una clave primaria, definida por un
conjunto de claves foráneas. En un modelo dimensional, toda tabla que exprese una
relación de muchos a muchos debe ser la tabla de hechos. Las demás tablas son
denominadas tablas dimensión.

Un ejemplo de dichas tablas se muestra en la Figura 8.

34
 Figura 8. Tabla de Hechos (Pérez, 1999)

2.4.7.- Tabla Dimensión

Son aquellas tablas que se conectan a la tabla de hechos a través de las claves
foráneas y son las que permiten ver la información del negocio en distintas formas, a
través del almacenamiento de un conjunto de valores o atributos que describen
textualmente al negocio. Dichos atributos juegan un papel fundamental, porque son
la fuente para concretar la mayoría de las consultas y reportes, y por lo tanto,
constituyen la clave para el buen uso y entendimiento del Almacén de Datos.
(Kimball & Ross, 2002).

Ejemplo de una tabla dimensión se muestra en la Figura 9.

Figura 9. Tabla Dimensión (Pérez, 1999)

35
2.4.8.- Tipos de esquemas
Para soportar un esquema multidimensional, existen varios esquemas, los más
comunes son el tipo estrella, copo de nieve y constelación, los cuales se describirán
a continuación. (Royo, 2003)

Esquema en estrella
Existe una sola tabla de hechos la cual está relacionada a cada tabla dimensión.
Las dimensiones son enlazadas al hecho mediante la relación de clave foránea. La
clave primaria en la tabla de hechos está compuesta de una relación de claves
primarias de las dimensiones. Una representación de este tipo de esquema se
muestra en la Figura 10.

Figura 10. Diagrama en estrella del Hecho Ventas (Pérez, 1999)

36
Esquema copo de nieve (snowflake)

El esquema en estrella puede ser redefinido en el esquema copo de nieve con un

soporte para jerarquía de atributos, permitiendo que las tablas de dimensiones
tengan tablas de sub-dimensiones. Existen muchos usos para este tipo de
esquema, pero el más común es cuando las tablas dimensión son muy grandes o
complejas como para lograr representar el modelo de negocio con una topología en
estrella. (Uzcanga, 2008).

El problema es que, para extraer datos de las tablas en este esquema, en ocasiones
hay que vincular muchas tablas en las sentencias SQL que puede llegar a ser muy
complejo y difícil para mantener. En la Figura 11 se puede observar un ejemplo del
esquema copo de nieve.

Figura 11. Esquema en copo de nieve (Pérez, 1999)

37
Esquema Constelación

El esquema constelación es una variante del esquema estrella, representado como

un conjunto de esquemas estrella unidos por tablas dimensiones. Este esquema
está compuesto por dos o más tablas de hechos, el cual comparte algunas tablas
dimensionales; con posibilidad de poseer tablas dimensiones exclusivas para cada
tabla hecho En este tipo de esquema cada tabla de hecho que componen a la
constelación, puede tener niveles de granularidad diferentes haciendo más flexible
el modelo de negocio.

El beneficio principal de este tipo de esquema es que se tendrá un mejor uso del
espacio de almacenamiento evitando la redundancia de dimensiones, ya que
pueden ser compartidas, aunque los hechos posean granularidades diferentes. En
la Figura 12 se muestra un ejemplo de este tipo de esquema.

Figura 12. Esquema Constelación

38
2.5.- Indicadores de gestión de ventas en el Sector Salud
La identificación de los indicadores de gestión permiten el análisis y estudio la
situación y posibles tendencias de cambio generadas por las ventas producidas en
las empresas de salud, por lo tanto se definen a continuación los conceptos básicos
relacionados al área de ventas y posibles indicadores de gestión que apoyen a la
toma de decisiones de ésta área temática.

2.5.1.- Empresas del sector salud

Antes de definir las empresas del sector salud, se definirá que son empresas, a que
se refiere sector dentro del contexto de este trabajo especial de grado, para luego
definir las empresas del sector salud.

2.5.1.1.- Empresas
Según (RAE, 2010) “Unidad de organización dedicada a actividades industriales,
mercantiles o de prestación de servicios con fines lucrativos”.

2.5.1.2.- Sector

Según (RAE, 2010) “Conjunto de empresas o negocios que se engloban en un área

diferenciada dentro de la actividad económica y productiva. Ej. El sector del
automóvil”. Como también podríamos dar de ejemplo “sector salud”.

2.5.1.3.- Salud.

Según (RAE, 2010) “Estado en que el ser orgánico ejerce normalmente todas sus
funciones”.

Dado estas definiciones, se puede definir el sector salud como, las organizaciones o
instituciones dedicadas a prestar servicios y productos, con fines lucrativos, en el
área de la salud.

39
2.5.2.- Unidades de Atención
Las unidades de atención son áreas o unidades asistenciales donde se atienden a
los pacientes según el cuadro clínico que posea.
Las unidades de atención más comunes son:

Emergencia
Unidad asistencial encargada de atender a los pacientes que ingresan con alguna
dolencia de carácter de emergencia. En esta área los pacientes son atendidos lo
antes posibles el mismo día de su ingreso, y en caso de alguna complicación,
pueden ser trasladados a otra unidad de atención.

Hospitalización

Es un área específica de la institución acondicionada estructuralmente y preparada

para brindar de forma segura y organizada, asistencia multidisciplinaria a aquellos
pacientes con procesos agudos o crónicos que, están hospitalizados por alguna
complicación médica o por haber pasado por algún procedimiento médico o
quirúrgico, pero que no requieren de asistencia avanzada (respirador artificial,
monitoreo cardiaco, entre otros).

Unidad de Cuidados Intensivos (UCI)

Es una unidad asistencial en la que un médico especialista en medicina intensiva2

es responsable de prestar la atención médica precisa, continua e inmediata, a
pacientes que se encuentran en un avanzado estado de gravedad, y que su cuadro
clínico representa un riesgo actual o potencial para su vida; y que al mismo tiempo
su recuperación es incierta.

Cirugía

Unidad de atención compuesta por una estructura física acondicionada para la

práctica de intervenciones quirúrgicas. El quirófano permite la atención de los
pacientes por un equipo interdisciplinario (anestesiólogos, cirujanos principales y
secundarios y médicos de otras especialidades) para todos los actos que se hacen
bajo anestesia (general o local).

2
Se entiende por intensivista, un profesional médico que tiene una especialidad en atención al
paciente crítico y las competencias profesionales para desarrollarla.

40
Ambulatorio

Es una unidad de atención donde se presta atención médica a los pacientes sin
necesidad de ser admitidos en hospitalización. El paciente ingresa a la institución,
lleva a cabo el procedimiento correspondiente o tratamiento, y regresar a su hogar
el mismo día.

Neonatología

Es el área asistencial encargada de la prevención y tratamiento de enfermedades en

las etapas de la vida comprendidas entre 0 a 28 días de nacido.

Servicios Auxiliares o de apoyo clínico

Los servicios auxiliares son entes que prestan servicios de apoyo clínico a los
pacientes a través de estudios, citas y consultas médicas. Estos servicios se pueden
solicitar a través de la central de citas o por solicitud del médico tratante (en caso de
que el paciente se encuentre en alguna unidad de atención). Existen dos tipos de
servicios auxiliares: internos y externos. Los servicios externos son empresas
subcontratadas por la institución para ofrecer sus servicios dentro de las
instalaciones de la misma.

Entre los diversos servicios auxiliares que ofrecen las instituciones de salud se
encuentran:
- Banco de sangre - Terapia respiratoria
- Cardiología - Perinatología
- Densitometría ósea - Gastroenterología
- Ecosonografía - Nutrición
- Laboratorio - Hemodinamia
- Medicina nuclear - Anestesiología
- Rayos X
- Tomografía

41
2.5.3.- Conceptos Facturables
En el proceso de ventas de una institución de salud, los conceptos facturables
vienen dados por un conjunto de servicios, materiales y medicamentos, estudios y
honorarios médicos, que son cargados a los pacientes durante su estadía en la
institución.

Generalmente, estos conceptos se pueden clasificar en los siguientes 4 rubros:

- Gastos generales y hoteleros.
- Material médico quirúrgico y medicamentos.
- Honorarios médicos y/o procedimientos especiales.
- Estudios de un servicio auxiliar.

Gastos generales y hoteleros

Corresponde a los gastos internos generados por el paciente en cada unidad de
atención de la institución de salud. Estos gastos poseen diferentes frecuencias de
cobro (diario, por consumo, por ingreso al área y cobro único). Entre los gastos
diarios se encuentran: habitación, acompañante, computador cardíaco, unidad de
cuidados intensivos, residente permanente, entre otros; por ingreso al área: derecho
a admisión, derecho de emergencia, derecho a quirófano, monitor dinamap, manta
térmica, entre otros; y por consumo: kit de ingreso (compuesto por almohada, toalla
de mano, bandeja, jarra, paquete de pañuelos faciales, papel higiénico, termómetro,
entre otros), servicios asistenciales al recién nacido, servicio de incubadora,
medición de tensión arterial, entre otras.

Material médico quirúrgico y medicamentos

Corresponde a los gastos generados por el uso de materiales quirúrgicos o

medicamentos y drogas que son suministrados en las diferentes unidades de
atención, consumidos por el paciente al momento de una intervención quirúrgica o
simplemente durante su estadía en la institución. Entre ellos se encuentran, agujas,
recolectores, vendas, catéter, sondas, gasas, suturas, entre otros.

42
Honorarios médicos y/o procedimientos especiales

Corresponde a los gastos por concepto de honorarios médicos de los especialistas

que realizan procedimientos quirúrgicos o estudios con instrumentos y equipos
especiales.

Estudios de servicios auxiliares

Corresponde a los gastos generados por cada estudio que el paciente se realiza en
los diversos servicios auxiliares de la institución. Estos estudios pueden ser: punción
lumbar, eco cardiograma, electrocardiograma, drenaje de absceso, hemodiálisis y
así entre otros.

2.5.4.- Protocolos
Es una agrupación de conceptos (gastos hoteleros, materiales y medicamentos,
estudios y honorarios médicos) necesarios para la realización de un procedimiento
médico o quirúrgico. Algunos protocolos que se pueden mencionar son: cesárea,
punción lumbar, apendicitis por laparoscopia, entre otros.

2.5.5.- Presupuestos clínicos

Un presupuesto es una estimación de costos para el pago de uno o varios
procedimientos clínicos que el paciente va a realizar. Al momento de generar un
presupuesto se identifican el o los protocolos a realizar y se genera un estimado del
costo de los gastos asociados a los protocolos.

Los presupuestos tienen un periodo de validez y estos varían según las políticas de
las instituciones de salud.

2.5.6.- Responsable de pago

El responsable de pago es el encargado de asumir el pago de los gastos generados
por un paciente que ingresa a la institución. Todo paciente al momento de su
ingreso debe indicar la modalidad de pago (autopagante o seguro). Si la modalidad
de pago es autopagante significa que el paciente o alguna persona (natural o
jurídica) se compromete a pagar los gastos generados. Por el contrario, si la

43
modalidad de pago es seguro significa que los gastos están avalados por alguna
compañía de seguro o administradora de riesgo.

Es importante resaltar que generalmente las instituciones poseen convenios con las
compañías de seguro y administradoras de riesgo, por lo cual se cuenta con una
serie de baremos para los diferentes conceptos facturables, sin embargo pueden
existir conceptos facturables que no se encuentren tabulados como por ejemplo
materiales y medicamentos cuyos costos podrían variar según el precio actual del
inventario.

2.5.7.- Proceso de Atención al Paciente

Este proceso como se muestra en la Figura 13 se inicia al momento de ingresar el
paciente a la institución, donde es atendido por el departamento de Admisión y
Presupuesto. El departamento toma los datos personales del paciente y de ser
necesario se realiza una pre-admisión. Una vez culminado el proceso de admisión,
el paciente es remitido a la unidad de atención correspondiente según su cuadro
clínico y se le apertura un caso.

Durante su estadía en la institución se comienzan a realizar cargas al caso por los

diferentes conceptos (gastos hoteleros, materiales y medicamentos, estudios
médicos y honorarios médicos), Estas cargas son realizadas por las enfermeras,
almacenistas o facturadores del área.

En el departamento de facturación existen auditores que se encargan de revisar

diariamente los conceptos cargados a los pacientes que están ingresados en la
institución. Adicionalmente tienen la potestad de realizar cargas y de anularlas.
También son responsables de verificar que los gastos generados por las cargas de
los conceptos no sobrepase la cobertura del seguro y de ser así avisar al
responsable de pago.

Una vez que el paciente es atendido y sus condiciones de salud por la cual ingresó
son estables o superadas, recibe de parte del médico tratante el alta médica, y es

44
entonces cuando las enfermeras informan a los auditores que el paciente ya está
listo para egresar.

En ese momento se inicia otro proceso, que es la generación de la factura. Los

auditores deben revisar que todas las cargas se hayan realizado de manera correcta
y que el responsable de pago esté en la capacidad de cubrir la deuda. Luego se
procede a generar la factura como tal y se le da el alta administrativa al paciente,
pudiendo éste retirarse de la institución.

Figura 13. Proceso de Admisión/Cargas/Facturación

El estudio de los procesos de admisión, consumos al paciente y facturación son

determinantes ya que las ventas en el sector salud vienen dadas a través de los
productos y servicios prestados al paciente, en consecuencia son vitales para la
elaboración de indicadores de gestión.

45
2.5.8.- Indicadores de gestión
Los indicadores de gestión son parámetros que nos permiten medir y comparar a lo
largo del tiempo resultados obtenidos en un periodo de gestión. Cada indicador
mide o clasifica un aspecto del negocio (por ejemplo eficiencia, eficacia y calidad) y
gracias a estos se puede construir un indicador que refleje lo que se pretende medir
(Salgueiro Anabitarte, 2001).

Además, los indicadores de gestión están relacionados con el modo en que las
organizaciones generan los servicios o productos, ya que el valor del indicador es el
resultado de su medición y constituye un valor de comparación.

Por lo tanto, el objetivo principal de los indicadores es evaluar el desempeño de la

organización mediante metas establecidas. Así mismo, permite observar la
tendencia en un período de tiempo durante un proceso y con los resultados
obtenidos, plantear soluciones que contribuyan al mejoramiento y que conlleven a la
obtención de las metas fijadas.

Tipos de indicadores de gestión

A continuación se especificarán los tipos de indicadores (Salgueiro Anabitarte,

2001):
Indicadores de cumplimiento: se refiere a los tiempos de cumplimiento de las
tareas, entendiéndose como la conclusión de las mismas.
Indicadores de evaluación: estos indicadores ayudan a identificar fortalezas,
debilidades y oportunidades en el negocio.
Indicadores de eficiencia: se refiere a lograr los objetivos consumiendo la
menor cantidad de recursos.
Indicadores de eficacia: se refiere a lograr los objetivos sin importar los
recursos consumidos.

En el contexto del área de ventas del sector salud y tomando en cuenta que por
medio de los indicadores se permite el análisis y estudio del negocio, así como las
tendencias de cambio generadas por las ventas, las empresas de salud pueden

46
medir y ser más competitivas con respecto a la ventas de sus servicios y productos
ofrecidos, además de optimizarlos y así poder competir en este mercado. En el
siguiente apartado se muestra una lista de posibles indicadores para el área de
ventas del sector salud.
Ventas por productos y servicios ofrecidos en un período de tiempo.
Desviación de ventas en un periodo de tiempo.
Comparación del costo de los productos y servicios vendidos contra el precio
de venta.
Cantidad de productos vendidos por mes.

2.6.- Herramientas de BI
Son sistemas compuestos por un conjunto de aplicaciones para crear soluciones de
BI que permiten consultar y manejar grandes volúmenes de datos para facilitar la
toma de decisiones.

Existen varias herramientas para el desarrollo de una solución BI y dependiendo de

las características, limitaciones (costo, incompatibilidad, garantía de soporte, entre
otros) y necesidades, se adopta la más adecuada. Algunas herramientas que
actualmente se encuentran en el mercado son: Cognos Business Intelligence de
IBM, Pentaho, JPalo, MicroStrategy, Business Object de SAP, SAS y Oracle
Business Intelligence. Después de haber realizado un estudio comparativo entre
estas herramientas como se muestra en el anexo 2, se evidencia que todas las
herramientas antes nombradas cuentan con los componentes mínimos y necesarios
para el desarrollo de la solución propuesta, entre los cuales se tiene: visión unificada
de los datos, creación personalizada de informes y consultas analíticas, cuadros de
mando para la presentación de los indicadores y la herramienta para la construcción
del almacén de datos.

47
2.6.1. - Oracle Business Intelligence Suite
Oracle Business Intelligence Suite es una plataforma para crear soluciones de BI, la
cual ofrece una infraestructura de BI unificada e integrada que incluye un conjunto
completo de productos, que abarcan: construcción de datamarts o datawarehouse,
consultas y análisis, creación de reportes, capacidad de análisis para dispositivos
móviles, dashboards y tecnología de portal, integración con Microsoft Office, flujo de
trabajo inteligente, alertas en tiempo real, Business Activity Monitoring (BAM), etc.
Oracle Business Intelligence Suite forma parte de los productos de Oracle Fusion
Middleware y posee tres ediciones (Lambertini & Cortés, 2009):
Oracle Business Intelligence Suite Enterprise Edition, integra la tecnología de
análisis de negocios de Siebel con la tecnología de BI y middleware
existente de Oracle para ofrecer una infraestructura y herramientas de BI a
toda la empresa.
Oracle Business Intelligence Suite Standard Edition, ofrece una
infraestructura y herramientas integradas previamente de BI para un entorno
Oracle. Esta herramienta es conocida como Discoverer.
Oracle Business Intelligence Suite Standard Edition One, es un producto
especialmente diseñado para la construcción de soluciones de BI a
pequeñas y medianas empresas.

En la Figura 14 se puede apreciar las diferencias y similitudes entre los

componentes de Oracle Business Enterprise Edition y Oracle Business Intelligence
Standard Edition One.

48
 Figura 14 Oracle BI Enterprise Edition Vs Oracle BI Standard Edition One
(Oracle)

2.7. - Oracle Business Intelligence Standard Edition One (OBI)

Oracle BI Standard Edition One es un sistema completo e integrado de BI diseñado

para pequeñas y medianas empresas o grupos de trabajo. (Oracle, 2007). Cuenta
con los componentes básicos para crear y gestionar una solución de BI
departamental como se observa en la Figura 15.

Figura 15. Componentes de Oracle BI Standard EditionOne. (Oracle)

Abarca todas las propiedades antes mencionadas como importantes principios de

diseño, incluye:

49
• Oracle Database Standard Edition One.Está diseñado para su despliegue en
entornos de pequeñas y medianas empresas, es fácil de instalar y configurar. Puede
ayudar a manejar los datos, y permite a las aplicaciones tomar ventaja sobre el
rendimiento, disponibilidad, seguridad y fiabilidad proporcionada por la Base de
Datos Oracle. Oracle Database 10g Standard Edition One también proporciona
compatibilidad completa con otras ediciones superiores de la base de datos,
soportando así la incrementabilidad. Un ejemplo del administrador de Oracle
Database standard Edition One se muestra en la Figura 16.

Figura 16. Oracle Database Standard Edition One (Oracle, 2010)

• Oracle Warehouse Builder (OWB). Es una herramienta para la creación de

almacenes de datos o datamarts y para la integración de datos. Con funciones para
garantizar el almacenamiento, calidad de los datos y además la gestión de
metadatos.

Las principales características de OWB incluyen:

Extracción, Transformación y Carga (ETL). Recopila datos de múltiples
fuentes (fuentes relacionales como: SQL Server, archivos ASCII, hojas de
cálculos, entre otros).
Los datos de perfiles y la calidad de los datos.

50
 Gestión de metadatos.
A nivel de negocio de integración de datos de aplicaciones ERP.
Integración con herramientas de BI de Oracle para la elaboración de
informes.

En la Figura 17 se muestra un ejemplo de un modelo dimensional creado en Oracle

Warehouse Builder

Figura 17. Oracle Warehouse Builder (Oracle)

• Oracle Business Intelligence Server. El Servidor de BI es capaz de integrar

distintas fuentes de datos heterogéneas en un solo repositorio. Puede generar
simultáneamente SQL optimizado frente a múltiples fuentes de datos, sean éstos
archivos ASCII, multidimensionales o relacionales. Esto implica, que los usuarios
pueden disfrutar del análisis operacional de los tableros de control o las consultas
ad-hoc, frente a un solo nivel de presentación. Un nivel de metadatos que brinda a
los usuarios informes y elementos en términos sencillos, así todos los elementos
pueden exponerse a un análisis único sin dificultades y publicarse en un informe o
en un tablero de control debido a que el Servidor BI coordina las consultas de cada
fuente de manera óptima.

Entre las fuentes de datos o aplicaciones, que maneja están:

Oracle Database, Oracle Database OLAP, Oracle e-Business Suite, Oracle
PeopleSoft EPM, Oracle Siebel CRM, SAP B/W, Microsoft SQL Server, Servicios de

51
Análisis Microsoft, Microsoft Office Excel, Base de datos IBM DB/2,
TeradataWarehouse, Fuentes ODBC, Archivos ASCII, XML, entre otros. En la
Figura 18 se muestra el funcionamiento del servidor de BI.

Figura 18. Oracle Business Intelligence Server (Oracle, 2007)

• Oracle Business Intelligence Interactive Dashboards. Es una herramienta que

permite a los usuarios crear y tener acceso a los cuadros de mandos para visualizar
la información. Brinda información filtrada y personalizada según el rol del usuario,
haciendo que la información sea intuitiva y fácil de comprender, apoyando a la toma
de decisiones precisas y efectivas. Los usuarios trabajan con informes, solicitudes,
cuadros, tablas, tablas pivote, gráficos actualizados. Los usuarios tienen la
capacidad de navegar rápida y fácilmente por la información que necesitan, realizar
desgloses para un futuro análisis, modificar cálculos e interactuar con los resultados.

Oracle BI Interactive Dashboards ofrece una característica denominada Navegación

Guiada. Esto permite que se muestren las alertas en las páginas en caso de ocurrir
una excepción comercial. En la Figura 19 se muestra un ejemplo de un Interactive
Dashboards.

52
 Figura 19. Business Intelligence Interactive Dashboards (Oracle)

• Oracle Business Intelligence Answers. Herramienta para el análisis y

construcción de consultas a la medida, totalmente integrada con Interactive
Dashboards y BI Publisher. Los usuarios finales pueden explorar e interactuar con
información mediante gráficos, tablas dinámicas, y los informes. Los resultados
pueden ser mejorados a través de gráficos, cálculo de los resultados de diseño, y
características de desglose. Esto implica que los usuarios pueden fácilmente
presentar los resultados en una página del tablero de control para una revisión
empresarial o cualquier otro propósito. Permite a los usuarios consultar todos los
activos de datos en la empresa, independientemente del formato que presenten. En
la Figura 20 se muestra un ejemplo de la interfaz de la herramienta Oracle Business
Intelligence Answer.

53
 Figura 20. Oracle Business Intelligence Answers (Oracle)

• Oracle Business Intelligence Publisher.

Oracle BI Publisher brinda una solución para generar documentos y reportes, a
partir de casi cualquier fuente de datos o aplicación. Los usuarios finales pueden
diseñar fácilmente diseños de reportes directamente en un navegador Web o
mediante herramientas familiares de escritorio, reduciendo el tiempo y los costos
para desarrollar y mantenerlos reportes. Los usuarios se pueden aprovechar de las
herramientas de escritorios comunes y tradicionales como Microsoft Office Word,
Microsoft Office Excel, y Adobe Acrobat para generar sus platillas de reportes. En la
Figura 21 se muestra un ejemplo de Publisher.

Figura 21. Oracle Business Intelligence Publisher (Oracle, 2007)

54
CAPÍTULO 3: MARCO METODOLÓGICO.
El desarrollo de una solución BI puede llegar a ser complicado e incluso puede fallar
su implementación sino se siguen una serie de pasos y lineamientos, es por esto
que este capítulo está dedicado a la definición de la metodología para la
construcción de una solución de inteligencia de negocio según (Kimball & Ross,
2002), la cual es una de las más usadas por su nivel de detalle, y por su relativa
facilidad de implementación y adaptación a la organización.

3.1.- Metodología de Ralph Kimball - Ciclo de Vida del Modelo de

Negocio.
La metodología de Ralph Kimball se compone por una serie de fases como se
muestra en la Figura 22, las cuales se desarrollan como sigue:

Figura 22. Ciclo de Vida del Modelo de Negocio por Kimball. (Kimball & Ross,
2002)

3.1.1.- Planificación del proyecto.

La planificación del proyecto es la primera etapa dentro del ciclo de vida para el
desarrollo de un almacén de datos, dando pie a una serie de actividades como lo
son la definición, alcance, evaluación y la justificación del proyecto.

55
En el caso de la definición, existen factores identificados por el autor, que
diferencian a los proyectos fallidos de los que han logrado seguir en pie. Estos
factores son:
Poseer un aliado empresarial comprometido con el proyecto, su papel
principal será de conciliador entre el proyecto y la organización. Esta
persona, debe ser un líder políticamente astuto que pueda convencer a
sus compañeros para que estos también apoyen la solución.
La existencia de una fuerte motivación organizacional por la construcción
del almacén de datos.
La factibilidad y disponibilidad los de datos.
Uso de tecnologías de información. Algunas organizaciones no usan
tecnología de información para realizar sus labores cotidianas y desean
adentrarse en este tipo de proyectos, dedicándole así más atención en
mantener y manejar los mismos objetivos.
La preparación de la cultura actual hacia el nuevo enfoque.

Definición del Alcance

Una vez que se ha logrado un acuerdo con la organización, es el momento para
poner los límites del proyecto. La determinación del alcance requiere la participación
conjunta tanto del departamento de tecnología de la información, como de la gestión
empresarial.

Justificación.

Estimación de los beneficios y costos asociados al desarrollo e implementación de

este tipo de solución. Es necesario estimar los costos aproximados para el hardware
y software que serán usados. Debido a que los almacenes de datos tienden a
expandirse rápidamente, es recomendable realizar estimaciones a corto plazo.

Adicionalmente, en la fase de planificación se debe seleccionar una aplicación piloto

que posea alta probabilidad de éxito, así como la construcción de prototipos rápidos
y frecuentes que apoyen el desarrollo del proyecto, reportar y publicar casos
exitosos y finalmente tener a disposición herramientas que sean fáciles de usar y
que den posibles visualizaciones del proyecto.

56
3.1.2.- Definición de los requerimientos del negocio.
La definición de los requerimientos está constituida por la definición de las
necesidades del negocio que se desean medir, así como el planteamiento de cómo
recolectar los requerimientos, la recolección de documentos y el seguimiento de los
mismos

Se centra principalmente en reunir el conocimiento de los analistas de la

organización, entendiendo los factores claves que determinan los requerimientos del
negocio y establecer los fundamentos de tecnología, datos y aplicaciones de usuario
final, para así obtener los posibles factores a medir o indicadores.

Adicionalmente en esta etapa, se fijan políticas de seguridad de datos, posibles

roles y usuarios.

3.1.3.- Diseño técnico de la arquitectura.

En el desarrollo del proyecto del almacén de datos, el diseño de la arquitectura es
un aspecto que puede generar conflictos, debido a que algunos grupos de desarrollo
no prestan la atención debida a este punto, le restan importancia y descuidan
elementos que más adelante generaran problemas en el desarrollo del proyecto.

Todo almacén de datos posee una arquitectura técnica, y por esto (Kimball & Ross,
2002) ha identificado una serie de pasos a seguir, que ayudarán a conseguir los
objetivos deseados en esta etapa.

El primer punto es el establecimiento de un grupo de trabajo especial, conformado

por dos o tres personas centradas en el diseño de la arquitectura. Por lo general, lo
conforma un arquitecto técnico que maneja aspectos de diseño y desarrollo de
aplicaciones analíticas, y a su vez es el coordinador del grupo, quien garantizará el
buen funcionamiento del mismo.

57
El segundo punto es la recolección de requerimientos de la arquitectura, donde se
debe identificar las implicaciones arquitectónicas asociadas con las necesidades
críticas del negocio.

Además de aprovechar los requerimientos del negocio, también se llevan a cabo

entrevistas adicionales dentro de la organización. Dichas sesiones, están enfocadas
en la tecnología, para comprender normativas vigentes, instrucciones técnicas
previstas y los limites no negociables.

El siguiente punto trata de la necesidad de documentar hallazgos, donde

simplemente se listen todos los requisitos del negocio que tienen un impacto en la
arquitectura, en conjunto a los aspectos que resultan de la construcción de la
arquitectura del almacén de datos, dando pie al siguiente punto, donde se utiliza
esta documentación para realizar el modelo de la arquitectura a un nivel más alto,
porque se ilustran los componentes principales como son la puesta en escena de
los datos, el acceso a los datos, metadatos y la infraestructura. Se puede decir que
el modelo generado es similar a los planos de una vivienda.

Seguidamente, se realiza un estudio preliminar de sistemas que den apoyo a los

requerimientos antes mencionados, considerando adicionalmente las necesidades
de seguridad, infraestructura física y las necesidades de configuración. En algunos
casos las decisiones de infraestructura, como el hardware del servidor y el software
de base de datos ya están predeterminadas.

El estudio de la implementación por fases es el siguiente paso, y va de la mano con

la documentación técnica de la arquitectura.

Finalmente, la culminación y constante revisión de la arquitectura técnica es el

último paso a seguir, anunciando el plan de la arquitectura al equipo de proyecto, los
colegas, empresas patrocinadoras y demás entes del negocio involucrados en el
proyecto del almacén de datos.

58
En caso de una revisión, la documentación debe ser actualizada y puesta en
práctica de inmediato en el proceso de selección de productos.

3.1.4.- Selección de productos e instalación.

La selección de los productos está estrechamente relacionada al plan de
arquitectura planteado en el paso anterior, e incluye una serie de tareas especificas
para una buena elección de productos, los cuales vienen dados por la comprensión
de los procesos de negocio, el establecimiento de un plan de evaluación del
producto, donde se coloquen ponderaciones para indicar la importancia de los
elementos y cuyos criterios comunes tomados en esta fase sean funcionalidad, la
arquitectura técnica, las características de software, el impacto de las
infraestructuras y la viabilidad de los proveedores. Adicionalmente, se debe realizar
un estudio de las herramientas disponibles en el mercado, que puedan dar soporte a
las necesidades del proyecto. Este estudio arrojará puntuaciones que serán
tomadas en cuenta para limitar la lista de proveedores, y comenzar a realizar una
evaluación más detallada, donde podría surgir la creación de un prototipo con no
más de dos productos y así demostrar cuál de las herramientas satisface mejor las
expectativas de la organización.

Una vez seleccionado el producto, comienzan las negociaciones directas con el

proveedor, a quien se debe confrontar constantemente con la finalidad de seguir en
un periodo de prueba, donde este tiene la oportunidad de utilizar su producto en el
entorno real de la empresa. Y finalmente a medida que el juicio llega a su fin, se
procede a la negociar el proceso de compra.

3.1.5.- Diseño del Modelo Dimensional.

Para la elaboración del diseño del modelo dimensional se plantean los siguientes
pasos:

Definir del nivel de granularidad. Una vez que en el paso anterior se determina el
proceso del negocio, el paso siguiente es determinar la granularidad, es decir, el
nivel de detalle al que se desea almacenar información del proceso a modelar. Para
la determinación del nivel de granularidad se debe responder a la pregunta “¿Cuál

59
es el nivel de detalle con que deseo medir? o ¿Cómo se representaría una fila en la
tabla de hechos?”. Ejemplos: Si nuestro negocio consiste en ventas de productos a
clientes y al realizar estas ventas se genera una factura por cliente, debemos decidir
que queremos almacenar, si el monto total de la factura o el detalle de los montos
por productos.

Determinar las dimensiones. Las tablas dimensiones son compañeros integrales

de una tabla de hechos. Los atributos de la dimensión sirven como fuente principal
para limitaciones de consulta, agrupaciones y etiquetas dentro del reporte. En una
solicitud de consulta o de reporte, los atributos son identificados por los
requerimientos de los usuarios. Por ejemplo, cuando un usuario declara que quiere
ver los montos de venta por semana y por la marca, donde la semana y la marca
deben de estar disponibles como atributos de la dimensión.

Los atributos de la tabla de dimensiones juegan un rol vital dentro del almacén de
datos, puesto que son la fuente de las restricciones de búsqueda y campos de los
reportes. El poder del almacén de datos es directamente proporcional a la calidad
de la profundidad lograda por los atributos de las dimensiones.
Las tablas de dimensiones son los puntos de entrada en la tabla de hechos. Sí los
atributos de las dimensiones son robustos entonces las capacidades analíticas
también lo serán. Los mejores atributos son textuales y discretos, deben estar
identificados por palabras reales, no abreviaturas. Los atributos típicos de una
dimensión producto por ejemplo incluyen una breve descripción compuesta máximo
por 30 o 50 caracteres, una marca, un nombre de categoría, tipo de empaque,
tamaño y otras características del producto.

En ocasiones, cuando se diseña el modelo dimensional no se tiene claro si un

campo de datos numérico extraído de la fuente de datos es un hecho o un atributo
de dimensión. A menudo se toma la decisión, preguntando si el campo es una
medida que toma diferentes valores y que participa en los cálculos (lo que define al
hecho) o básicamente es una descripción discreta, posiblemente constante y que
participa en las limitaciones (lo que define a un atributo dimensional). Por ejemplo, el

60
costo puede cambiar tan a menudo que finalmente se decida que es más como un
hecho medible.

Las tablas dimensiones a menudo representan las relaciones jerárquicas de la

organización, por ejemplo dentro de la tabla producto las dimensiones podrían
identificar a los productos según la marca o según su categoría, almacenando en
cada fila de la tabla dimensión la descripción de la marca y la categoría asociada a
cada producto, facilitando el uso y rendimiento de las consultas a pesar de la
evidente redundancia de datos, proceso que define la desnormalización de las
tablas.

Determinar el hecho. La tabla de hecho es la tabla principal en un modelo

dimensional donde el desempeño medible del negocio es almacenado. Nos
esforzamos para almacenar los datos medibles resultantes de los procesos del
negocio de un almacén.

Se usa el término hecho para representar la medida del negocio. Ejemplo: Estar en
un mercado observando los productos que son vendidos y anotar la cantidad
vendida y el monto en dinero vendido por cada día de cada producto en esa tienda.
Una medición se realiza entonces, con la intersección de todas las dimensiones
(día, producto y tienda). Esta lista de dimensiones define el grano de la tabla de
hecho y el nivel de alcance de la medida.

Una fila en la tabla de hecho corresponde a una medida por lo tanto todas las
medidas en la tabla de hecho debe tener el mismo nivel de granularidad.

El hecho más usable en una tabla de hechos son los numéricos y los sumarizables.
Es teóricamente posible para un hecho medible ser textual. Sin embargo, esto se
presenta raramente. En la mayoría de los casos, una medida textuales una
descripción de algo y se extrae de una lista de valores discretos.

Todas las tablas de hechos tienen dos o más claves foráneas, que conectan con las
tablas dimensión a través de sus claves primarias. Por ejemplo, una clave de

61
producto en la tabla de hecho siempre coincidirá con un producto específico de la
dimensión producto. Cuando todas las claves foráneas de la tabla de hecho hacen
referencia a sus respectivas claves primeras en las dimensiones correspondientes,
entonces se dice que las tablas satisfacen la integridad referencial. Se accede al
hecho como tal a través de la intersección de las dimensiones combinadas.

La tabla de hecho por sí misma tiene su propia clave primaria formada por un
subconjunto de claves foráneas. Esta clave es comúnmente llamada clave
compuesta o clave concatenada. Cada tabla de hecho en un modelo dimensional
tiene una clave compuesta, por lo que, cada tabla que contenga una clave
compuesta es una tabla de hecho. Las tablas de hechos expresan relaciones de
muchos a muchos entre dimensiones en los modelos dimensionales

Finalizado el esquema se procede a la validación del mismo y para esto se requiere

de una evaluación mucho más detallada, centralizada en la realización de preguntas
que puedan ser respondidas por este modelo. Una vez que el grupo de trabajo
encuentre que el modelo cumple con los objetivos, es presentado al grupo de
tecnologías de información y a los encargados del almacén de datos y finalmente,
luego de varias pruebas ser presentado a la comunidad del negocio.

Una vez que se tienen definidas las tablas de hechos y dimensión, se deben
relacionar a través de las claves primarias y foráneas correspondientes.

En los modelos dimensionales, podemos añadir nuevas dimensiones en el esquema

siempre y cuando al menos un valor de la dimensión clasifique o defina cada uno de
los hechos existente en la tabla de hechos .Del mismo modo, podemos añadir
nuevos hechos imprevistos a la tabla de hechos, asumiendo que el nivel de detalle
es coherente con los hechos existentes.

Existe una relación natural entre los modelos dimensionales y los normalizados. La
clave es entender que la relación se encuentra en el desglose del modelo entidad
relación dentro de los múltiples esquemas dimensionales posibles de modelar

62
Finalmente se realiza la documentación en esta fase que debe contener los
nombres de las tablas y columnas, las definiciones y normas de cálculo, ya sea para
el hecho o para un atributo de alguna dimensión. Adicionalmente, debe contener
ciertos estándares con respecto a las convenciones de nomenclaturas para la
identificación de los elementos.

3.1.6.- Diseño Físico.

Dado que se posee el modelo dimensional lógico, se procede a su implementación
física. En esta fase se debe seleccionar las estructuras necesarias que puedan dar
soporte al diseño lógico, así como definir algunos aspectos importantes como son
las convenciones estándares de nombres, tipos de datos, declaraciones claves y
permisividad de valores nulos. Aspectos referentes al ambiente de bases de datos
así como indexación, estrategias de particionamiento, ajustes de rendimiento y
distribución de archivos.

3.1.7.- Diseño y construcción de procesos ETC.

En el diseño de los proceso de extracción, transformación y carga (ETC), como ha
sido expuesto anteriormente, implica la extracción de los datos generalmente de los
sistemas operacionales y la preparación de los estos para su puesta en escena en
el área de presentación de los datos.

En esta etapa se deben formular planes, parecidos a los elaborados en el diseño de

la arquitectura, así como analizar el planteamiento de compra de una herramienta
que realice los procesos ETC o la elaboración de una herramienta propia. Otra
decisión fundamental es con respecto a la estructura de los almacenes de datos,
donde la normalización de los datos de origen, es lo más apropiado aunque no muy
necesario pero aumenta la credibilidad los datos.

3.1.8.- Especificación y desarrollo de aplicaciones analíticas.

El primer paso para la especificación de las aplicaciones analíticas, es el estudio de
un conjunto de herramientas posibles, que puedan ayudar a solventar las
necesidades del negocio. Luego de haber definido la herramienta, se procede a

63
establecer estándares de diseño como características del menú y la apariencia del
entorno.

En la fase de desarrollo de la aplicación, también se deben establecer ciertas

normas. Convenciones de nomenclatura a usar, los cálculos que se realizarán, las
bibliotecas y hasta la forma de codificación. La actividad de desarrollo de
aplicaciones puede comenzar una vez que el diseño de la base de datos esta
completa. Las herramientas de acceso a los datos y metadatos están instalados, y
un subconjunto de los datos históricos se han cargado.

Mientras la aplicación está siendo desarrollada, varios beneficios secundarios

resultan. Los desarrolladores de aplicaciones, equipados con una herramienta
robusta de acceso a los datos, rápidamente podrán encontrar respuestas a los
diferentes problemas. Esta es una razón por la que los desarrolladores prefieren
comenzar las actividades de desarrollo de las aplicaciones lo antes posible.

3.1.9.- Integración y despliegue.

La tecnología, datos y aplicaciones analíticas convergen en el despliegue, donde se
logra la unificación de las tecnologías, datos y la aplicación de usuario final.
Adicionalmente, la educación es fundamental en esta etapa, debido a que es la vía
para la aceptación exitosa del almacén por parte de la comunidad de la
organización. El programa de adiestramiento debe estar enfocado en aspectos
como, estándares de datos, exploración sobre las aplicaciones analíticas, y
finalmente uso de la aplicación para el acceso de los datos.

3.1.10.- Mantenimiento y crecimiento.

Una vez terminado el desarrollo completo, no se debe olvidar los siguientes puntos:
- Soporte: Se deberá hacer mantenimiento tanto de soporte técnico como de
programación periódicamente al sistema, y estos deben estar programados
de tal manera que no interrumpan con el desarrollo del negocio. Se debe
mantener vigilado el funcionamiento del negocio para poder estar preparado
a realizar cualquier tipo de cambio necesario para adaptar el sistema a las
nuevas necesidades.

64
- Capacitación de los usuarios: se debe capacitar a los usuarios para que
realicen un buen uso del sistema y así, se logre mantener una calidad
estable en los datos.

65
CAPÍTULO 4: MARCO APLICATIVO
En este capítulo presenta cómo la metodología de Ralph Kimball fue aplicada para
el desarrollo de una solución de inteligencia de negocio en el área de ventas de
instituciones del sector salud. Se explican aspectos propios de la arquitectura de la
solución planteada como la base de datos intermedia, diseño y construcción del
almacén de datos, elaboración de procesos ETC y diseño y construcción de las
consultas analíticas para el despliegue de los indicadores de gestión relevantes en
el área de ventas en el sector salud.

A continuación se describe con detalle los procesos que se realizaron en cada una
de ellas para llevar a cabo la solución.

4.1.- Planificación del proyecto.

Se realizó un estudio de diversas empresas en el área de ventas que prestan
servicios de salud, donde se planteó realizar una solución de BI adaptable a
cualquier empresa interesada en la medición de su negocio a través la identificación
de una serie de indicadores comunes, que permitan monitorear y controlar los
procesos relacionados con las ventas de productos y servicios prestados.

Para lograr este objetivo se investigaron una serie de indicadores relacionados con
las ventas y se discutieron acerca de los posibles indicadores que podrían requerir,
se listaron los que se podían utilizar para las empresas del sector salud.

4.2.- Definición de los requerimientos del negocio.

Para levantar los requerimientos del negocio se estudiaron diversas empresas
reconocidas del sector salud. Una vez estudiados los procesos del negocio de estas
empresas, se pudo identificar requerimientos comunes básicamente relacionados
con los productos y servicios que facturan en función de variables como el tiempo,
cliente y área de facturación y se listaron en una matriz.

66
Posteriormente, se produjo una fase de selección y se establecieron las fórmulas
que podían resolver dichas consultas, la unidad de medida correspondiente y una
breve descripción tal y como se muestran en las siguientes tablas, donde la tabla 3
posee indicadores de medición y tabla 4 posee indicadores de comparación,
permitiendo identificar la dimensionalidad de cada indicador y así especificar los
diferentes grados de detalle dentro de cada concepto del negocio propuesto.
Nombre Formula Unidad Glosario

Total ventas en Bolívares Monto total de ingresos

un período de percibidos por la venta de
tiempo servicios y productos
Donde i es un concepto en particular y j es (gastos hoteleros, materiales
un tipo_concepto y medicamentos, honorarios
médicos y estudios).

Monto vendido por Bolívares Monto total de ventas por

servicios y producto o líneas de
productos en un ( )j servicios.
período de tiempo.
Donde i es un concepto en particular y j es
un tipo_concepto

Cantidad vendida Bolívares Cantidad total de ventas por

por Unidad de Unidad de atención.
Atención en un ( )j
período de tiempo.
Donde i es un concepto en particular y j es
una Unidad de atención.

Monto vendido por Bolívares Monto total vendida por tipo

tipo de cliente en de Cliente Autopagante o
un período de ( )j Seguro.
tiempo
Donde i es un concepto en particular y j es
un tipo_cliente.

Monto vendido por Bolívares Monto total vendido por

tipo responsable Sexo, Edad, Educación o
en un período de escolaridad, diagnostico de
tiempo ingreso o diagnostico de
Donde i es un criterio o perspectiva de egreso.
selección

Total ventas por Bolívares Monto total de ventas por

responsable responsable autopagante
Autopagante en
un período de
tiempo Donde i es un responsable autopagante

Total ventas por Bolívares Monto total de ventas por

responsable responsable seguro
Seguro en un
período de tiempo

67
 Donde i es un responsable seguro

Porcentaje de Porcentaje Determina si la empresa

desviación de aumenta o disminuye su
ventas en un volumen de negocio en un
período de tiempo período de tiempo.
Donde Ventasa son las ventas actuales y
las Ventasb son las ventas del periodo
contra el que se quiere comparar.

Top 10 de ventas Bolívares Selección de los 10 servicios

por estudios en un que generen mayores
período de tiempo Donde Ventasa representan el monto de las ganancias en un periodo de
(penetración) ventas obtenidas por i estudio. tiempo.

Top 10 de ventas Bolívares Selección de los 10 doctores

por honorarios que generen mayores
médicos en un Donde Ventasa representan el monto de las ganancias en un periodo de
período de tiempo ventas obtenidas por i honorario medico. tiempo.
(penetración)

Top 10 de ventas Bolívares Selección de los 10 gastos

por gastos hoteleros que generen
hoteleros en un Donde Ventasa representan el monto de las mayores ganancias en un
período de tiempo ventas obtenidas por i gasto hotelero periodo de tiempo.
(penetración)

Top 10 de ventas Bolívares Selección de los 10 servicios

por materiales y auxiliares que generen
medicamentos en Donde Ventasa representan el monto de las mayores ganancias en un
un período de ventas obtenidas por i servicio auxiliar periodo de tiempo.
tiempo
(penetración)

Top 10 de seguros Bolívares Selección de los 10 seguros

en un período de que más facturan en un
tiempo Donde Ventasa representan el monto de las periodo de tiempo.
(penetración) ventas obtenidas por i seguro

Top 10 de Bolívares Selección de los 10

responsables responsables autopagantes
Autopagante en Donde Ventasa representan el monto de las que más facturan en un
un período de ventas obtenidas por i autopagante periodo de tiempo.
tiempo
(penetración)

Cantidad de Unidad Cantidad de presupuestos

presupuestos facturados por cada unidad
facturados por Donde por i de atención
unidad de representa cada unidad de atención
atención en un
período de tiempo

Tabla 3. Indicadores de ventas

68
 Nombre Fórmula Unidad Glosario

Margen de utilidad por Bolívares Diferencia entre precio de

producto y servicio en un venta y costo del producto
período de tiempo en un período de tiempo
donde p es un producto o servicio e
i es un período de tiempo

Margen de utilidad por Bolívares Diferencia entre precio de

unidad de atención en un venta y costo del producto
período de tiempo por unidad de atención
donde p es un producto o servicio e
i es una unidad de atención

Desviación porcentual de Porcentaje Porcentaje de ventas por

ventas en un período de mes en un periodo de
tiempo tiempo

Diferencias de montos Bolívares Monto presupuestado

facturados versus contra monto facturado por
presupuestados por unidad de atención en un
unidad de atención en un periodo de tiempo.
donde p es una unidad de atención
período de tiempo.
e i es un periodo de tiempo

Tabla 4. Indicadores de comparación de ventas

4.3.- Diseño de la arquitectura.

El diseño de la arquitectura de la solución BI que se implementó se puede observar
en la siguiente Figura 23:

ETC ETC

Fuentes de Datos Base de Datos Intermedia Almacén de Datos Cuadros de Mando y

Reportes

Figura 23. Diseño Técnico de la Arquitectura (Juliet, 2010)

La arquitectura de la solución está dividida claramente en cuatro componentes. El

primer componente son las fuentes de datos, que debido a que cada empresa del
sector salud maneja sus procesos diarios de formas diferentes, se hizo uso de un
área intermedia encargada estandarizar los datos provenientes de las diferentes
fuentes de datos. Esta base de datos intermedia es una base de datos relacional

69
que sigue un modelo de ventas dentro de las empresas del sector salud, basándose
en un modelo de ventas genérico. Esta base de datos está construida con una base
de datos Oracle.

Luego se diseñó y desarrolló un almacén de datos que soporta los datos

provenientes de la base de datos intermedia pero estructurado desde el punto de
vista del negocio, a través de la construcción de un modelo dimensional genérico
que permitió obtener los indicadores de gestión relevantes del área de ventas
utilizando la metodología seleccionada.

En la solución se tienen dos procesos ETC: el primero es el encargado de extraer,

transformar y cargar los datos fuentes a la base de datos intermedia. Este proceso
ETC es particular para cada empresa del sector salud. El segundo es el encargado
de la extracción, transformación y carga de los datos de la base de datos intermedia
al almacén de datos. Con los datos cargados en el almacén de datos, estos están
disponibles para el análisis mediante el uso de las herramientas de explotación y
publicación.

Posteriormente se construyeron las consultas y cuadros de mando que permiten

visualizar los indicadores de gestión del área de ventas para las empresas del
sector salud.

4.4.- Selección de productos e instalación.

Luego de pasar la fase de estudio de diversas herramientas para el desarrollo e
implementación de una solución de inteligencia de negocio (ver anexo 2) se optó por
la utilización de la herramienta Oracle Business Intelligence Standard Edition One,
ya que cumple con los componentes mínimos y necesarios para el desarrollo de la
solución BI propuesta, los cuales son: visión unificada de los datos, creación
personalizada de informes y consultas analíticas, cuadros de mando para la
presentación de los indicadores y herramienta para la construcción de almacenes de
datos.

70
4.5.- Diseño del Modelo Dimensional
El análisis de los requisitos analíticos de los usuarios para este tipo de solución,
requiere un enfoque diferente al usado en los sistemas operacionales, por lo tanto
para el diseño del modelo dimensional, se desarrolló siguiendo los siguientes pasos
propuestos por Kimball:

4.5.1.- Definir el nivel de granularidad: El proceso realizado en esta fase consistió

en la identificación de lo que se deseaba medir con cada indicador propuesto, como
se muestra en la Figura 24.

Figura 24. Ejemplo de proceso de identificación de granularidad

Luego, bajo la premisa de seleccionar la granularidad más baja para obtener la

información más detallada posible y tomando como ejemplo la figura anterior, se
concluyó que existían dos niveles de granularidad dado que se requiere conocer el
detalle de los productos vendidos por factura y adicionalmente se requiere conocer
el monto total de la factura para ser comparado con los montos de los presupuestos.

4.5.2.- Determinar las dimensiones: para determinar las dimensiones se planteó la

pregunta ¿cómo se describen los datos en los indicadores propuestos?, y para dar

71
 respuesta a esta interrogante se tomó cada indicador y se señaló bajo que
perspectiva se deseaba ver el hecho a medir. Se puede observar un ejemplo del
proceso realizado en la Figura 25.

Figura 25. Ejemplo de identificación de dimensiones

Posteriormente, se listaron y agruparon las dimensiones como se puede observar

en la siguiente Tabla 5

Dimensión 1 Dimensión 2 Dimensión 3 Dimensión 4 Dimensión 5

1- Productos 1.- Tipo Cliente 1.- Unidad de 1.- Diagnostico 1.- Día
2- Clasificación 2.- Cliente atención 2.- Mes
productos 3.- Año
3- Tipo producto 4.- Fecha

Tabla 5. Dimensiones identificadas

Así mismo, se identificó que existían relaciones jerárquicas entre ciertos atributos de
las dimensiones, las cuales fueron representadas como se muestra en la siguiente
Figura 26. Relaciones jerárquicas identificadas

72
 Figura 26. Relaciones jerárquicas identificadas

Finalmente se les asignó un nombre a cada dimensión, los cuales fueron localidad,
diagnóstico, tiempo ventas, tiempo presupuesto, producto y cliente. Cabe destacar,
que se crearon dos dimensiones referentes a las fechas ya que dependiendo del
nivel de granularidad, el tiempo puede ser visto como la fecha de elaboración de la
factura o como la fecha en que se realizó un presupuesto.

En el caso de la localidad se refiere a las diversas áreas de facturación, la cual

posee dos campos uno referente a su identificador y una breve descripción del sitio.
En el caso de la dimensión diagnóstico esta identifica a los diagnósticos de egreso
de los pacientes, obteniendo como atributos el tipo de historia que indica la
clasificación del diagnóstico con código y descripción, así como el diagnóstico con
un código y una breve descripción del mismo.

La dimensión producto se refiere a cada uno de los conceptos facturables, la cual

poseerá las categorizaciones por tipo producto y clasificación producto, el tipo
producto determinara si se trata de gastos hoteleros, materiales y medicamentos,
estudios y honorarios médicos, y la clasificación se determinara por la
categorización del producto dependiendo de su tipo. Un ejemplo de un producto con
su clasificación y tipo es: el estudio “Proyecciones de tórax” pertenece a la
clasificación de “rayos X” que a su vez pertenece al tipo producto “Estudios”.

73
Y por último, los clientes quienes son los responsables de los pagos de las facturas,
y que puede ser categorizado por tipo cliente (Autopagante o Seguro) y finalmente
su descripción. Ejemplo: Seguros Mercantil pertenece al tipo cliente Seguro y Pedro
Pérez pertenece al tipo cliente Autopagante.

Con los hechos y las dimensiones definidas, se puede observar en las Figura 27 y
28 una representación gráfica de los hechos con sus dimensiones y sus atributos.

Figura 27. Representación gráfica del hecho ventas con sus dimensiones

74
 Figura 28. Representación gráfica del hecho Presupuesto con sus
dimensiones y atributos

4.5.3.- Determinar el hecho: Teniendo definidas las dimensiones con sus atributos,
jerarquías y conociendo la existencia de dos niveles de granularidad, el paso
siguiente es la definición de las tablas hechos, donde se determinó que para el nivel
de granularidad correspondiente al detalle de los productos vendidos, los siguientes
elementos medibles: Monto, Cantidad y Costo, denominado hecho “Ventas” como
se muestra en la siguiente Figura 29. Además, se definieron los siguientes atributos
en el hecho:
Nro_caso, que se refiere al número de caso de una factura,
Nro_factura que es el identificador de cada factura,
Paciente, el nombre del paciente de un caso
Diagnóstico de ingreso y de egreso, que son los diagnósticos que se
les dio al paciente

75
 Tabla Hecho Atributos

Ventas id_Producto(PK),
id_Cliente(PK),
id_localidad(PK),
id_Tiempo(PK),
nro_caso,
nro_factura,
paciente,
diagnostico_ing
diangostico_eg,
Precio,
Costo,Cantidad

Figura 29. Hecho Ventas

Para nivel de granularidad referente al monto total de las facturas, cantidad y monto
de presupuestos, se denominó “Presupuesto vs Facturado”, y se identificaron los
siguientes elementos medibles, como se muestra en la Figura 30.

Tabla Hecho Atributos

Presupuesto id_Diagnóstico(PK),
Vs Facturado id_Cliente(PK),
id_localidad(PK),
id_Tiempo(PK),
nro_Factura,
paquete,
rompio_paquete,
Precio_Presupuesto,
Precio_Factura
Cantidad_Presupuesto
Figura 30. Hecho Presupuesto

Además como se puede observar en la figura anterior existen una serie de atributos
que significan lo siguiente:
Nro_factura: factura que se le realizó un presupuesto
Paquete: se refiere a que si el prespuesto que se le realizó tiene un previo
acuerdo con la compañía de seguro sobre el monto a pagar por la factura.
Rompio_paquete: se refiere a que si durante el proceso de facturación se
rompió el acuerdo con la compañía de seguro por haber excedido el monto
de la facturación con respecto al del presupuesto.

Dada la existencia de dimensiones en común entre ambos hechos, se obtuvo un

modelo de constelación para la representación del modelo dimensional que dará

76
soporte a la solución de inteligencia de negocio propuesta. El modelo dimensional
se muestra en la siguiente Figura 31.

Figura 31. Representación del modelo dimensional

Finalmente, se muestra el modelo dimensional con todas sus dimensiones y

atributos en la Figura 32

77
Figura 32. Modelo Dimensional extendido

78
4.5.4.- Modelo Entidad Relación – Base de Datos intermedia: Debido a que
cada empresa del sector salud maneja sus procesos diarios de formas diferentes, se
hizo uso de un área intermedia encargada de centralizar los datos referentes al área
de ventas, para así estandarizar los datos provenientes de las distintas fuentes de
datos y que serán almacenados posteriormente en el almacén de datos.

Tomando en cuenta que se trata de la representación del modelo de ventas se

estudiaron cuales podrían ser las posibles entidades que conformen el modelo
relacional del área intermedia, arrojando como resultado las entidades
unidad_atencion, cliente, tipo_cliente, diagnostico, tipo_historia, factura,
detalle_factura, clasificación_producto, tipo_producto y producto.

Una vez definidas las entidades que conforman el modelo propuesto, se

identificaron los atributos que debían poseer cada una ellas, como se ilustra en la
siguiente Tabla 6

Tabla Atributos

Tipo_cliente Cod_tipocliente
Descripcion

Cliente Cod_cliente
Descripcion
Cod_tipocliente
Unidad_atencion Cod_unidad
Descripcion
Factura Nro_factura
Nro_caso
Cod_unidad
Monto
Fecha_emision
Ci_rif_responsable
Estado
Cod_cliente
Nombre_paciente
Sexo_paciente
Diagnostico_ingreso
Diagnostico_egreso
Cod_presupuesto
Cod_diagnostico_presupuesto
Precio_presupuesto

79
 Paquete
Rompio_paquete
Fecha_presupuesto
Cantidad_presupuesto
Detalle_factura Nro_factura
Cod_producto
Cod_detalle
Cod_unidad
Cantidad
Precio
Costo
Producto Cod_producto
Descripción
Cod_clasif
Clasificacion_producto Cod_clasif
Descripción
Cod_tipoproducto
Tipo_producto Cod_tipoproducto
descripcion
Diagnostico Cod_diagnostico
Descripción
Cod_tipo_historia
Tipo_historia Cod_tipo_historia
Descripción

Tabla 6. Atributos de las entidades.

Finalmente, la representación del modelo entidad de relación propuesta para la base

de datos intermedia se puede observar en la siguiente Figura 33.

80
 Figura 33. Modelo entidad relación de la base de datos intermedia

4.6.- Diseño Físico.

El diseño físico de la solución se divide en dos partes, en el diseño de la base de
datos intermedia y en el diseño de las estructuras del almacén de datos.

La base de datos intermedia se desarrolló en una base de datos Oracle 10g

utilizando SQL Developer para construir las estructuras y relaciones modelo entidad
relación antes expuesto. En la Figura 34 se observa cómo están implementadas
estas tablas.

Figura 34. Estructuras de la base de datos intermedia implementadas

81
Una vez creada la base de datos intermedia, el siguiente paso fue la creación de las
estructuras del almacén de datos: dimensiones y cubos. Para la creación de estas
estructuras se utilizó la herramienta Oracle Warehouse Builder 10g (OWB), la cual
provee un asistente para la creación de las mismas como se puede ver en la Figura
35

Figura 35. Asistente de creación de dimensiones

Como anteriormente se definió, que cada dimensión posee atributos y niveles

jerárquicos específicos, se asignó un nombre a la dimensión para luego identificar
los atributos como se muestra en la Figura 36

82
 Figura 36. Asignación de atributos con el asistente

Luego de la asignación de los atributos, se estableció la jerarquía de las

dimensiones que lo ameritaban como se muestra en la Figura 37.

Figura 37. Definición de jerarquías con el asistente

83
Seguido a esto, cada nivel jerárquico de la dimensión tiene una estructura
compuesta por los atributos antes definidos para la dimensión como se muestra en
la Figura 38. En cada nivel jerárquico se puede elegir que atributos tendrá cada nivel
jerárquico de la dimensión.

Figura 38. Definiendo los atributos por jerarquías

Una vez creada todas las dimensiones utilizando la herramienta OWB a través de
los pasos antes descritos, se pasó a construir los cubos. Para ello la herramienta
cuenta también con un asistente para la creación de cubos el cual se puede
observar en la Figura 39.

84
 Figura 39. Asistente de creación de cubos

Luego de seleccionar el nombre que identifica al cubo, se pasó a indicar las

dimensiones con las que estaría relacionado como se puede ver en la Figura 40.

85
 Figura 40. Definiendo las dimensiones para el cubo

Luego de seleccionar las dimensiones, se indicó que medidas tendría cada cubo,
para ello el asistente cuenta con una interfaz como se observa en la Figura 41,
donde se escribió el nombre de la medida y su tipo de datos.

86
 Figura 41. Definiendo las medidas y atributos del cubo

Es importante mencionar que, nro_factura, nro_caso, desc_paciente,

diagnostico_ingreso, diagnostico_egreso y sexo, son dimensiones degeneradas3.

Una vez realizado este proceso para cada uno de los cubos, el modelo dimensional
estuvo completo, con sus seis dimensiones y dos cubos formando una constelación.

Es importante mencionar que tanto el asistente para la creación de dimensiones

como el de creación de cubos, define tablas que corresponden a cada dimensión y
cubos, las cuales serán pobladas por los procesos ETC.

3
El término Dimensión Degenerada, hace referencia a un campo que será utilizado como
criterio de análisis y que es almacenado en la tabla de hechos.

87
4.7.- Diseño y construcción de procesos ETC
Dada la existencia de una base de datos intermedia por las necesidades y
beneficios antes descritos, fue necesario un proceso de ETC para extraer y cargar
los datos de las fuentes a la base de datos intermedia. También fue necesario otro
proceso de ETC para obtener y cargar los datos de la base de datos intermedia al
almacén de datos. Estos procesos de ETC se explican a continuación.

4.7.1.- Proceso ETC de la fuente a la base de datos Intermedia

Es importante mencionar, que este proceso ETC es particular para cada institución
o empresa que ofrece servicios de salud. Para efectos del Trabajo Especial de
Grado se contó con los datos de una clínica reconocida quien suministró los datos
referentes a las ventas de sus productos y servicios.

Para ayudar a ilustrar este proceso ETC se puede observar en la Figura 42. La
empresa del sector salud cuenta con una base de datos en SQL Server 2005 la cual
almacena sus procesos diarios, entre los cuales están los procesos de ventas.

Figura 42. Diagrama del proceso ETC de la base de datos intermedia

88
Para extraer los datos de la fuente hacia la base de datos intermedia, se creó un
procedimiento almacenado que se conectó a través de un servicio heterogéneo con
la fuente de datos para extraer y transformar los datos y así poder adaptarlos a la
estructura de la base de datos intermedia para luego cargarlos en ella.

4.7.2.- Proceso ETC de la base de datos intermedia al almacén de datos

El proceso de ETC para el almacén de datos está compuesto por ocho procesos
ETC en realidad, uno por cada dimensión definida y otros dos para los hechos.
Estos procesos se realizaron con la ayuda de la herramienta Oracle Warehouse
Builder la cual presenta una interfaz gráfica para ayudar a realizar los procesos de
ETC. En la Figura 43 se muestra un ejemplo de la interfaz de la aplicación

Figura 43. Centro de diseño OWB 10g

Como se puede observar en la Figura 43 existe un área de trabajo llamado

“Explorador de Proyectos”. Seleccionado de color azul, se observa la carpeta
llamada “Correspondencias”, es ahí donde se almacenan los procesos ETC que se
crearon. La descripción del proceso de creación se describirá a continuación.

Para el proceso de ETC de la dimensión Cliente, se usaron las tablas cliente y

tipo_cliente de la base de datos intermedia, haciendo uso de un operador que

89
provee la herramienta OWB llamado “Joiner”, para luego hacer corresponder los
atributos de dicha intersección con la dimensión Cliente. En la siguiente Figura 44
se muestra el resultado de este proceso.

Figura 44. ETC de la dimensión Cliente

La dimensión producto se creó juntando las tablas clasificación_producto, producto

y tipo_producto utilizando nuevamente el operador “Joiner”, luego se realizaron las
correspondencias de los atributos con la dimensión arrojando como resultado el
siguiente ETC que se observa en la Figura 45.

Figura 45. ETC de la dimensión Producto

90
Para dimensión localidad sólo hizo falta realizar las correspondencias directas de los
atributos de la tabla Unidad_Atencion con los atributos de la dimensión Localidad,
esto gracias a como está diseñada la base de datos intermedia. En la Figura 46 se
puede ver esta correspondencia

Figura 46. ETC de la dimensión Localidad

La dimensión diagnóstico se creó juntando las tablas Diagnóstico y Tipo_Historia

utilizando nuevamente el operador “joiner” para luego hacer corresponder los
atributos con la dimensión Diagnóstico, este proceso se puede observar en la Figura
47.

Figura 47. ETC de la dimensión Diagnostico

Para las dimensiones de Tiempo y Tiempo Presupuesto, se utilizó la herramienta

para la creación de dimensiones tiempo de OWB, con ella se le especifica la forma

91
de representar el tiempo, si en forma de calendario o en forma fiscal. También se
especifica el año de inicio y la cantidad de años que se desea generar. Para el caso
de estudio, se decidió crear la dimensión tiempo y tiempo presupuesto como
calendario, así la herramienta creó las dimensiones con la jerarquía año, trimestre,
mes y día, además de sus atributos.

Con los datos cargados correctamente en las dimensiones, se pasó a la

construcción de los procesos de ETC para los cubos. Para el cubo de ventas se
utilizó las tablas factura y detalle_factura de la base de datos intermedia, y haciendo
uso del operador “joiner” donde el nro_factura de la tabla factura debe ser igual al
nro_factura de la tabla detalle_factura, se intersectaron las tablas para luego hacer
corresponder los campos con el cubo de ventas obteniendo el siguiente proceso de
ETC como se muestra en la Figura 48.

Figura 48. ETC para el cubo de Ventas

Para la construcción del ETC del cubo de presupuesto, se uso la tabla factura de la
base de datos intermedia, en esta tabla se encuentran todas las facturas con o sin
presupuestos y se coloco un filtro para condicionar la búsqueda, para así identificar
sólo las facturas que poseían presupuesto, además se utilizó dos operadores
“Expression” para transformar las fechas que están almacenadas en la tabla factura

92
y así estuvieran en el formato que el cubo maneja. En la Figura 49 se muestra el
ETC del cubo de presupuesto.

Figura 49. ETC para el cubo de Presupuesto

Con los procesos ETC de las dimensiones y de los cubos construidos, se pasó al
despliegue de los mismos para poblar las tablas, utilizando el centro de control de
Oracle Warehouse Builder.

El despliegue de cada una de las dimensiones se realizó en tres fases, primero se

crearon y desplegaron las secuencias de cada dimensión, luego la creación y
despliegue de las tablas correspondientes, y finalmente el despliegue y carga de las
correspondencias antes descritas. Una vez culminado este proceso las tablas de las
dimensiones están pobladas con sus datos correspondientes.

Para los cubos se realizó un proceso similar, se crearon y se desplegaron las tablas
para luego desplegar e iniciar las correspondientes que poblaron ambos cubos.

4.8.- Especificación y desarrollo de aplicaciones analíticas

Conociendo que por medio de los tableros de mando, los usuarios interactuarán con
los reportes elaborados en base a los indicadores antes mencionados, se
establecieron una serie de lineamientos y estándares de diseño, de forma que la
interfaz gráfica sea agradable y fácil de entender.

93
Los tableros de mando están compuestos por un conjunto de páginas, donde se
representan los indicadores, en cada una de ellas se pueden representar uno o más
indicadores con diferentes formatos.

Para lograr homogeneidad en la representación de los indicadores se establecieron

los siguientes estándares:
Diseño simple de las páginas: Mantener las páginas del tablero de mando sin
sobrecarga de información agrupando los indicadores de medidas similares
como por ejemplo los Top 10. El diseño de las páginas tienen una
combinación de colores suaves de bajo contraste para que reflejen seriedad
e inspiren confianza.
Refinamiento de consultas: En cada página del tablero de mando se
colocaron filtros donde el usuario puede seleccionar un elemento que
establece y actualiza las vistas de los indicadores.
Vistas de los indicadores: la representación de los indicadores esta dadas
por vistas de tablas con los datos combinados con elementos gráficos como
gráficos de barra, gráficos torta, gráficos lineales, entre otros.
Acceso de usuarios: los usuarios tienen que pasar por un proceso de
autenticación, donde deben colocar su nombre y una clave secreta asignada.
Además los usuarios son categorizados dependiendo de las tareas que
pueda realizar dentro de la aplicación.

4.9.- Integración y despliegue

Para la integración y despliegue de la solución de inteligencia de negocio, se utilizó
Oracle BI Server Administration Tool. Como se muestra en la Figura 50, la
herramienta está compuesta por una vista gráfica de las tres capas del repositorio:
a) una capa física, b) Modelo de Negocio y capa de mapeo, y c) la capa de
presentación.

94
 Figura 50. Oracle BI Administration Tool

Dentro de la capa física se especificaron las fuentes de datos físicas y las

relaciones entre ellas, con las que Oracle BI Server trabaja para la elaboración de
consultas. Se seleccionó la base de datos fuente a través del ODBC de BISE1DB
especificando el esquema a usar, el cual fue VENTAS_DW.

Al importar metadatos, muchas de las propiedades de las fuentes se configuran

automáticamente como lo son las relaciones de claves primarias y foráneas. Figura
51, se muestra la capa física con más detalle.

95
 Figura 51. Capa Física

Dentro de la capa del Modelo de Negocio y mapeo, el objetivo de esta capa fue
captar cómo piensan los usuarios acerca del negocio utilizando su propio
vocabulario, para esto se definió el modelo de negocio especificando las
dimensiones, jerarquías y atributos de cada uno de los componentes y se
renombraron alguno de los atributos, además de eliminar los que no eran
significativos para los usuarios finales. En la Figura 52, se muestra la capa del
Modelo de Negocio y mapeo.

96
 Figura 52. Capa del Modelo de Negocio y mapeo

En la capa de Presentación, se encuentran los datos que ven los usuarios con la
aplicación analítica, el Oracle BI Answer. En esta capa se pueden reorganizar los
datos como renombrarlos para hacerlos más entendibles para el usuario final. En
este caso se dejaron los datos como los ubicados en la capa anterior, como se
muestra en la Figura 53.

97
 Figura 53. Capa de presentación

Durante la elaboración de las tres capas con el Oracle BI Administration Tool, los
datos esta deshabilitados para realización de consultas a través de las herramientas
analíticas, es por esto que al final de la definición de las tres capas se realizó un
proceso de habilitación de los datos.

4.10.- Cuadros Analíticos

En esta fase para la elaboración de los cuadros de analíticos se requirió la definición
de los indicadores en la herramienta Oracle Business Intelligence Answers, para
luego ser mostrados en los cuadros de mando, a través de la herramienta Oracle

98
Business Intelligence Interactive Dashboards. En las figuras siguientes, podemos
observar algunos ejemplos de nuestros indicadores representados en el cuadro de
mando.

En la Figura 54, se muestra un ejemplo del cuadro de mando que contiene todos los
indicadores resaltantes de la solución de negocio propuesta y es usado como
cuadro resumen.

Figura 54. Resumen de indicadores

El siguiente cuadro de mando Figura 55, se muestran las ventas por unidad de
atención en un periodo de tiempo , donde se evidencio que la unidad de atención
que posee más ventas a su cargo es la unidad de Quirófano.

99
Figura 55. Indicador referente al análisis de las ventas por unidad de atención

En la siguiente Figura 56, se muestra un análisis detallado de las ventas por unidad
de atención y tipo de producto facturado por cada diagnostico registrado en un
periodo de tiempo.

Figura 56. Indicador referente al análisis detallado de las ventas por unidad de
atención

100
La figura 57 muestra las ventas por tipo de cliente, evidenciando que los
responsables Seguro son los que más generan ventas a la empresa de salud.

Figura 57. Indicador referente a las ventas por tipo de cliente.

Siguiendo con el análisis de las ventas por tipo cliente, la figura 58 muestra el
detalle de los tipos de cliente Seguro

Figura 58. Indicador referente a las ventas por tipo cliente Seguro

101
Así mismo se realizó el siguiente cuadro de mando para el análisis por tipo Cliente
Autopagante, como se muestra en la figura 59.

Figura 59. Indicador referente a las ventas por tipo de cliente Autopagante.

El siguiente cuando de mando figura 60, se muestran las ventas por tipo producto
en un periodo de tiempo.

Figura 60. Indicador referente a las ventas por concepto facturable

102
En la figura 61 se muestra la desviación porcentual de las ventas realizadas por
mes, donde el mayor registro de ventas se realizo en el mes de marzo.

Figura 61. Indicador referente a la desviación porcentual de las ventas por mes

Se realizó un cuadro de mando especial para la comparación entre los conceptos

facturables que generan más ventas en la empresa de salud, describiendo solo los
10 primeros para cada tipo de concepto y su monto vendido en un periodo de
tiempo.

Figura 62. Indicador referente a los Top 10 por concepto facturable

103
Así mismo se realizó el siguiente cuadro de mando Figura 63, para determinar los
10 primeros clientes, autopagante y seguro con los mayores montos generados por
la venta en un periodo de tiempo.

Figura 63. Indicador referente al Top 10 por tipo Cliente

Para ilustrar otro indicador de comparación, se elaboro el cuadro de mando como se

muestra en la figura 64, para detallar las ventas facturadas versus los presupuestos,
así como el detalle de los mismos por diagnostico en un periodo de tiempo.

104
Figura 64. Indicador referente a la diferencia entre Facturado y Presupuestado
La figura 65 muestra el cuadro de mando realizado para ilustrar el detalle de
cantidad de presupuestos realizados por unidad de atención en un periodo de
tiempo, con el cual se determino que la mayor cantidad de presupuestos se realiza
en el mes de enero.

105
 Figura 65. Indicador referente a la cantidad de Presupuestos por Unidad de
Atención

Y por último, se muestra la figura 66 se detalla el monto versus el costo facturado de

los productos, indicando si se están generando pérdidas o ganancias en las ventas
de los mismos.

Figura 66. Indicador referente al monto facturado Vs su costo

106
4.11.- Mantenimiento y crecimiento
Una vez terminado el desarrollo completo, se tomaron en cuenta los siguientes
puntos:
- Soporte: Los procesos de ETC se deben programar según las necesidades
de cada institución de salud, en este sentido, se recomienda que se escoja
un momento en que las fuentes de datos no estén siendo muy utilizadas
para no entorpecer los procesos diarios de las empresas del sector salud.
Además, la periodicidad de la ejecución de estos procesos depende de las
necesidades de cada institución de salud.

- Capacitación de los usuarios: se realizó una reunión con los usuarios de la

herramienta para capacitarlos en el uso de la misma, y orientarlos en la
construcción de nuevos indicadores.

107
 CONCLUSIONES

El objetivo principal de este Trabajo Especial de Grado fue alcanzado exitosamente

al lograr diseñar y desarrollar una solución de inteligencia de negocio orientada a la
gestión de ventas de empresas del sector salud con el fin de apoyar la toma de
decisiones precisas y a tiempo. En este sentido, se logró sustentar la toma de
decisiones gracias a los indicadores y reportes que arrojan hechos reales de los
procesos de ventas registrados, permitiendo a los usuarios consultar en detalle y
generar conocimiento sobre el negocio.

Se logró definir una lista de indicadores de gestión genéricos para el área de ventas
de las empresas de salud. Así mismo, se diseñó e implementó un modelo relacional
del área de ventas correspondiente a las empresas del sector salud, el cual permite,
sin importar la fuente de datos que manejen las empresas del sector salud, modelar
los procesos de ventas, convirtiendo la solución propuesta en una solución de
inteligencia de negocio genérica y no particular para una empresa del sector salud.

También se diseñó con éxito un modelo dimensional gracias al uso de la

metodología de Kimball, la cual nos sirvió de guía para la elaboración de cada uno
de los componentes que conforman a la solución a través de una serie de pasos
sencillos y fáciles de entender. Este modelo dimensional soporta los indicadores
propuestos colaborando en el apoyo a las tomas de decisiones a tiempo.

Se desarrollaron e implementaron los procesos encargados de extraer, transformar

y cargar los datos desde las posibles fuentes de datos, hacia el modelo relacional,
así como también los procesos de extracción, transformación y carga para poblar el
almacén de datos.

Una vez construido y poblado el almacén de datos, se logró diseñar e implementar

las consultas analíticas y reportes que dan respuesta a los indicadores de gestión
que fueron definidos para esta solución de inteligencia de negocio, a través de una
interfaz amigable y de fácil manejo.

108
Se realizaron pruebas para validar los valores que estas consultas arrojaron a través
de un caso de estudio, dichas pruebas arrojaron resultados positivos validando así
la solución de inteligencia de negocio.

109
 RECOMENDACIONES

A pesar de que gracias a esta solución de inteligencia de negocio, se cuenta con

una opción de poder conocer más a fondo los procesos de venta en las empresas
del sector salud, se recomienda que para trabajos futuros en este tipo de soluciones
o para la mejora de esta misma lo siguiente:

Implementar la solución para dispositivos móviles, así los usuarios de la

solución podrán acceder a la información desde cualquier parte y podrán
tomar decisiones soportadas por los resultados obtenidos de los indicadores,
además de poder supervisar en todo momento el funcionamiento de sus
procesos.
Integrar otras áreas temáticas de las empresas de salud como: cadena de
suministro, cobranza, recursos humanos, contabilidad, entre otros.
Estudiar que otros indicadores de gestión se puedan agregar a la lista
propuesta para brindarle más información a los usuarios de la solución y así
estos puedan tomar mejores decisiones.
Adiestrar a los usuarios para que aprendan a construir ellos mismos las
consultas analíticas y así agilizar el proceso de los nuevos requerimientos en
cuanto a indicadores de gestión.

110
 REFERENCIAS BIBLIOGRÁFICAS

Armando, F. (2003). De los datos a las decisiones rentables. Recuperado el

21 de abril de 2010, de Profinmexico:
http://www.profinmexico.com/boletines/JUN03.htm

C, L. K., & P, L. J. (2008). Sistemas de Información Generacial,

Administración de la empresa digital. Pearson Educación.

Collins; Jackie. (2001). Performance.Success. Data Warehousing

Fundamentals. Vol 1 y 2 Student Guide. Oracle Educations.

de Pablos, C., López Hermoso, J. J., Martín Romo, S., & Medina, S. (2004).
Informática y comunicaciones en la empresa. Madrid: ESIC Editorial.

Grupo Iberoamerica tecnología y conocimiento. (2010). Business Intelligence.

Grupo Iberoamerica.

IBM. (2010). Cognos Business Intelligence and Financial. Recuperado el 14

de enero de 2010, de IBM software: http://www-
01.ibm.com/software/data/cognos/

Inmon, W. H. (1999). Building the Operational Data Store. Wiley.

Jesús, B. d. (2003). Metodología del análisis estructurado de sistemas.

Madrid: Universidad Pontificia Comillas .

Juliet, J. (16 de marzo de 2010). BenefitOf.net. Recuperado el 10 de agosto

de 2010, de Benefit of Business Intelligence: http://benefitof.net/benefits-of-
business-intelligence/

Kendall, K. E., & Kendall, J. E. (2005). Análisis y diseño de sistemas.

Monterrey: Pearson Education.

Kimball, R., & Ross, M. (2002). The Data Warehouse Toolkit. Wiley.

Lambertini, C., & Cortés, C. (2009). Oracle Latinoamerica. Recuperado el 18

de noviembre de 2010, de

111
http://www.oracle.com/global/lad/corporate/press/2006_mar/presentacion_nu
eva_bi-suite.html

Microsoft. (2002). Microsoft Data Warehouse Training Kit. Microsoft.

MicroStrategy. (2010). MicroStrategy. Recuperado el 16 de Enero de 2010,
de MicroStrategy: http://www.microstrategy.com/

Moliner López, F. J. (2005). Grupos A y B de la informática. Bloque

específico. Valencia, España: MAD.

Moss, L. T., & Atre, S. (2003). Business intellingence roadmap. The Complete
Project Lifecyvle for Decision-Support Applications. Boston: Addison - Wesley
Information Technology Series.

Oracle. (2010). Oracle Business Intelligence. Recuperado el 28 de agosto de

2010, de Oracle: http://www.oracle.com

Oracle. (2007). Oracle Business Intelligence Standard Edition One. Informe

Ejectuvo de Oracle. Oracle.

Pentaho. (2011). Pentaho Open source business intelligence. Recuperado el

17 de febrero de 2011, de pentaho: http://www.pentaho.com/

Pérez, E. (1999). Data Warehouse. Recuperado el 5 de octubre de 2010, de

Programatium.com: http://www.programatium.com/manuales/Data-
Warehouse/diagrama-estrella.htm

Planeaux & Alvin. (2007). Oracle Business Intelligence Standard Edition One.
Oracle.

Ponniah, P. (2001). Data Warehousing Fundamentals. A Comprehensive

Guide for IT Professionals. Nueva York: John Wiley & Sons, Inc.

Roy, D. (2005 de agosto de 2005). Understanding Business Intelligence.

Recuperado el 10 de agosto de 2010, de CIO Update:
http://www.cioupdate.com/reports/article.php/3531436/Understanding-
Business-Intelligence.htm

Royo, J. A. (2003). Data Warehouse and data Mining. Zaragoza, España.

Salgueiro Anabitarte, A. (2001). Indicadores de Gestión y cuadro de mando.

Madrid: Díaz de Santos,S.A.

SCN Education B.V. (Eds). (2001). Data Warehousing. The Ultimate Guide to
Building Corporate Business Intelligence. Lengerich: Vieweg.

112
Todman, C. (2001). Designing a Data warehousing. Hewlett-Packard
Professional Books.
Tsai, J. (2007). Oracle Business Intelligence Standard Edition One Tutorial
Release 10g (10.1.3.2.1). Oracle.

Uzcanga, R. (2008). Sistema de apoyo a la toma de decisiones a partir de

documentos distribuidos en el Web: aplicación a la prensa electrónica.
Mexico: Universidad de las Américas Puebla.

Whitten, J., Bentley, L., & Barlow, V. (1997). Análisis y diseño de Sistemas de
Información. Madrid: McGraw-Hill.

Wrembler, R., & Koncilia, C. (2007). Data Warehouses and OLAP. Concepts,
architectures and solutions. IGI Global.

113
 ANEXOS
Anexo 1. Creación del Servicio Heterogéneo
1. Lo primero es definir el DNS de SQL Server. En el panel de control, icono de
ODBC.
2. En la pestaña de DNS de Sistema oprimir el botón Agregar.
3. Escoger el controlador para SQL Server.
4. Colocarle el nombre, en nuestro caso fue ORACLE_SQL y escoger como
servidor “local”. Continuar con el asistente para la creación del ODBC hasta
el final hasta que confirme la creación del mismo.
5. Se modifica el archivo init asignando los valores OFF a los parámetros
referentes a la conexión y traza.
6. Luego se modifica el listener.ora con los parámetros que identifican al objeto
odbc
7. Se modifica el tnsname, colocando la referencia de la conexión por odbc:
8. Luego crear el DB Link desde oracle de la siguiente manera:
create database link ORACLE_SQL
connect to sa identified by using 'ORACLE_SQL ';
9. Por último probar la conexion hacienda una consulta sencilla como:
Select * from factura@oracle_sql;

114
Anexo 2. Tabla comparativa de herramientas para la construcción de
soluciones de inteligencia de negocio

Cognos 8 Business Oracle Business Intelligence

Pentaho MicroStrategy V9
Intelligence Standard Edition One
Integración de datos Soportada Data Integrator MicroStrategy Architec Oracle warehouse Builder
OracleBI Office Plug-In. Hace
Compatibilidad con
Microsoft Office OpenOffice MicroStrategy Office Essentials posible el soporte con Microsoft
herramientas Office
Sistemas operativos AIX, HP-UX, HP Itanium, Linux,
Windows, Linux, Mac OS Windows, Linux Windows, Linux
soportados Solaris, Windows
Administrador de usuarios Pentaho Administration
Soportada MicroStrategy Administrator Oracle BI Server
y de datos Console
Pentaho Report
Herramientas de reportes MicroStrategy Desktop.
Designer,Pentaho Report OracleBI Publisher. OracleBI
y consultas (Query & IBM Cognos 8 BI Reporting MicroStrategy Report Services.
Design Wizard, Web ad-hoc Answers
reports) MicroStrategy Web
reporting
MicroStrategy Report Services:
Cuadro de mando
BM Cognos 8 BI Dashboards Soportada Dynamic Enterprise OracleBI Interactive Dashboard
(dashboard) Dashboards
Soportada bajo una extensión,
Datamining IBM analysis
Weka Project No posee En la version Enterprise

Herramienta de
MicroStrategy Administrator.
construccion de Pentaho Data Integration
MicroStrategy Intelligence Oracle warehouse Builder
InfoSphere Warehouse
Datawarehouse / data Kettle
Server.
marts
Sistema de mensajes de Soportado en la versión
Cognos 8 Planning MicroStrategy Movil
Alerta Enterprise con Oracle BI Delivers

Microsoft Internet Information

Un servidor Web instalado e
iniciado. Alguna de las
Requisitos Software siguientes bases de datos
instaladas : Oracle, Sybases,
DB2, Microsoft SQL server
Services (IIS) version 5.1, 6.0,
7.0 or 7.5. Microsoft Internet
Microsoft Framework 2.0.
Explorer version 6.0.2, 6.0.3,
Java run Time Enviroment 5 o Windows Installer 3.0.Adobe
7.0 or 7.5. Adobe® Reader®
posteriores, MySQL version 5 o Acrobat Reader. Acrobat Flash
version 7.1, 8.1 or 9.1. Adobe®
posteriores Player. Pop-Up Blocker debe
Flash® Player version 9.0 or
estar deshabilitado
10. 16-bit color display.
Windows fonts display set to
small fonts (96 dpi)

Procesador de arquitectura Procesador de arquitectura Procesador de arquitectura

Pentium de 2.0 GHZ, 2 GB de
Requisitos Hardware memoria RAM, Disco Duro con
al menos 6,5 GB libres
Idiomas soportados Ingles, español
Pentium de 2.0 GHZ, 768 MB
de memoria RAM, Disco Duro
con al menos 2 GB libres
Ingles, español
Procesador de arquitectura
Pentium de 2.0 GHZ, 4 GB de
Pentium de 2.5 GHZ, 2 GB de
memoria RAM, Disco Duro (4,5
memoria RAM, Disco Duro 6GB
GB para windows, 15 GB para
libres
linux) libres
Ingles, español Ingles, español

115