FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS
ESCUELA PROFESIONAL DE INGENIERÍA EN
COMPUTACIÓN E INFORMÁTICA
TESIS
“INTELIGENCIA DE NEGOCIOS PARA MEJORAR EL
PROCESO DE TOMA DE DECISIONES EN EL ÁREA DE
RENTAS DE LA MUNICIPALIDAD DISTRITAL DE CIUDAD
ETEN – CHICLAYO, 2018”.
PARA OTORGAR EL TITULO DE
INGENIERO EN COMPUTACIÓN E INFORMÁTICA
AUTOR(ES):
BACH. DIAZ BECERRA, DIANA CATHERINE
BACH. TOCTO CARLOS, DENIS FRANCO.
ASESOR:
ING. DENNY JOHN FUENTES ADRIANZÉN
DECLARACIÓN JURADA DE ORIGINALIDAD
Yo Diana Catherine Diaz Becerra, Denis Franco Tocto Carlos Investigadores principales, y Ing. Denny John Fuentes Adrianzén, asesor del trabajo de investigación “Inteligencia de Negocios para mejorar el Proceso de Toma de Decisiones en el Área de Rentas de la Municipalidad Distrital de Ciudad Eten – Chiclayo, 2018” declaramos bajo juramento que este trabajo no ha sido plagiado, ni contiene datos falsos. En caso se demostrará lo contrario, asumo responsablemente la anulación de este informe y por ende el proceso administrativo a que hubiera lugar. Que puede conducir a la anulación del título o grado emitido como consecuencia de este informe.
Lambayeque, 5 de Junio del 2019
Investigadores:
Bach. Diaz Becerra, Diana Catherine. Bach. Tocto Carlos, Denis Franco. Asesor:
DEDICATORIA
A Dios, por habernos permitido llegar a esta etapa tan trascendental en nuestras vidas, y darnos la fortaleza y sabiduría para seguir adelante en los momentos de incertidumbre.
AGRADECIMIENTO
A todas aquellas personas que de una u otra manera nos ayudaron a crecer como personas y como profesionales, personas que nos dieron la mano en los momentos más difíciles para poder cumplir una de nuestras metas en el ámbito profesional.
RESUMEN
INTELIGENCIA DE NEGOCIOS PARA MEJORAR EL PROCESO DE TOMA DE DECISIONES EN EL ÁREA DE RENTAS DE LA MUNICIPALIDAD DISTRITAL DE
CIUDAD ETEN – CHICLAYO, 2018.
DIANA DIAZ BECERRA DENIS TOCTO CARLOS [email protected] [email protected] La presente tesis trata sobre el desarrollo de una solución de Inteligencia de Negocios, dicha herramienta nos permitirá mejorar el proceso de toma de decisiones en el área de Rentas de la Municipalidad Distrital de Ciudad Eten, haciendo uso de la metodología de Kimball.
El área de Rentas de la Municipalidad Distrital de Ciudad Eten diariamente maneja grandes cantidades de información, pero debido a que su sistema actual no soporta el adecuado manejo de grandes volúmenes de información, se establece que en dicha área tiene el inconveniente de usar toda esa información que sirva de apoyo a la toma de decisiones de la gerencia. El proceso de obtención de los reportes es muy tardío y genera esfuerzo innecesario en el personal encargado de la obtención de los reportes solicitados por la gerencia.
Por lo antes mencionado es que se plantea el desarrollo de una solución de Inteligencia de Negocios, que nos permitirá reducir los tiempos en el proceso de obtención de los reportes y a su vez disminuirá el esfuerzo desplegado en dicho proceso.
En conclusión, la solución final nos mostrará una serie de reportes que permitirán al usuario visualizar el estado actual e histórico de los Impuestos de dichos arbitrios, y en base a ellos el gerente podrá tomar decisiones acertadas y plantear nuevas estrategias.
ABSTRACT
INTELIGENCIA DE NEGOCIO TO IMPROVE THE DECISION MAKING PROCESS IN THE RENT AREA OF THE CITY DISTRICT MUNICIPALITY ETEN - CHICLAYO,
2018.
DIANA DIAZ BECERRA DENIS TOCTO CARLOS [email protected] [email protected] This thesis deals with the development of a Business Intelligence solution, this tool will allow us to improve the decision-making process in the Rents area of the District Municipality of Ciudad Eten, using the Kimball methodology.
The area Rents of the District Municipality of Ciudad Eten daily handles large amounts of information, but because the current system does not support the proper handling of large volumes of information, it is established that in that area has the drawback of using all such information will support the decision of management. The process of obtaining the reports is very late and generates unnecessary effort in the personnel in charge of obtaining the reports requested by management.
By the aforementioned is that the development of a Business Intelligence solution that will enable us to reduce the process of obtaining reports and in turn decrease the effort made in said process.
In conclusion, the final solution will show us a series of reports that will allow the user to visualize the current and historical tax status of said taxes, and based on them the manager will be able to make sound decisions and propose new strategies.
ÍNDICE
DECLARACIÓN JURADA DE ORIGINALIDAD ... iv
DEDICATORIA ... v
1.1.1. Realidad Problemática. ... 3
1.1.2. Definición del Problema ... 6
1.1.3. Enunciado del Problema ... 9
1.2. Tipo y Nivel de la Investigación ... 10
1.2.1. Tipo de Investigación ... 10
1.2.2. Nivel de Investigación ... 10
1.3. Justificación de la Investigación ... 10
1.4. Objetivos ... 11
1.4.1. Objetivo general. ... 11
1.4.2. Objetivos específicos ... 11
1.6. Antecedentes ... 12
1.6.1. Antecedentes en el contexto internacional. ... 12
1.6.2. Antecedentes en el contexto nacional. ... 13
1.6.3. Antecedentes en el contexto Regional. ... 15
1.6.4. Antecedentes en el contexto Local. ... 16
1.7. Bases Teóricas ... 18
1.7.1. Inteligencia de negocios. ... 18
1.7.2. Metodología de Kimball. ... 27
1.7.3. Metodología de Bill Inmon... 40
1.7.4. Toma de decisiones. ... 52
1.7.5. Microsoft Power BI ... 57
1.8. Definición y Operacionalización de Variables. ... 59
1.9. Actividades y Recursos ... 61
1.9.1. Cronograma. ... 61
1.9.2. Presupuesto. ... 62
CAPÌTULO II ... …65
II. MÉTODOS Y MATERIALES ... 66
2.1. Diseño de Contrastación de Hipótesis ... 66
2.2. Población y Muestra ... 67
2.2.1. Población ... 67
2.2.2. Muestra ... 67
2.3. Técnicas, Instrumentos, Equipos y Materiales ... 67
CAPÍTULO III ... 69
3.1. Análisis e interpretación de los resultados ... 70
3.2. Análisis para la elección de la metodología. ... 85
3.2.1. Comparación de metodologías ... 85
3.2.2. Selección de la metodología ... 86
3.3. Generalidades ... 86
3.4. Planificación del Proyecto ... 87
3.4.1. Descripción del Proyecto. ... 87
3.4.2. Objetivos del Proyecto. ... 87
3.3.3. Alcance del Proyecto. ... 87
3.3.4. Stakeholders ... 88
3.3. Definición de los Requerimientos del Negocio ... 90
3.3.1. Proceso de negocio: Toma de Decisiones del Área de Rentas ... 90
3.3.2. Procesos de Negocio y Temas Analíticos... 91
3.3.3. Matriz Procesos/Dimensiones ... 91
3.3.4. Requerimientos ... 92
3.3.5. Documentación de los Requerimientos ... 93
3.4. Modelo Dimensional ... 96
3.4.1. Dimensiones ... 96
3.4.2. Dimensión: Personal. ... 97
3.4.3. Dimensión: Material. ... 97
3.4.4. Dimensión: Ubigeo ... 98
3.4.5. Dimensión: Arbitrio ... 98
3.4.6. Dimensión: Costos ... 99
3.4.7. Dimensión: Tiempo ... 99
3.4.8. Granularidad. ... 100
3.4.9. Hechos ... 101
3.4.11. Diseño del Modelo Estrella. ... 103
3.5. Diseño de la Arquitectura Técnica ... 104
3.5.1. Arquitectura ... 104
3.6. Diseño Físico ... 104
3.6.1. Tabla Dimensión: DimUbigeo ... 106
3.6.2. Tabla Dimensión: DimPersonal ... 107
3.6.3. Tabla Dimensión: DimMaterial ... 108
3.6.4. Tabla Dimensión: DimArbitrio ... 108
3.6.5. Tabla Dimensión: DimCostos ... 109
3.6.6. Tabla Dimensión: DimTiempo ... 109
3.6.7. Tabla de Hechos: HechoRentas ... 110
3.6.8. Diseño Modelo Físico. ... 111
3.7. Diseño ETL ... 112
3.7.1. Extracción (Extract) ... 112
3.7.2. Transformación (Transformation). ... 115
3.7.3. Carga (Load). ... 143
3.8. Diseño del Cubo OLAP. ... 148
3.8. Implementación de Reportes ... 152
3.8.1. Lista de reportes. ... 152
3.9. Discusión ... 157
CAPÍTULO IV ... 159
IV. CONCLUSIONES ... 160
CAPÍTULO V ... 161
INDICE DE FIGURAS
Figura 01. Ubicación de la Municipalidad de Ciudad Eten. ... 5
Figura 02. Proceso de Toma de Decisiones en el Área de Rentas. ... 9
Figura 03. Componentes de Inteligencia de Negocio. ... 19
Figura 04. Elementos Básicos de Almacén de Datos. ... 20
Figura 05. Ejemplo de Cubo Olap. ... 22
Figura 06. Ejemplo de Cubo Olap. ... 23
Figura 07. Ejemplo del Cubo Olap. ... 24
Figura 08. Ejemplo del Cubo Olap. ... 24
Figura 09. Ejemplo del Cubo Olap. ... 25
Figura 10. Tareas de la Metodología de Kimball Denominada Business. ... 28
Figura 11. Diagrama de Flujo del Proceso Dimensional de Kimball. ... 32
Figura 12. Ejemplo de Modelo Final de Alto Nivel de la Sesión Inicial de Diseño. ... 34
Figura 13. Enfoque Inmon-Dw Corporativo. ... 41
Figura 14. Migración al Entorno Diseñado - Parte I. ... 43
Figura 15. Migración al Entorno Diseñado - Parte II. ... 47
Figura 16.Migración al Entorno Diseñado - Parte III. ... 51
Figura 17. Proceso para Resolver Problemas. ... 55
Figura 18. Tiempo de entrega de reportes Personal Responsable. ... 70
Figura 19. Tiempo de demora en generar reportes. ... 71
Figura 20. Satisfacción de Requerimientos. ... 72
Figura 22. Encuesta aspecto de servicios del Personal Responsable. ... 76
Figura 23. Costos por responsables ... 79
Figura 24. Montos de Arbitrios por Mes ... 81
Figura 25. Reporte Arbitrios ... 83
Figura 26. Proceso de Negocio: Toma de Decisiones ... 90
Figura 27. Determinación de nivel de granularidad... 101
Figura 28. Modelo Dimensional: Rentas. ... 103
Figura 29. Arquitectura Técnica ... 104
Figura 30. Data Warehouse Eten. ... 105
Figura 31. Modelo Físico Rentas. ... 111
Figura 32. Extracción: DimUbigeo. ... 112
Figura 33. Extracción: DimPersonal. ... 112
Figura 34. Extracción: DimMaterial. ... 113
Figura 35. Extracción: DimArbitrio. ... 113
Figura 36 . Extracción: DimCostos. ... 113
Figura 37. Extracción: DimTiempo. ... 114
Figura 38. Extracción: HechoRentas. ... 114
Figura 39. Nueva Conexión OLE DB. ... 115
Figura 40. Administrador de Conexiones. ... 116
Figura 41. Test de Conexión. ... 116
Figura 42. Comprobando Conexión. ... 117
Figura 43. Tarea Ejecutar SQL ... 118
Figura 45. Verificación de configuración ... 119
Figura 46. Elaboración de las Dimensiones. ... 119
Figura 47. Creación de Origen OLE DB DimPersonal... 120
Figura 48. Elección de Campos. ... 121
Figura 49. Agregación de Tablas Personal. ... 121
Figura 50. Generador de consultas Personal. ... 122
Figura 51. Visualización de las Tablas Personal. ... 122
Figura 52. Copiar Columna... 123
Figura 53. Administrador de Conexiones OLE DB Personal. ... 124
Figura 54. Asignaciones de Columnas Personal. ... 124
Figura 55. Visualización de la Cantidad de Filas Insertadas Personal. ... 125
Figura 56. Origen OLE DB DimMaterial. ... 126
Figura 57. Administrador de Conexiones OLE DB Material. ... 126
Figura 58. Asignaciones de Columnas Material. ... 127
Figura 59. Visualización de la Cantidad de Filas Material. ... 128
Figura 60. Origen OLE DB DimUbigeo. ... 128
Figura 61. Administrador de Conexiones OLE DB Ubigeo. ... 129
Figura 62. Asignaciones de Columnas Ubigeo. ... 129
Figura 63. Visualización de la Cantidad de Filas Ubigeo. ... 130
Figura 64. Origen OLE DB DimArbitrio. ... 130
Figura 65. Administrador de Conexiones OLE DB Arbitrio ... 131
Figura 66. Asignaciones de Columnas Arbitrio. ... 131
Figura 68. Origen OLE DB DimCostos. ... 132
Figura 69. Administrador de Conexiones OLE DB Costos. ... 133
Figura 70. Asignaciones de Columnas Costos. ... 133
Figura 71. Visualización de la Cantidad de Filas Costos. ... 134
Figura 72. Selección de Consulta Tiempo. ... 135
Figura 73. Selección de Tabla Orden ... 135
Figura 74. Visualización de los Datos de la Dimensión ... 136
Figura 75. Administrador de Conexiones OLE DB DimTiempo. ... 137
Figura 76. Asignaciones de Columnas Tiempo. ... 137
Figura 77. Visualización de la Cantidad de Filas DimTiempo. ... 138
Figura 78. Unión de Dimensiones. ... 138
Figura 79. Selección de SELECT distint. ... 139
Figura 80. Copia de USP_Carga_Impuesto. ... 140
Figura 81. Tarea Ejecutar SQL. ... 140
Figura 82. Verificación de ETL_ETEN. ... 141
Figura 83. Limpiar Tabla ETL. ... 142
Figura 84. Copia y Pega del código en SQL. ... 142
Figura 85. Visualización de Resultados en Load. ... 143
Figura 86. Visualización Carga (Load) DimPersonal. ... 144
Figura 87. Visualización Carga (Load) DimMaterial. ... 144
Figura 88. Visualización Carga (Load) DimUbigeo. ... 145
Figura 89. Visualización Carga (Load) DimArbitrio. ... 145
Figura 91. Visualización Carga (Load) DimTiempo. ... 147
Figura 92. Visualización Carga (Load) HechosRentas. ... 148
Figura 93. Herramienta Power BI creacion de Cubos OLAP. ... 149
Figura 94. Creación de nombre de servidor DENIS ... 149
Figura 95. Selección de dimensiones y hecho. ... 150
Figura 96. Metodo Estrella ... 151
Figura 97. Montos de Arbitrios ... 152
Figura 98. Reporte de Arbitrios ... 153
Figura 99. Reporte de Personal Responsable ... 154
Figura 100. Datos del Personal Responsable. ... 155
Figura 101. Monto de materiales ... 156
INDICE DE TABLAS
Tabla 1.Valores actuales de los indicadores ... 8
Tabla 2. Tabla de diferencias ... 26
Tabla 3. Temas analíticos ... 30
Tabla 4. Matriz proceso/Dimensiones ... 31
Tabla 5. Modelo multidimensional ... 52
Tabla 6. Pasos para tomar decisiones ... 54
Tabla 7. Definición y Operacionalización de Variables ... 59
Tabla 8. Cronograma de actividades... 61
Tabla 9. Costo personal ... 62
Tabla 10. Costo materiales ... 62
Tabla 11. Costo de servicios ... 63
Tabla 12. Resumen de costos ... 64
Tabla 13. Técnicas para la recolección de datos ... 67
Tabla 14. Instrumentos para la recolección de datos... 68
Tabla 15. Primera pregunta al personal responsable ... 70
Tabla 16. Segunda pregunta al personal responsable ... 71
Tabla 17. Tercera pregunta al personal responsable ... 72
Tabla 18. Cuarta pregunta al personal responsable ... 73
Tabla 19. Quinta pregunta al personal responsable ... 75
Tabla 20. Primera pregunta al Gerente de rentas ... 76
Tabla 21. Segunda pregunta al Gerente de rentas ... 77
Tabla 23. Cuarta pregunta al Gerente de rentas ... 84
Tabla 24. Cuadro comparativo Kimball vs Inmon y Devlin. ... 85
Tabla 25. Funciones de equipos de trabajo 1 ... 88
Tabla 26. Funciones de equipos de trabajo 2 ... 89
Tabla 27. Procesos de Negocio basados en entrevistas ... 91
Tabla 28. Matriz Procesos/Dimensiones ... 91
Tabla 29. Lista de Requerimientos ... 92
Tabla 30. Dimensiones ... 96
Tabla 31.Dimensión Personal ... 97
Tabla 32. Dimensión Material ... 97
Tabla 33. Dimensión Ubigeo ... 98
Tabla 34. Dimensión Arbitrio ... 98
Tabla 35. Dimensión Costos ... 99
Tabla 36. Dimensión Tiempo. ... 99
Tabla 37. Tabla de Hechos: HechoRentas ... 101
Tabla 38. Medidas ... 102
Tabla 39. Diseño Físico: DimUbigeo ... 106
Tabla 40. Diseño Físico: DimPersonal ... 107
Tabla 41. Diseño Físico: DimMaterial. ... 108
Tabla 42. Diseño Físico: DimArbitrio ... 108
Tabla 43. Diseño Físico: DimCostos ... 109
Tabla 44. Diseño Físico: DimTiempo ... 109
INTRODUCCIÓN
El presente Proyecto tiene como objetivo principal desarrollar una solución de Inteligencia de Negocios, dicha herramienta nos permitirá mejorar el proceso de toma de decisiones en el área de Rentas de la Municipalidad Distrital de Ciudad Eten. Esto permitirá al gerente saber el estado de las recaudaciones y deudas hechas por el área, y en base a ello tomar decisiones más acertadas que contribuirán con los objetivos estratégicos que tiene la entidad.
En el capítulo I abarca el Diseño Teórico, donde se detallan los antecedentes, así como las Bases teóricas, también se detalla la definición y Operacionalización de variables que hemos identificado previamente.
El capítulo II se describe los Métodos y Materiales donde se detalla el Diseño de contrastación de hipótesis, la población, la muestra, así como los métodos, técnicas e instrumentos que usaremos para la extracción de la información.
En el capítulo III abarca los Resultados y discusión. Empezamos por la definición de las generalidades para luego tomar el desarrollo en sí de la solución. Se plasma fase por fase el camino que se siguió para el desarrollo de nuestra solución basándonos en la metodología de Ralph Kimball, la cual también es conocida como Business Dimensional LifeCycle (Ciclo de Vida Dimensional del Negocio).
El capítulo IV abarca las conclusiones que dejaron el desarrollo de la tesis.
Para finalizar en el capítulo V se detallan las Recomendaciones, las Referencias Bibliográficas que sirvieron de ayuda en el transcurso de la elaboración de la tesis y los anexos que están ahí como apoyo.
CAPITULO I:
I. DISEÑO TEÓRICO 1.1. El Problema
1.1.1.Realidad Problemática.
A diario tomamos diferentes decisiones ya sea a nivel profesional, sentimental, familiar, etc. Esta consiste en realizar una elección entre diversas alternativas. Sin embargo, cuando aplicamos esto al ámbito empresarial las cosas ya no son tan sencillas, ya que es el proceso de donde depende el triunfo de la organización.
Es por ello que, si como directivos tomamos decisiones acertadas, lograremos el éxito en nuestra organización. Pero si, por el contrario, tomamos decisiones erróneas, nos veremos ante una situación muy desfavorable. Con esto vemos la gran importancia que tiene el realizar una correcta toma de decisiones.
Podemos decir que, en el ámbito organizacional, la mayoría de las decisiones significativas se realizan mediante el juicio. Lo cual indica una falta de apoyo en la información. (Chacin, 2010, pág. 13)
Y ante esto podemos preguntarnos ¿La información es necesaria? Ya que este cumple un papel muy importante en el proceso de toma de decisiones.
La respuesta que podemos dar es que la información es la materia prima, la entrada de una decisión, y cuando es tratada dentro del proceso de toma de decisiones se obtiene como salida de la acción a ejecutar. (VV.AA, 2007, pág. 63)
Cosa que es apoyada por (Villanueva L. , pág. 25) al considerar que la toma de decisiones que se lleva a cabo dentro de las organizaciones debe cumplir con ciertas características, una de las cuales es ser fundamentada en información concreta.
Con todo esto podemos decir, que el proceso de toma de decisiones es importante porque determina el éxito de la empresa, pero la información a su vez también lo es y además necesario para realizar el proceso de manera óptima. Debemos recalcar que la información debe ser, primero que nada, verídica, exacta y precisa. Y por supuesto también debe ser oportuna, es decir, que se encuentre accesible para quien la requiera y en el momento en que lo requiera.
El problema que aqueja actualmente la Municipalidad Distrital de Ciudad Eten se observa en el Área de Rentas, esta área se encarga básicamente de la administración, recaudación y fiscalización de todas las obligaciones tributarias y/o multas administrativas con fines de garantizar el objetivo liquides de la Municipalidad. Es aquí donde se ve la inadecuada administración y distribución de los montos, esto es debido a que no cuentan con un sistema que muestre los reportes necesarios para poder dar una adecuada solución, conocer en donde se recaudan los mayores montos por impuestos prediales y arbitrios Municipales, o quiénes son los contribuyentes que pagan los mayores montos para así poder ver el avance y cuanto es lo que falta para llegar a la meta que quieren alcanzar cada año.
En el presente proyecto se ha podido identificar que a pesar de que la Municipalidad cuenta con este programa que brinda reportes para las diferentes áreas, estos no son suficientes, ya que los procesos que se realizan con ellos para obtener información útil en la toma de decisiones implican que más de un reporte sea analizado y filtrado. El área de Rentas también ha sido involucrada en la elaboración de este tipo de reportes generando una mayor carga laboral para esta área y la dependencia de otras áreas, quienes solicitan estos reportes para luego llegar a una conclusión que brinde información útil sobre la realidad actual de la Municipalidad y finalmente tomar una decisión.
Con la finalidad de solucionar lo antes mencionado, proponemos una Inteligencia de Negocios para mejorar el Proceso de Toma de Decisiones en el Área de Rentas de la Municipalidad Distrital de Ciudad Eten.
La municipalidad de Ciudad Eten se encuentra ubicada en Plaza de Armas, Av. Pedro Ruiz Nº579, Ciudad Eten-Perú. (Ver Figura 01).
1.1.2. Definición del Problema
El problema en cuestión se centra en el área de rentas de la Municipalidad Distrital de Ciudad Eten, en cuya gerencia el proceso de toma decisiones muchas veces no hace uso de la información actual del estado de las recaudaciones de impuestos y arbitrios. Esto es debido a que el sistema transaccional (el llamado sistema de recaudación) nos permite conocer, por ejemplo, donde se recaudan los mayores montos por impuestos prediales y arbitrios municipales, o quiénes son los contribuyentes que pagan los mayores montos (principales contribuyentes).
Es por esto que, para obtener dicha información, la gerencia de rentas debe solicitar reportes al área de informática, cuyo personal los genera con datos obtenidos de Microsoft Excel, lo cual demanda mucho tiempo y esfuerzo.
Figura 02. Proceso de Toma de Decisiones en el Área de Rentas de la Municipalidad Distrital de Ciudad Eten
Fuente: Elaboración Propia
Del Siguiente proceso podemos ver e inferir problemas con: El tiempo empleado en la generación de reportes. El tiempo que emplea en el análisis de la información. El número de veces que se accede a la información al día.
El porcentaje de exactitud de la información. El nivel de satisfacción del Gerente de Renta.
Tabla 1.
Valores actuales de los indicadores
Indicador Datos de Pre Prueba (Promedio)
Tiempo empleado en la generación de reportes
30 minutos
Tiempo empleado en el análisis de la
información 2 horas
El número de veces que se accede a la información al día.
0
El porcentaje de exactitud de la información.
82% El nivel de satisfacción del Gerente de
Rentas. Bajo
Fuente: Elaboración Propia.
Proceso de Toma de Decisiones en el Área de Rentas de la Municipalidad Distrital de Ciudad Eten
Figura 02. Proceso de Toma de Decisiones en el Área de Rentas. Fuente: Elaboración Propia
1.1.3.Enunciado del Problema
1.2. Tipo y Nivel de la Investigación 1.2.1.Tipo de Investigación
Cuantitativa: Porque se investiga por medio de técnicas estadísticas.
Aplicada: Porque aplica teorías especializadas con el tema de investigación. 1.2.2.Nivel de Investigación
Explicativo: Porque presenta una visión general y aproximada del objeto de estudio, cuando un tema ha sido poco explorado.
1.3. Justificación de la Investigación
Científica
La teoría que se emplea es la metodología llamada Ciclo de Vida Dimensional del Negocio, la cual fue un trabajo de muchos años por parte de Ralph Kimball (Kimball & Ross, 2008). Dicha metodología defiende el enfoque bottom-up, es decir un enfoque ascendente para diseñar un almacén de datos o Data Warehouse, la misma que Kimball definió como “la unión de todos los Data Mart de una entidad”.
La importancia que tiene en este proyecto es que gracias a esta metodología se podrá elaborar la solución de Inteligencia de Negocio desde cero, en otras palabras, servirá de guía o manual para el desarrollo del producto, el cual tiene como fin mejorar el proceso de toma de decisiones.
Institucional
Ante esta situación, el desarrollo de la solución de Inteligencia de Negocio busca una optimización del proceso de toma de decisiones del área de Rentas.
Social
El beneficio social que brinda este proyecto es que, al solucionar el problema en la institución, puede servir de ejemplo o modelo para otras instituciones que adolezcan del mismo problema. Abriendo de este modo la posibilidad de que en un futuro puedan aplicarlo también, y por ende obtener una solución viable.
Por otro lado, podemos decir que el beneficio social también va muy ligado a un beneficio académico, pues el presente proyecto también servirá de guía para los ciclos posteriores que realicen proyectos de tesis relacionados al tema de la Inteligencia de Negocio.
1.4. Objetivos
1.4.1. Objetivo general.
Desarrollar una Solución de Inteligencia de Negocios para mejorar el Proceso de Toma de Decisiones en el Área de Rentas de la Municipalidad Distrital de Ciudad Eten.
1.4.2. Objetivos específicos
a) Analizar la situación interna del Área de Rentas de la Municipalidad Distrital de Ciudad Eten.
b) Conocer la información actual que sirve como soporte para la toma de decisiones de la Municipalidad Distrital de Ciudad Eten.
c) Diseñar la herramienta de Inteligencia de Negocios.
1.5. Hipótesis
La Implementación de una Solución de Inteligencia de Negocios mejorará el Proceso de Toma de Decisiones del Área de Rentas de la Municipalidad Distrital de Ciudad Eten.
1.6. Antecedentes
1.6.1. Antecedentes en el contexto internacional.
Así mismo (Arena López & Gómez Montes, 2017), contiene un conjunto de procedimientos y técnicas, que desde la inteligencia de negocios, apoyan los procesos de autoevaluación institucional de la Universidad de Manizales. El objetivo de este proyecto es diseñar una solución que proporcione calidad a la presentación de los datos y que a partir de hechos e información argumentada sirva como un apoyo a la toma de decisiones, iniciando con el levantamiento de la información, análisis de fuentes de datos, creación de los reportes o informes diseñados a partir de los indicadores cuantitativos que permitirán la toma de decisiones e identificación de necesidades o fortalezas a lo largo de los procesos de autoevaluación que se definen continuamente por la institución. Al tener la información y los datos conectados correctamente se tendrán informes y comportamientos que representan y gestionan los grandes volúmenes de información.
1.6.2. Antecedentes en el contexto nacional.
El trabajo de fin de titulación de (Ocas Terrones, 2012), desarrolla un Data Mart para el apoyo al proceso de toma de decisiones del área de administración y finanzas de la Municipalidad Distrital de los Baños del Inca.
Debido a que sus sistemas actuales no soportan el manejo adecuado de grandes volúmenes de información, tienen el problema de utilizar su información para emplearla en la toma de decisiones de la institución.
Para llevar adelante el desarrollo del Data Mart se utilizó la metodología de Kimball, conformada por las siguientes etapas:
Análisis de requerimientos: Se debe aprender tanto como se pueda sobre el negocio, los competidores, la industria y los clientes del mismo.
Modelado Dimensional: El proceso de diseño comienza con un modelo dimensional de alto nivel obtenido a partir de los procesos priorizados.
Diseño del sistema de Extracción, Transformación y Carga (ETL): El sistema de Extracción, Transformación y Carga (ETL) es la base sobre la cual se alimenta el Datawarehouse. Si el sistema ETL se diseña adecuadamente, puede extraer los datos de los sistemas de origen de datos, aplicar diferentes reglas para aumentar la calidad y consistencia de los mismos
Especificación y desarrollo de aplicaciones de BI: Las aplicaciones de BI son la cara visible de la inteligencia de negocios: los informes y aplicaciones de análisis proporcionan información útil a los usuarios.
Para concluir con el proyecto, se realizó la contratación de la hipótesis, las conclusiones y finalizando con las recomendaciones.
Así mismo (Vargas Chumpitas, 2016), consiste en el desarrollo de una solución de Business Intelligence, herramienta que ayudará a mejorar el proceso de toma de decisiones en el área de rentas de la municipalidad de Lurín.
Si bien es cierto que la gerencia de rentas de la municipalidad de Lurín sí usa la información del sistema transaccional para tomar decisiones, el proceso de obtención de reportes resulta demasiado tardío y demanda mucho esfuerzo por parte del personal de informática.
Para el desarrollo se empleó la metodología de Ralph Kimball, la cual se adaptó más a nuestro caso de estudio pues está enfocada únicamente a una parte de la empresa o institución.
La solución final para el usuario consistirá en una serie de reportes acerca del estado actual e histórico de las recaudaciones y deudas realizadas por el área, para que así se puedan tomar decisiones basándose de información real.
1.6.3. Antecedentes en el contexto Regional.
En la investigación de (Piscoya Ordoñez, 2016), tiene como objetivo proponer una herramienta utilizando las técnicas de minería de datos, donde permita al usuario tener acceso a la información precisa donde se realicen predicciones sobre los alumnos que se matriculen en los próximos años, obteniendo resultados a corto plazo, que permitirá asegurar la confiabilidad de éstos, sirviendo de apoyo a la institución para las decisiones futuras que se puedan tomar.
Dentro de las técnicas predictivas se determinó utilizar los algoritmos de ETS y Redes Neuronales, al realizar el análisis se descartaron algunas técnicas adicionales por no tener los criterios necesarios para su implementación en el modelo a desarrollar.
Además, se presentan los antecedentes de estudio a nivel de base teórica, tomando como fuentes libros, publicaciones, entre otros, los cuales permiten justificar muchos de los conceptos abarcados durante el proceso de investigación.
que retrasan el proceso de los resultados; y el uso de la metodología XP para el desarrollo del sistema como solución a la optimización de los procesos mostrando los resultados.
Así mismo (Angeles Neciosup, 2015), para la realización de la toma de decisiones, se ha planteado la implementación del desarrollo de un software para la toma de decisiones utilizando minería de datos y así poder optimizar los procesos en la Gestión de ventas, en la empresa PROCOMS.A.C de la ciudad de Pimentel, mediante su información histórica de ventas, de modo que se brinde al personal involucrado una herramienta que contribuya al logro de mejores estrategias de negocio, mediante pronósticos de ventas basados en algoritmos de minería de datos. A través de técnicas e instrumentos de recolección de datos como la observación, la entrevista y el cuestionario, se lograron identificar los principales procesos dentro de la Empresa; tomando como base para la investigación el proceso de ventas, como fuente de información histórica a consultar, y, como elemento clave para la creación de un modelo de minería de datos que permita realizar pronósticos a corto y mediano plazo. Se desarrollan dos de las metodologías más importantes en el campo de la Inteligencia de Negocios, que son la metodología CRISP-DM y Metodología XP, para la aplicación de minería de datos orientada al pronóstico de ventas y para el Software.
1.6.4. Antecedentes en el contexto Local.
que se deben realizar con ellos para obtener información útil en la toma de decisiones implican que más de un reporte sea analizado y filtrado.
El desarrollo de un Sistema DATAWAREHOUSE, representa el primer paso para desarrollar una solución completa y fiable de Inteligencia de Negocios, de vital importancia para la toma de decisiones oportunas, basadas en información propia y no sólo en la experiencia del personal. Permitiendo a los directivos formular preguntas, realizar consultas, analizar los datos en el momento, forma y cantidad que precisen, ampliar la visión estratégica, reducir el riesgo y la incertidumbre en la toma de decisiones empresariales construyendo ventajas competitivas, descubriendo patrones de comportamiento y tendencias difíciles de detectar debido a la gran cantidad de datos. Para realizar el presente proyecto se ha optado por la metodología Ralph Kimball y las herramientas utilizadas para el desarrollo del mismo son: Microsoft Visual Studio 2008 y Microsoft SQL Server Management Studio 2008.
una limpieza de los datos almacenados para poder generar con ellos reportes que ayuden al directorio a la toma de decisiones. Para la realización del actual tema de tesis, se está optando por utilizar la suite de Inteligencia de Negocios proporcionada por Análisis Service. Por esta razón, el presente proyecto dará pautas para la utilización de esta herramienta, lo cual servirá de base para proyectos similares que deseen implementar proyectos con ella. Para implementar este proyecto de tesis se realizó todos los pasos de un proyecto de Inteligencia de Negocios: diseño y construcción del Datawarehouse y los Data marts, creación y programación de los procesos ETL, creación de los cubos, creación de los informes, minería de datos.
1.7. Bases Teóricas
1.7.1.Inteligencia de negocios.
Según Curto (2012), define a Inteligencia de Negocios o Business Intelligence como al conjunto de metodologías, aplicaciones, prácticas y capacidades enfocadas a la creación y administración de información que permite tomar mejores decisiones a los usuarios de una organización. (pág. 18)
Según Cano (2007), La inteligencia de Negocio cuenta con componentes los cuales son: Fuentes de información, de las cuales partiremos para alimentar de información el Data Warehouse.
SISTEMAS
El propio Data Warehouse o almacén de datos, con la metadata o diccionario de datos. Se busca almacenar los datos de una forma que maximice su flexibilidad, facilidad de acceso y administración.
El motor OLAP, que nos debe proveer capacidad de cálculo, consultas, funciones de planeamiento, pronóstico y análisis de escenarios en grandes volúmenes de datos.
Las herramientas de visualización, que nos permitirán el análisis y la navegación a través de los mismos. (pág. 94).
Figura 03. Componentes de Inteligencia de Negocio. Fuente: (Cano, 2007)
1.7.1.1. Data warehouse.
grandes velocidades de respuesta. La ventaja principal de este tipo de bases de datos radica en las estructuras en las que se almacena la información (modelos de tablas en estrella, en copo de nieve, cubos relacionales... etc.). Este tipo de persistencia de la información es homogénea y fiable, y permite la consulta y el tratamiento jerarquizado de la misma (siempre en un entorno diferente a los sistemas operacionales). (pág. 54).
Según Kimball & Ross (2002), considera que el proceso consta de cuatro componentes: sistemas operacionales fuente, área de preparación de datos, área de presentación de datos y herramientas de acceso a datos. (pág. 7).
Figura 04. Elementos Básicos de Almacén de Datos. Fuente: (Kimball & Ross, 2008)
Sistemas Operacionales Fuente: Sistemas de registro que capturan las transacciones del negocio. Los sistemas fuente deben ser considerados como parte fuera del Data Warehouse ya que se tiene poco o ningún control sobre su contenido y el formato de los datos que contienen.
Área de Preparación de Datos: Es a la vez un área de almacenamiento y un conjunto de procesos comúnmente conocido como extracción, transformación y carga (ETL). El área de preparación de datos es todo lo que existe entre los sistemas operacionales fuente y el área de presentación de datos. Es algo análogo a la cocina de un restaurante, donde los productos alimenticios crudos son transformados en buena comida. En el Data Warehouse, datos operacionales crudos son transformados en un almacén entregable para las consultas de usuario.
Área de Presentación de Datos: Es donde los datos son organizados, almacenados y puestos a disposición para consultas directas por los usuarios, redactores de informes y otras aplicaciones analíticas. Es todo lo que la comunidad del negocio ve y toca por medio de herramientas de acceso a datos.
Herramientas de Acceso a Datos: Es el componente principal final del entorno. Usamos el término herramientas para referirnos a la variedad de capacidades que pueden ser proporcionadas a los usuarios del negocio para aprovechar el área de presentación para la toma de decisiones. Por definición, todas las herramientas de acceso a datos consultan los datos existentes en el área de presentación. (Kimball & Ross, 2008, págs. 8-13).
En la Figura N° 04 podemos apreciar la relación entre los mencionados componentes. 1.7.1.2. Datamart
Según Yalan Castillo & Palomino Paniora (2013), Un DataMart es una base de datos departamental, especializada en el almacenamiento de los datos de un área de negocio específica. (pág. 54).
Datamart OLTP: Pueden basarse en un simple extracto del Data Warehouse, no obstante, lo común es introducir mejoras en su rendimiento (las agregaciones y los filtrados suelen ser las operaciones más usuales) aprovechando las características particulares de cada área de la empresa.
Los datamarts que están dotados con estas estructuras óptimas de análisis presentan las siguientes ventajas:
Poco volumen de datos.
Mayor rapidez de consulta.
Validación directa de la información.
Datamart OLAP: Se basan en los populares cubos OLAP, que se construyen agregando, según los requisitos de cada área o departamento, las dimensiones y los indicadores necesarios de cada cubo relacional. (pág. 55).
Según Cano (2007), La representación gráfica del OLAP son los cubos. Veamos un ejemplo:
En la Figura 05 podemos ver que en el cubo tenemos las unidades vendidas de cada uno de los libros, para los distintos clientes y en los distintos años. Este es el concepto de multimensionalidad. Disponemos de las unidades vendidas de cada uno de los libros para cada uno de los clientes y en cada uno de los años: el contenido de un cubo individual son las ventas de un libro a un cliente en un año. Los contenidos de cada uno de los cubos individuales del cubo recogen lo que llamamos “hechos” (en nuestro ejemplo las unidades vendidas). En la actualidad, las soluciones OLAP permiten que cada una de los cubos individuales pueda contener más de un hecho.
Las herramientas OLAP nos permiten “rotar” (en inglés “slicing”) los cubos, es decir, cambiar el orden de las distintas dimensiones: En lugar de analizar por clientes, como en el caso anterior, quizás estamos interesados en analizarlo por libros, ya que los usuarios que lo quieren consultar son distintos y tienen distintas necesidades.
Figura 06. Ejemplo de Cubo Olap. Fuente: (Cano, 2007).
En la Figura 06 podemos ver como en el ejemplo anterior, hemos cambiado la dimensión “clientes” por la de “libros”. También podemos seleccionar (en inglés “dicing”) sólo algunas de las celdas, por ejemplo: ¿Cuáles son las ventas al cliente 2, de los libros 1 y 2, en el año 1?
Figura 07. Ejemplo del Cubo Olap. Fuente: (Cano, 2007)
En la Figura 07 nos puede interesar es el total de libros, máximo nivel de agregación (en inglés “roll-up”):
Figura 08. Ejemplo del Cubo Olap. Fuente: (Cano, 2007)
En la Figura 08, Imaginemos que tenemos libros de dos materias distintas: El libro 1 y el libro 2 son de la materia A y el libro 3 de la materia B. Partiendo del cubo anterior de las ventas agregadas, bajamos a más detalle (en inglés “drill-down”) a través de la jerarquía “materias”. En ese caso obtendríamos:
Figura 09. Ejemplo del Cubo Olap. Fuente: (Cano, 2007)
En la Figura 09, Como hemos visto en el ejemplo anterior, las jerarquías nos permiten hacer agrupaciones. Existen distintos tipos de herramientas OLAP. La diferencia entra ellas, básicamente, depende de cómo acceden a los datos:
ROLAP: Relational OLAP
Las capacidades OLAP acceden directamente a la base de datos relacional. Se accede por tanto a una base de datos relacional (RDBMS). Accede habitualmente sobre un modelo “estrella”. La principal ventaja es que no tiene limitaciones en cuanto al tamaño, pero es más lento que el MOLAP, aunque algunos productos comerciales nos permiten cargar cubos virtuales para acelerar los tiempos de acceso.
MOLAP: Multimensional OLAP
La implementación OLAP accede directamente sobre una base de datos multidimensional. La ventaja principal de esta alternativa es que es muy rápida en los tiempos de respuesta y la
principal desventaja es que, si queremos cambiar las dimensiones, debemos cargar de nuevo el cubo.
HOLAP: Hybrid OLAP
Accede a los datos de alto nivel en una base de datos multidimensional y a los atómicos directamente sobre la base de datos relacional. En esencia utiliza las ventajas del ROLAP y del MOLAP. (Cano, 2007, págs. 127-130).
1.7.1.3. Diferencia entre un data warehouse y datamart.
Tabla 2.
Tabla de Diferencias
Data Warehouse DataMart
Alcance Construido para satisfacer las necesidades de información de
toda la organización.
Construir para satisfacer las necesidades de un área de
negocios específica.
Objetivos
Diseñado para optimizar la integración y la administración de
los datos fuentes.
Diseñado para optimizar la entrega de información de
soporte a decisiones.
Datos Administra grandes cantidades de datos históricos a nivel atómico.
Se concentra en administrar resúmenes y / o datos
totalizados.
Pertenencia Pertenece a toda la Organización. Pertenece al área de negocio al cual está orientado.
Administración Es administrado por la unidad de sistema de la organización.
Es administrado por el personal de sistema de la unidad propietaria del Datamart.
1.7.2. Metodología de Kimball.
Según Mundy & Thornthwaite (2006), menciona que la metodología se basa en lo que Kimball denomina Ciclo de Vida Dimensional del Negocio (Business Dimensional Lifecycle). Este ciclo de vida del proyecto de DW, está basado en cuatro principios básicos:
Centrarse en el negocio: Hay que concentrarse en la identificación de los requerimientos del negocio y su valor asociado, y usar estos esfuerzos para desarrollar relaciones sólidas con el negocio, agudizando el análisis del mismo y la competencia consultiva de los implementadores.
Construir una infraestructura de información adecuada: Diseñar una base de información única, integrada, fácil de usar, de alto rendimiento donde se reflejará la amplia gama de requerimientos de negocio identificados en la empresa.
Realizar entregas en incrementos significativos: crear el almacén de datos (DW) en incrementos entregables en plazos de 6 a 12 meses. Hay que usa el valor de negocio de cada elemento identificado para determinar el orden de aplicación de los incrementos. En esto la metodología se parece a las metodologías ágiles de construcción de software.
La construcción de una solución de DW/BI (Datawarehouse/Inteligencia de Negocio) es sumamente compleja, y Kimball nos propone una metodología que nos ayuda a simplificar esa complejidad. Las tareas de esta metodología (ciclo de vida) se muestra en la Figura 10:
Figura 10. Tareas de la Metodología de Kimball Denominada Business. Fuente:(Rivadera, 2010)
Planificación.
refiere a una iteración simple del KLC (Kimball Life Cycle), desde el lanzamiento hasta el despliegue.
Esta tarea incluye las siguientes acciones típicas de un plan de proyecto:
Definir el alcance (entender los requerimientos del negocio).
Identificar las tareas.
Programar las tareas.
Planificar el uso de los recursos.
Asignar la carga de trabajo a los recursos.
Elaboración de un documento final que representa un plan del proyecto.
Además, en esta parte definimos cómo realizar la administración o gestión de esta subfase que es todo un proyecto en sí mismo, con las siguientes actividades:
Monitoreo del estado de los procesos y actividades.
Rastreo de problemas.
Desarrollo de un plan de comunicación comprensiva que direccione la empresa y las áreas de TI.
Análisis de Requerimientos.
del negocio. Parte del proceso de preparación es averiguar a quién se debe realmente entrevistar. Esto normalmente implica examinar cuidadosamente el organigrama de la organización. Hay básicamente cuatro grupos de personas con las que hablar desde el principio: el directivo responsable de tomar las decisiones estratégicas; los administradores intermedios y de negocio responsables de explorar alternativas estratégicas y aplicar decisiones; personal de sistemas, si existen, la gente que realmente sabe qué tipos de problemas informáticos y de datos existen; y por último, la gente que se necesita entrevistar por razones políticas. A partir de las entrevistas, podemos identificar temas analíticos y procesos de negocio. Los temas analíticos agrupan requerimientos comunes en un tema común (ver Tabla 3).
negocio de soporte Comentarios
Planificación
a analizar, datos que se denominan medidas (measures en inglés). Esta matriz tiene en sus filas los procesos de negocio identificado, y en las columnas, las dimensiones identificadas. Un ejemplo de esta matriz se puede observar en la Tabla 4. Cada X en la intersección de las filas y columnas significa que en el proceso de negocio de la fila seleccionada se identifican las dimensiones propuestas.
Tabla 4
Matriz de Procesos/ Dimensiones (Bus Matrix).
Dimensiones
Proceso de
Negocio Tiempo Producto Empleados
1.7.2.1. Modelo dimensional.
La creación de un modelo dimensional es un proceso dinámico y altamente iterativo. Un esquema general se puede ver en la Figura 11.
Figura 11. Diagrama de Flujo del Proceso Dimensional de Kimball. Fuente: (Rivadera, 2010).
El proceso de diseño comienza con un modelo dimensional de alto nivel obtenido a partir de los procesos priorizados de la matriz descrita en el punto anterior. El proceso iterativo consiste en cuatro pasos:
2. Establecer el nivel de granularidad. 3. Elegir las dimensiones.
4. Identificar medidas y las tablas de hechos. 1. Elegir el proceso de Negocio.
Consiste en, elegir el área a modelizar. Esta es una decisión de la dirección, y depende fundamentalmente del análisis de requerimientos y de los temas analíticos anotados en la etapa anterior.
2. Establecer el nivel de granularidad.
La granularidad significa especificar el nivel de detalle. La elección de la granularidad depende de los requerimientos del negocio y lo que es posible a partir de los datos actuales. La sugerencia general es comenzar a diseñar el DW al mayor nivel de detalle posible, ya que se podrían realizar agrupamientos posteriores, al nivel deseado.
3. Elegir las dimensiones.
Las dimensiones surgen naturalmente de las discusiones del equipo, y facilitadas por la elección del nivel de granularidad y de la matriz de procesos/dimensiones.
Las tablas de dimensiones tienen un conjunto de atributos (generalmente textuales) que brindan una perspectiva o forma de análisis sobre una medida en una tabla hechos. Una forma de identificar las tablas de dimensiones es que sus atributos son posibles candidatos para ser encabezado en los informes, tablas pivot, cubos, o cualquier forma de visualización, unidimensional o multidimensional.
4. Identificar medidas y las tablas de hechos.
datos y usando los criterios de corte conocidos como dimensiones. Las medidas habitualmente se vinculan con el nivel de granularidad del punto 2, y se encuentran en tablas que denominamos tablas de hechos (fact en inglés). Cada tabla de hechos tiene como atributos una o más medidas de un proceso organizacional, de acuerdo a los requerimientos. Un registro contiene una medida expresada en números, como ser cantidad, tiempo, dinero, etc., sobre la cual se desea realizar una operación de agregación (promedio, conteo, suma, etc.) en función de una o más dimensiones. La granularidad, en este punto, es el nivel de detalle que posee cada registro de una tabla de hechos.
Modelo gráfico de alto nivel.
Para concluir con el proceso dimensional inicial se realiza un gráfico denominado modelo dimensional de alto nivel (o gráfico de burbujas, Bubble chart, en el léxico de Kimball), como ilustra la Figura 12.
- Identificación de atributos de dimensiones y tablas de hechos.
La segunda parte de la sesión inicial de diseño consiste en completar cada tabla con una lista de atributos bien formada.
Esta lista o grilla se forma colocando en las filas los atributos de la tabla, y en las columnas la siguiente información:
Características relacionadas con la futura tabla dimensional del almacén de datos (target), por ejemplo, tipo de datos, si es clave primaria, valores de ejemplo, etc. Por razones de espacio no describiremos todas las columnas, para mayor información puede consultarse la referencia.
El origen de los datos (source, por lo general atributos de las tablas transaccionales).
Reglas de conversión, transformación y carga (ETL rules), que nos dicen cómo transformar los datos de las tablas de origen a las del almacén de dato.
- Implementar el modelo dimensional detallado.
Este proceso consiste simplemente en completar la información incompleta de los pasos anteriores. El objetivo en general es identificar todos los atributos útiles y sus ubicaciones, definiciones y reglas de negocios asociadas que especifican cómo se cargan estos datos. Para este cometido se usa la misma planilla del punto anterior.
- Prueba del modelo.
- Revisión y validación del modelo.
Una vez que tenemos confianza plena en el modelo, ingresamos en esta etapa final (ver en la Figura 11), lo cual implica revisar el modelo con diferentes audiencias, cada una con diferentes conocimientos técnicos y del negocio. En el área de sistemas deberían revisarlo los programadores y analistas de los sistemas, y el DBA si existe. También debería revisarse con usuarios y personas del negocio que tengan mucho conocimiento de los procesos y que quizás no hayan participado del diseño del modelo. Finalmente podemos hacer un documento que enuncie una serie de preguntas del negocio (tomadas a partir de los requerimientos), y las conteste por medio del modelo.
- Documentos Finales.
El producto final, como se puede ver en la Figura 11, son una serie de documentos (solo mencionamos los más importantes), a saber:
Modelo de datos inicial de alto nivel.
Lista de atributos.
Diagrama de tablas de hechos.
Definición de campos de medida.
Diagrama de tablas de dimensiones.
Descripción de los atributos de las dimensiones.
Matriz DW (o DW Bus Matrix) completa. 1.7.2.2. Diseño físico.
En esta tarea, se contestan las siguientes preguntas:
¿Cuáles son los factores de uso que llevarán a una configuración más grande y más compleja?
¿Cómo se debe configurar el sistema?
¿Cuánta memoria y servidores se necesitan? ¿Qué tipo de almacenamiento y procesadores? ¿Cómo instalar el software en los servidores de desarrollo, prueba y producción?
¿Qué necesitan instalar los diferentes miembros del equipo de DW/BI en sus estaciones de trabajo?
¿Cómo convertir el modelo de datos lógico en un modelo de datos físicos en la base de datos relacional?
¿Cómo conseguir un plan de indexación inicial? ¿Debe usarse la partición en las tablas relacionales?
1.7.2.3. Diseño e implementación del subsistema.
El Sistema de Extracción, Transformación y Carga (ETL) es la base sobre la cual se alimenta el Data Warehouse. Si se diseña adecuadamente, puede extraer los datos de los sistemas de origen de datos, aplicar diferentes reglas para aumentar la calidad y consistencia de los mismos, consolidar la información proveniente de distintos sistemas, y finalmente cargar (grabar) la información en el DW en un formato acorde para la utilización por parte de las herramientas de análisis.
1.7.2.4. Especificación y desarrollo de aplicaciones de BI.
Proporcionamos este acceso estructurado a través de lo que llamamos aplicaciones de inteligencia de negocios (Inteligencia de Negocio Aplications).
Las aplicaciones de BI son la cara visible de la inteligencia de negocios: los informes y aplicaciones de análisis proporcionan información útil a los usuarios. Las aplicaciones de BI incluyen un amplio espectro de tipos de informes y herramientas de análisis, que van desde informes simples de formato fijo a sofisticadas aplicaciones analíticas que usan complejos algoritmos e información del dominio. Kimball divide a estas aplicaciones en dos categorías basadas en el nivel de sofisticación, y les llama informes estándar y aplicaciones analíticas.
- Informes Estándar
Los informes estándar son la base del espectro de aplicaciones de BI. Por lo general son informes relativamente simples, de formato predefinido, y parámetros de consulta fijos. En el caso más simple, son informes estáticos pre-almacenados. Los informes estándar proporcionan a los usuarios un conjunto básico de información acerca de lo que está sucediendo en un área determinada de la empresa. Este tipo de aplicaciones son el caballo de batalla de la BI de la empresa. Son informes que los usuarios usan día a día. La mayor parte de lo que piden las personas durante el proceso de definición de requisitos se clasificaría como informes estándar.
Por eso es conveniente desarrollar un conjunto de informes estándar en el ciclo de vida del proyecto.
Algunos informes estándares típicos podrían ser:
Ventas del año actual frente a previsión de ventas por vendedor.
Tasa de renovación mensual por plan de servicio.
Tasa quinquenal de deserción por unidad académica.
Recuento de audiencia y porcentaje de la audiencia total por la red de televisión por día de la semana y hora del día (Sistema de marketing televisivo).
Reclamos del año actual hasta la fecha frente a previsión, por tipo de vehículo.
Volumen de llamadas por producto como un porcentaje del total de ventas. - Aplicaciones Analíticas
Las aplicaciones analíticas son más complejas que los informes estándar. Normalmente se centran en un proceso de negocio específico y resumen cierta experiencia acerca de cómo analizar e interpretar ese proceso de negocio. Estas aplicaciones pueden ser muy avanzadas e incluir algoritmos y modelos de minería de datos, que ayudan a identificar oportunidades o cuestiones subyacentes en los datos. Otra característica avanzada en algunas aplicaciones analíticas es que el usuario puede pedir cambios en los sistemas transaccionales basándose en los conocimientos obtenidos del uso de la aplicación de BI. En el otro extremo del espectro, algunas aplicaciones analíticas se venden como soluciones cerradas o enlatados, y son independientes de las aplicaciones particulares de la empresa. Algunas aplicaciones analíticas comunes incluyen:
Análisis de la eficacia de las promociones.
Análisis de rutas de acceso en un sitio Web.
Análisis de afinidad de programas.
Planificación del espacio en espacios comerciales.
Detección de fraudes.
1.7.3. Metodología de Bill Inmon. - Paradigma de Bill Inmon
Bill Inmon ve la necesidad de transferir la información de los diferentes OLTP (Sistemas Transaccionales) de las organizaciones a un lugar centralizado donde los datos puedan ser utilizados para el análisis (sería el CIF o Corporate Information Factory). Insiste además en que ha de tener las siguientes características:
Orientado a Temas: Los datos en la base de datos están organizados de manera que todos los elementos de datos relativos al mismo evento u objeto del mundo real queden unidos entre sí.
Integrado: La base de datos contiene los datos de todos los sistemas operacionales de la organización, y dichos datos deben ser consistentes.
No volátil: La información no se modifica ni se elimina, una vez almacenado un dato, éste se convierte en información de sólo lectura, y se mantiene para futuras consultas.
Variante en el tiempo: Los cambios producidos en los datos a lo largo del tiempo quedan registrados para que los informes que se puedan generar reflejen esas variaciones.
La información ha de estar a los máximos niveles de detalle. Los DW departamentales o datamarts son tratados como subconjuntos de este DW corporativo, que son construidos para cubrir las necesidades individuales de análisis de cada departamento, y siempre a partir de este DW Central (del que también se pueden construir los ODS (Operational Data Stores) o similares).
metadatos que documentan de una forma clara y precisa el contenido del DW. Una vez realizado este proceso, los procesos de refresco de los DataMart departamentales obtienen la información de él, y con las consiguientes transformaciones, organizan los datos en las estructuras particulares requeridas por cada uno de ellos, refrescando su contenido. (Espinosa , 2010).
Figura 13. Enfoque Inmon-Dw Corporativo. Fuente: (Espinosa , 2010).
- Migration Plan (Plan de Migración)
Según Inmon (2003), El punto de inicio para el plan de migración es un modelo de datos corporativos. El modelo representa las necesidades de información de la corporación, es decir representa lo que la corporación necesita, no necesariamente lo que tiene actualmente. Además, está construido sin consideración de tecnología.
Temas principales de la corporación.
Definición de los principales temas de la corporación.
Relaciones entre los temas principales.
Agrupaciones de claves y atributos que representan más completamente los temas principales, incluyendo lo siguiente:
o Atributos de los temas principales.
o Teclas de los temas principales.
o Repetición de grupos de claves y atributos.
o Conectores entre las principales áreas temáticas.
o Subtitular las relaciones.
En teoría, es posible construir el entorno arquitectónico centrado en el almacén de datos sin un modelo de datos; sin embargo, en la práctica, nunca se hace.
La Figura 14 muestra que construir o adquirir un modelo de datos es el comienzo punto para el proceso de migración. Como regla general, el modelo de datos corporativos identifica información corporativa a un alto nivel. Del modelo de datos corporativos a modelo de nivel inferior está construido. El modelo de nivel inferior identifica los detalles que tienen ha sido ignorado por el modelo de datos corporativos. Este modelo de nivel medio está construido de las áreas temáticas que se han identificado en el modelo de datos corporativos, en un área temática a la vez. No se construye sobre la base de una sola vez porque tal hacerlo toma demasiado tiempo.
DSS en estos modelos. En cambio, los datos derivados y DSS son deliberadamente excluidos del modelo de datos corporativos y los modelos de nivel medio.
Figura 14. Migración al Entorno Diseñado - Parte I. Fuente: (Inmon, 2003).
Algunas razones para excluir datos derivados y datos de DSS de los datos corporativos modelo y el modelo de nivel medio incluyen los siguientes:
Los datos derivados y los datos DSS cambian con frecuencia.
Estas formas de datos se crean a partir de datos atómicos.
Con frecuencia se borran por completo.
Hay muchas variaciones en la creación de datos derivados y datos DSS.
actividad es definir el sistema de registro. El sistema de registro se define en términos de los sistemas existentes de la corporación. Por lo general, estos sistemas antiguos heredados son cariñosamente conocidos como el "desastre". El sistema de registro no es más que la identificación de los "mejores" datos la corporación tiene que reside en el legado operativo o en la web basada entorno ebusiness. El modelo de datos se usa como punto de referencia para determinar cuál es la mejor información En otras palabras, el arquitecto de datos comienza con los datos modelo y pregunta qué datos están a la mano que mejor cumple con los requisitos de datos identificado en el modelo de datos. Se entiende que el ajuste será menos que perfecto.
En algunos casos, no habrá datos en el entorno de sistemas existente o el entorno de ebusiness basado en la web que ejemplifica los datos en los datos modelo. En otros casos, muchas fuentes de datos en el entorno de sistemas existente aportar datos a los sistemas de registro, cada uno bajo diferentes circunstancias. La "mejor" fuente de datos o datos existentes encontrados en el ebusiness basado en la web el medio ambiente está determinado por los siguientes criterios:
¿Qué datos en los sistemas existentes o el entorno de ebusiness basado en la web es el más completo?
¿Qué datos en los sistemas existentes o el entorno de ebusiness basado en la web es el más oportuno?
¿Qué datos en los sistemas existentes o el entorno de ebusiness basado en la web es el más exacto?
¿Qué datos en los sistemas existentes o en el entorno de ebusiness basado en la web se ajusta más a la estructura del modelo de datos? En términos de ¿llaves? En términos de ¿atributos?
Usando el modelo de datos y los criterios descritos aquí, el analista define el sistema de registro. El sistema de registro se convierte en la definición de la fuente datos para el entorno del almacén de datos. Una vez que esto está definido, el diseñador entonces pregunta cuáles son los desafíos tecnológicos para llevar los datos del sistema de registro en el almacén de datos. Una breve lista de los desafíos tecnológicos incluye el seguimiento:
Un cambio en DBMS. El sistema de registro está en un DBMS, y los datos el almacén está en otro DBMS.
Un cambio en los sistemas operativos. El sistema de registro está en un operativo sistema, y el almacén de datos está en otro sistema operativo, la necesidad de combinar datos de diferentes DBMS y sistemas operativos. Los sistemas de registro abarcan más de un DBMS y / o sistema operativo.
Los datos del sistema de registro se deben extraer de múltiples DBMS y múltiples sistemas operativos y deben fusionarse de una manera significativa.
La captura de datos basados en web en los registros web. Una vez capturado, cómo ¿Pueden liberarse los datos para su uso dentro del almacén de datos?
Un cambio en los formatos de datos básicos. Los datos en un ambiente se almacenan en ASCII, y los datos en el almacén de datos se almacenan en EBCDIC, y así sucesivamente.
