magallanes nahuel - bi aplicada_en la gestión de producción.pdf

Inteligencia de Negocio aplicada

en la Gestión de Producción.

Córdoba, 21 de Junio de 2012.

Quiero agradecer enormemente la gentileza que tuvo el Sr. Juan Manuel Molla por abrir las puertas

de la organización de la cual él forma parte, para permitir desarrollar este trabajo de grado en las

instalaciones de Magneti Marelli. De no haber tenido su apoyo y su confianza, este proyecto no se

habría podido realizar. Muchas gracias Juan Manuel.

Se hace un agradecimiento muy especial al Ing. Mariano Garcia Mattio, por haber compartido sus

experiencias y conocimientos a lo largo del cursado de la carrera de Ingeniería. Valoro ampliamente

su aporte realizado y la dedicación que tuvo en los años que fue mi profesor. Muchas Gracias

Mariano.

También quiero agradecer a mi colega y amigo, compañero de aventuras universitarias, al Ing

Ricardo Dario Bernabeu, por aceptar ser el tutor de esta Tesis y por haber colaborado ampliamente

en la supervisión del trabajo. Su participación fue de gran importancia por brindar un análisis

crítico muy completo y por haber aportado sus experiencias que, sin lugar a dudas, fueron muy

provechosas para el proyecto. Muchas Gracias Dario.

Este trabajo está dedicado a mi familia y amigos, más particularmente a cada uno de mis abuelos,

Raúl Argentino Magallanes, Amelia Martínez Luque, Ricardo Víctor Udovicich y Nelbia Filomena

Margarita Baudino. A mis padres, Raúl Argentino Magallanes y Alicia del Valle Udovicich. A mis

hermanas Lorena Beatriz Magallanes Udovicich y Mariana Loreta Magallanes Udovicich. A la

familia Molla-Autelli. A la familia Villacé-Magallanes. A la familia Portela.

DECLARACIÓN DE LOS DERECHOS DE AUTOR

Todos los derechos de propiedad intelectual son del autor. Se autoriza la publicación de

este documento con fines didácticos.

TECNOMAG, el logotipo de TECNOMAG, Adalia y el logotipo de Adalia, son marcas

comerciales registradas de TECNOMAG I&D® en Argentina.

Todos los nombres comerciales que aparecen en este documento son propiedad de sus

respectivos propietarios.

MAGALLANES UDOVICICH, Ricardo Nahuel.

Inteligencia de Negocio aplicada en la Gestión de Producción.

Ingeniería en Sistemas - Instituto Universitario Aeronáutico.

Todos los derechos de propiedad intelectual son del autor. Se autoriza la publicación de este documento con

fines didácticos. Magallanes Udovicich Ricardo Nahuel ©2012.

pág. 5

ÍNDICE






pág. 6

ÍNDICE ......................................................................................................................................... 5

PRÓLOGO .................................................................................................................................... 8

RESUMEN .................................................................................................................................. 10

INTRODUCCIÓN ...................................................................................................................... 12

Título del proyecto .................................................................................................................. 13

Introducción ............................................................................................................................ 13

Destinatario ............................................................................................................................. 14

Situación problemática ............................................................................................................ 15

Problema ................................................................................................................................. 16

Objeto de estudio ..................................................................................................................... 17

Campo de acción ..................................................................................................................... 18

Objetivos ................................................................................................................................. 18

Justificación de la propuesta ................................................................................................... 19

Delimitación del proyecto ....................................................................................................... 20

Beneficios esperados ............................................................................................................... 21

Aporte teórico .......................................................................................................................... 23

Aporte práctico ........................................................................................................................ 23

Métodos y medios de ingeniería .............................................................................................. 23

MARCO CONTEXTUAL .......................................................................................................... 25

Entorno del Objeto de Estudio ................................................................................................ 26

Relación tesista y Objeto de estudio. ...................................................................................... 27

Análisis de problemas observados. ......................................................................................... 29

MARCO TEÓRICO .................................................................................................................... 31

Marco Teórico del Objeto de Estudio ..................................................................................... 32

Software Open Source ......................................................................................................... 32

Business Intelligence o Inteligencia de Negocio. ................................................................ 33

Beneficios de las Soluciones BI: ......................................................................................... 36

Cuadro de Mando Integral ................................................................................................... 37

Sistemas de Soporte a la Decisión (DSS) ............................................................................ 37

Sistemas de Información Ejecutiva (EIS) ........................................................................... 38

Data Warehouse .................................................................................................................. 38

Características ..................................................................................................................... 39

Ventajas ............................................................................................................................... 39

Data Marts ........................................................................................................................... 40






pág. 7

Metodología Hefesto ........................................................................................................... 47

Data Mining ........................................................................................................................ 54

MODELO TEÓRICO ................................................................................................................. 59

Introducción ............................................................................................................................ 60

Programación de actividades ................................................................................................... 61

Requerimientos funcionales del sistema ................................................................................. 62

Requerimientos no funcionales del sistema ............................................................................ 64

Arquitectura Lógica............................................................................................................. 65

Infraestructura requerida ..................................................................................................... 66

Selección de la Tecnología .................................................................................................. 68

Diseño del modelo ................................................................................................................... 70

Análisis de requerimiento .................................................................................................... 70

Análisis de los OLTP. ......................................................................................................... 74

Modelo lógico del Data Warehouse .................................................................................... 86

Procesos ETL ...................................................................................................................... 94

Creación de cubos multidimensionales ................................................................................. 108

CONCRECIÓN DEL MODELO .............................................................................................. 116

Implementación: .................................................................................................................... 117

Lenguajes de Programación .............................................................................................. 117

Arquitectura y componentes .............................................................................................. 122

Esquema de directorios y artefactos .................................................................................. 122

Prueba General del Sistema................................................................................................... 162

Análisis de resultados: ........................................................................................................... 191

Experiencias Alcanzadas ....................................................................................................... 199

Puesta en Marcha .................................................................................................................. 200

CONCLUSIONES .................................................................................................................... 203

REFERENCIA BIBLIOGRÁFICA .......................................................................................... 208






pág. 8

PRÓLOGO






pág. 9

Este trabajo de tesis describe el estudio de campo de una solución Business Intelligence

aplicado a una organización piloto donde se realiza la implementación de un Data

Warehouse con el objetivo de resolver los inconvenientes encontrados en la empresa en

cuestión.

El mismo está dividido en cuatro partes fundamentales más una introducción. En la

parte inicial, la introducción, el lector podrá tomar contacto con la organización donde

se realiza el estudio, el problema identificado y los objetivos establecidos. En adelante,

las siguientes partes contienen el desarrollo de la tesis propiamente dicha.

Los cuatro capítulos fundamentales son: El Marco Contextual, que incluye el entorno

del objeto de estudio, la relación del tesista con el objeto de estudio y el análisis de los

problemas observados. En esta sección el lector podrá tomar contacto con el problema y

la situación en la que se encuentra la organización; A continuación, se encuentra el

Marco Teórico que contiene el marco del objeto de estudio. Allí se abordaran todos los

temas y conceptos que son necesarios conocer para comprender el funcionamiento

general del sistema y del Data Warehouse. Luego esta el Modelo Teórico. Esta es la

sección dónde se recaban los requerimientos funcionales y no funcionales del sistema,

se establece cual será la arquitectura lógica y la infraestructura utilizada y, finalmente,

se definen los componentes necesarios para la implementación. Por último, arribamos a

la sección Concreción del Modelo. Aquí se describe cómo se realizó la implementación

del sistema, cuáles fueron las pruebas realizadas y los resultados obtenidos. Más

adelante, se describen las experiencias alcanzadas con el empleo de la herramienta y se

concluye la etapa con la puesta en marcha del sistema propuesto.

Se pretendió hacer que el trabajo resulte muy completo, detallado y sobre todo

informativo. Se espera que el lector lo encuentre muy ameno y atienda sus inquietudes

lo mejor posible.






pág. 10

RESUMEN






pág. 11

Magneti Marelli es una empresa Pyme radicada en ciudad Córdoba Capital que se

dedica a la fabricación de caños de escape. La Gerencia General, encabezada por Juan

Manuel Mollá, se contactó en un primer momento con la intención de que se realice un

estudio de campo para diagnosticar los problemas presentes y proponer una solución

destinada a mejorar el sistema de información que poseía hasta ese momento.

Del estudio realizado surgió que la información que se recolectaba en la organización

finalmente era registrada sobre planillas papel. Esta situación presentaba un gran

impedimento a la hora de obtener informes confiables a partir de los datos disponibles.

Por otra parte, la información generada a partir de las planillas, era calculada

manualmente por el personal administrativo, lo que generaba un grado de incertidumbre

importante y una demora considerable en las decisiones estratégicas.

Consecuentemente, el proceso de toma de decisión de la organización se veía

drásticamente afectado.

En aquel momento, se propuso aplicar una Solución de Negocio que permita almacenar

y procesar la información digitalmente para facilitar su posterior análisis y, con ello,

mejorar la gestión de los procesos productivos en la empresa. Esta solución iba a estar

soportada sobre una plataforma de uso libre disponible en el mercado. Se decidió

utilizar para ello la solución Pentaho BI.

Para el diseño y la implementación de esta solución se trabajó en base a los pasos

propuestos por la Metodología Hefesto, desarrollada por Ing. Bernabeu Ricardo Dario,

la cual permitió guiar el trabajo pasando por cuatro procesos fundamentales: el análisis

de los requerimientos, el análisis de los OLTP, la construcción del modelo lógico Data

Warehouse y la definición de los procesos ETL.

Como resultado de este proyecto se desarrolló el Sistema Adalia registrado bajo la

marca Tecnomag I&D®. Este programa es una solución de inteligencia de negocio que

está separado en dos partes: la carga y almacenamiento de la información obtenida de

los procesos de producción y, por otro lado, el panel de control para el análisis histórico

de la información destinada a asistir las decisiones gerenciales.

En base a la experiencia alcanzada en esta tesis se pudo exponer el mejoramiento

obtenido con el tratamiento sistematizado de la información dentro de la empresa piloto

y, a su vez, quedaron demostradas las ventajas que poseen las herramientas descriptas

en este trabajo, para ser aplicadas en empresas PyMes.






pág. 12

INTRODUCCIÓN






pág. 13

Título del proyecto

“Inteligencia de Negocio aplicada en la Gestión de Producción”.

Introducción

Con frecuencia sucede en las empresas que el volumen de información generada

diariamente crece de manera drástica, al mismo tiempo en el que se incrementan las

variables que intervienen en la actividad desarrollada. Esta situación provoca la

necesidad de procesar sistemáticamente la información para facilitar la interpretación de

las variables que intervienen en el proceso de toma de decisión empresarial. En ese

momento, se torna imprescindible que la organización emplee diversos recursos en la

búsqueda de una solución que permita atender esta necesidad.

La principal dificultad al momento de buscar una herramienta adecuada es la

imposibilidad de encontrar rápidamente una solución que resuelva el problema de

manera acabada. Esto genera como resultado que ciertas organizaciones opten por

adquirir soluciones informáticas no orientadas a los negocios que, lejos de correjir el

problema, complican aún más la situación que desean mejorar.

Este problema se presenta principalmente por tres aspectos principales: En primer lugar,

el elevado costo de inversión requerido para implementar cualquier solución candidata

que, muchas veces, supera las expectativas del grupo gerencial. En segundo lugar es

importante destacar que todas las soluciones son complejas por lo que el tiempo

requerido para la evaluación de cada una de ellas es generalmente insuficiente. Por

último, como el costo y el esfuerzo necesario para evaluar cada una de las herramientas

son demasiado grandes, en muchos casos es preferible analizar los resultados de alguna

implementación anterior antes de iniciar un estudio completo por parte de la misma

empresa. A veces, realizar esto no es posible puesto que no existen antecedentes de

público conocimiento que validen o verifiquen previamente una implementación de este

tipo.

Ante esta situación, las organizaciones pequeñas y medianas rara vez llegan a utilizar

soluciones de Inteligencia de Negocio para asistir la toma de decisión gerencial,

característica fundamental en este tipo de soluciones.

El objetivo del proyecto es desarrollar dentro de una empresa piloto una solución de

Inteligencia de Negocio aplicado a la gestión de producción, utilizando para esto una

plataforma de uso libre disponible en el mercado.

La organización que participa en calidad de Empresa Piloto es “Magneti Marelli

Conjuntos de Escape S.A.”. Con la voluntad de Juan Manuel Mollá, Gerente General de

Planta, se tuvo la oportunidad de ingresar a la empresa para realizar el estudio y

desarrollo de una plataforma mútuamente beneficiosa, que permitió alcanzar el objetivo






pág. 14

pretendido para esta tesis y, al mismo tiempo, le brindó a la organización la posibilidad

de explotar los beneficios obtenidos en este trabajo.

El proyecto se originó a partir de una charla informal mantenida con Juan Manuel

Mollá, a mediados del año 2009. En aquel momento, el personal gerencial tenía la

necesidad de contar con una herramienta de gestión que presente información oportuna

para la toma de decisión empresarial. Se indagó respecto del tipo de datos que se

requerían, el grado de detalle y la frecuencia con la que se la debía consultar la

información y, luego de analizar las características del problema, se propuso la

implementación de un sistema integrado para el almacenamiento y procesamiento de los

datos, junto a la construcción de un panel de control para el análisis de los indicadores

que se obtendrían del sistema.

La motivación para comenzar el proyecto fue la oportunidad de realizar el desarrollo de

un Sistema de Inteligencia de Negocio aplicado en un problema real. El desarrollo

incluyó, por un lado, la construcción de un almacén de datos que permite el análisis de

la información de manera sistemática, pasando por las etapas de definición, diseño y

construcción incluidas en el proceso de Data Warehousing estudiado (proceso de

desarrollo constructivo de un Data Warehouse), pudiendo aportar a la organización una

solución concreta a su problema. Por otra parte, se tuvo la posibilidad de abordar el

campo de estudio referido a la Minería de Datos, aprovechando los datos que se

obtendrían a partir de este sistema para enriquecer, de esta forma, el trabajo de grado.

Destinatario

“Magneti Marelli Conjuntos de Escape S.A.”

La empresa destinataria de este proyecto es “Magneti Marelli Conjuntos de Escape

S.A.” cuya principal actividad es, como su razón social lo sugiere, la fabricación de

caños de escape para automóviles. La misma se encuentra físicamente ubicada en la

Ciudad de Córdoba a metros del acceso sur de la circunvalación, sobre la avenida Vélez

Sarsfield al 4500.






pág. 15

Situación problemática

Magneti Marelli es una empresa multinacional de autopartes que, desde hace unos años,

ha radicado una planta industrial en Córdoba para fabricar y comercializar sus productos

en el mercado local suministrándolos a diversas terminales automovilísticas de la

región.

Debido al continuo crecimiento de la actividad que la organización tuvo en los últimos

años, la alta Gerencia detectó dificultades en el seguimiento y control de la producción.

Por un lado, habían identificado que la información que adquirían de su Sistema de

Información no poseía el grado de detalle suficiente que permitiera tomar decisiones

que afecten positivamente el proceso productivo con el fin de mejorar el rendimiento

general de la organización. Por otro lado surgió, de las entrevistas realizadas, la

necesidad de conocer con un mayor nivel de detalle los valores diarios de producción

como, así también, la de analizar datos históricos para poder generar y supervisar planes

de mejora más certeros y predecir posibles desviaciones.

Por esta razón, se encomendó la tarea de analizar, diagnosticar y proponer una solución

informática que pueda implementarse en un plazo previsible para complementar el

sistema de gestión de la organización.

Se inició entonces el relevamiento para estudiar los principales procesos productivos de

la empresa y se profundizó en el análisis del sistema de información que tenían, con la

intención de evaluar el procesamiento que se realizaba sobre los datos hasta ese

momento. Para ello se realizaron diversas actividades: visitas y recorridos por el interior

de la fábrica; se recopilaron documentos, entre ellos, las planillas de declaración de

producción; se llevaron a cabo entrevistas a los principales responsables en el proceso

de toma de decisión, el gerente de producción, el gerente de calidad y el gerente general

de Magneti Marelli.

A partir del trabajo de relevamiento se detectó que los empleados de planta trabajaban

en tres turnos. Todos ellos operan la maquinaria de forma individual y realizan un único

proceso por vez dentro de la línea de fabricación al cuál fueron asignados. Al completar

la jornada laboral, los empleados deben llenar una planilla donde dejan asentadas tanto

las horas de trabajo realizadas y la producción alcanzada, junto a otros datos adicionales

como ser: los problemas de fabricación o detenciones inesperadas en la línea de

producción, siempre y cuando éstos existan. Estas “declaraciones de producción” eran

utilizadas posteriormente para permitir realizar seguimientos tanto de los empleados

como de los procesos. A partir de la información registrada se podía consultar,

adicionalmente, el presentismo de los trabajadores, las horas trabajadas, las piezas

fabricadas y el rendimiento individual de fabricación alcanzado por cada empleado.

En algunos casos el gerente de producción podía tomar ciertas decisiones estratégicas

basándose en la información recabada, como por ejemplo, el cambio de un proceso, la

modificación de un parámetro o la programación de la rotación de personal a fin de






pág. 16

mejorar el rendimiento general de la organización. Además, era posible obtener datos

mensuales de la producción, las horas totales de fabricación y las cantidades totales de

piezas fabricadas utilizados para cumplimentar diversos procedimientos

administrativos.

Para obtener todos estos informes, una persona debía revisar personalmente cada

planilla involucrada en el período de tiempo requerido para el análisis y calcular

manualmente todos los valores de interés. De la misma manera se operaba para obtener

los volúmenes de fabricación, el total de horas de parada de máquina, la cantidad de

piezas totales defectuosas y el rendimiento general de la organización. Estos informes

eran utilizados posteriormente para respaldar las decisiones gerenciales a mediano y

largo plazo.

En muchas ocasiones, esto se tornaba impráctico por la cantidad de planillas que se

encontraban afectadas, lo que provocaba que los indicadores de gestión fueran muy

complicados de obtener y lentos de calcular. Finalmente, estos valores tampoco resultan

ser suficientemente confiables por haber sido obtenidos con métodos manuales falibles

a los errores u omisiones por parte de los operarios.

Hasta aquí se había detectado cuál era la necesidad, cuál la información relevante y se

conocía un procedimiento para recopilar los datos. A partir del análisis realizado, se

pudo comprender que los problemas de carencia de información en los altos mandos de

la empresa, se debían a un inconveniente ocurrido en alguna etapa intermedia entre la

recopilación de los datos obtenidos de cada proceso de fabricación y la instancia final

para su consulta por parte de los gerentes. En definitiva, el problema se producía debido

a una selección inadecuada del soporte utilizado para almacenar todos estos datos. Al

quedar registrado todo en papel se tornaba muy complicada la gestión de la

información, tanto para accederla como para procesarla.

Problema

Como resultado del proceso de diagnóstico, se pudo identificar que el principal

inconveniente que reportaba Magneti Marelli consistía en la imposibilidad de adquirir

información detallada de cada proceso productivo para identificar las causas que

afectaban negativamente en la productividad, como así también, la imposibilidad de

cuantificar sus niveles de incidencia. La información con la que se contaba por ese

entonces en la empresa no estaba siendo procesada e integrada a una herramienta de

análisis de datos dinámicos, lo que impedía estudiar las variables intervinientes en el

proceso productivo. Mucho más difícil aún, bajo esta situación, era poder realizar una

predicción que les permita ejecutar acciones proactivas y verificar, a lo largo del

tiempo, los resultados obtenidos.






pág. 17

Por esta razón, el principal desafío era encontrar la forma de agilizar el sistema de

gestión de información actual, con el fin de lograr un mayor grado de certidumbre y un

menor tiempo de respuesta en las decisiones estratégicas. Considerando que, con la

ayuda de un sistema informatizado, los gerentes de Magneti Marelli, lograrían una

mayor agilidad en la obtención de los datos relevantes y un mayor nivel de

confiabilidad en la información que tienen hasta el momento. Por esta razón, se propuso

diseñar una solución de inteligencia de negocio adecuada, destinada a dar respuesta a

los principales problemas encontrados en el sistema de información de la organización.

Objeto de estudio

El objeto de estudio del presente proyecto es el sistema de información de los procesos

productivos de Magneti Marelli. Cuyo foco de estudio estuvo centrado en el desarrollo

y la implementación de una solución de Inteligencia de Negocio destinada a brindar un

soporte práctico y confiable para la toma de decisión empresarial.

Para ello, se trabajó en el marco de esta organización piloto, donde se buscó identificar

las falencias e inconvenientes que surgían en el tratamiento de los datos, con el objetivo

de brindar una herramienta eficiente que sea acorde a las necesidades de la empresa y

permita asistir las decisiones gerenciales. Los resultados iniciales obtenidos del proceso

de diagnóstico permitieron establecer los requerimientos principales de la solución

propuesta en Magneti Marelli.

En primer lugar, dado que la información iba a ser empleada para tomar decisiones

críticas en la empresa, la misma, tenía que estar correctamente recopilada y ser

adecuadamente procesada para mantener cierta calidad a la hora de ser entregada. Para

esto, era muy importante que los datos fueran almacenados y mantenidos respetando su

integridad de manera que los informes sean altamente confiables.

En segundo lugar, la información requerida no sólo debía analizarse diariamente, sino

que además debía permitir analizar registros históricos, es por ello que, a priori, se

comenzó a pensar en una solución orientada a resolver a esta necesidad. Se hizo

necesario tener en cuenta, tal como lo solicitó el gerente de planta, el señor Juan M.

Molla, que los datos pudieran ser consultados y estudiados dinámicamente. Por lo que la

solución propuesta, debía permitir el análisis y la indagación de la información en

diferentes niveles de profundidad y desde distintas perspectivas para llegar identificar

los conflictos y sus causalidades.






pág. 18

Campo de acción

Una vez detectadas las necesidades de la organización y definidos los requerimientos

para la solución a desarrollar, se estableció el campo de acción de la siguiente manera:

a) Guiar el trabajo con la metodología Hefesto.

b) Implementar un Sistema de Inteligencia de Negocio.

c) Realizar un estudio de Data Mining sobre los datos obtenidos.

La solución de negocio planteada se comenzó a diseñar a partir de la detección de las

necesidades propias del cliente. El primer paso fue identificar, en detalle, qué

información era requerida y cuál era su frecuencia de uso. Luego de ello, se continuó

con las etapas descriptas en la Metodología Hefesto, que permitió desglosar el diseño en

cuatro procesos fundamentales: el Análisis de requerimientos, el Análisis de los OLTP

(OnLine Transaction Processing), la construcción del Modelo Lógico del Data

Warehouse, y la definición de los procesos ETL (Extract, Transform, Load).

Finalizado el diseño y la implementación del nuevo Almacén de Datos, se estuvo en

condiciones de diseñar un Panel de Control preliminar, para finalmente personalizarlo

en función de la comodidad y facilidad de uso del cliente. Desde la pantalla, el usuario

podrá acceder a los indicadores de gestión y a los gráficos estadísticos más importantes,

permitiéndole cierta interacción para obtener algún detalle deseado.

Una vez construida la solución y de manera previa a la implementación definitiva, se

realizaron distintas pruebas a la plataforma con el objetivo de comprobar la estabilidad

de la herramienta. Luego, se programaron los procesos de transformación y carga para

que trabajen de manera automática contra la base de datos.

Objetivos

El objetivo de este proyecto fue construir para Magneti Marelli una solución Business

Intelligence que les permita, a los empleados de la empresa, acceder de manera

sistemática a la información generada en el área de producción para asistir las

decisiones gerenciales.






pág. 19

Objetivos Específicos

Definir los interrogantes que se desean resolver con la asistencia de la

herramienta de consulta.

Diseñar un Almacen de Datos que permita responder a los interrogantes

planteados.

Diseñar un esquema físico donde quede soportado el Almacen de Datos.

Desarrollar procesos de carga del Almacen de Datos y su programación.

Generar los informes que se desean obtener del sistema de Inteligencia de

Negocio.

Emplear alguna herramienta de Minería de Datos y definir un método práctico

para el análisis masivo de datos.

Construir un modelo de análisis y validarlo.

Utilizar herramientas libres y/o open source para la construcción de la solución

completa.

Justificación de la propuesta

Se tiene la convicción en afirmar que la mejor alternativa para Magneti Marelli es la

implementación de una solución de Inteligencia de Negocio.

En ese sentido, el término “Solución” representa el resultado obtenido de las técnicas

constructivas aplicadas en el Proceso Business Intelligence. Las soluciones BI, permiten

capturar y procesar toda la información destinada a atender una necesidad de negocio

determinada. Además, ofrecen una plataforma de análisis dinámica de datos con la

posibilidad de cambiar las perspectivas de estudio y de personalizar el modo de

presentación de los reportes que se generen. Cuentan también, con una infraestructura

para el tratamiento de los datos relevantes con la que se puede gestionar toda la

información de negocio clave para la gerencia de la empresa.

Con una solución de este tipo, los directivos de la organización pueden seguir

diariamente el estado de los indicadores de proceso, obtener informes periódicos de

producción y analizar la información histórica en la empresa. Esto les permite

identificar, de manera temprana, cuáles son los factores que inciden en pérdida de

materiales y/o de mano de obra para encaminar una acción que posibilite minimizar las

pérdidas con mayor probabilidad de éxito.

Una de las alternativas más interesantes en Inteligencia de Negocio es Pentaho BI que,

al día de hoy, sigue cobrando cada vez más popularidad dentro de la comunidad.

Pentaho BI es una plataforma de código abierto que proporciona una variedad de

herramientas destinadas a la generación y extracción exhaustiva de información, el

análisis OLAP (On-Line Analytical Processing), la construcción y presentación de

cuadros de mando, la integración de datos y la minería de datos, principalmente.






pág. 20

Con la implementación de la solución Pentaho BI en Magneti Marelli, se pretende

averiguar si la herramienta, de uso libre, tiene la madurez y la estabilidad suficiente para

poder brindar, de manera confiable, todos los servicios requeridos en un ambiente

productivo, permitiéndole posicionarse como una buena alternativa en materia de

inteligencia de negocio. Por otro lado, se propone que el proyecto alcance un valor de

inversión razonablemente reducido para incentivar a empresas que, al igual que Magneti

Marelli, no pretenden orientar sus inversiones en tecnologías del software

principalmente y, por lo tanto, deben encontrar que la propuesta sea suficientemente

conveniente como para desarrollar su propio sistema analítico de información.

Delimitación del proyecto

Seguridad

Se dejó de lado cualquier tipo de análisis referido a la seguridad debido a que la

plataforma de Inteligencia de Negocio seleccionada, Pentaho Community Edition, ya

cuenta con un sistema de seguridad integral para la validación de usuarios.

En cuanto a la seguridad de red, se aplicarán las políticas de seguridad que la propia

organización tenga asignadas en sus instalaciones. El único elemento importante en la

implementación del sistema es la necesidad de brindar un servicio Web. Por esta razón,

se solicitó al área de redes que se mantenga disponible el acceso a dicho servicio a

través de algún puerto de red designado.

Rendimiento

Se realizó el análisis de rendimiento a los procesos ETL que estaban en ejecución contra

el Data Warehouse para verificar que su funcionamiento se encuentra dentro de los

parámetros normales de trabajo.

Como la cantidad de transacciones (unidades de trabajo en la base de datos) están muy

por debajo de los que normalmente existen en un DW típico, normalmente millones de

transacciones, fue despreciable e innecesario hacer un análisis de rendimiento de la base

de datos.

Tampoco fue necesario evaluar el rendimiento de la aplicación de consulta de

información por tratarse de una herramienta que tiene como máximo 10 empleados

simultáneos.






pág. 21

Tamaño

El modelo del Data Warehouse inicialmente estuvo definido en un máximo de dos

cubos y no más de 8 dimensiones cada uno. Esta fue una restricción arbitraria que

permitió en los orígenes del proyecto delimitar su tamaño y crecimiento.

Beneficios esperados

La meta principal del desarrollo fue lograr cubrir las necesidades presentes en la

empresa piloto sobre la cual se construye la solución. Por esta razón, es importante que

se destaque cuál es el aporte que brinda el sistema a los usuarios de la misma. A

continuación se listan los beneficios principales que se esperaban obtener con el empleo

de las herramientas de gestión:

Proveer Información Histórica de Producción.

Identificar las causas de las pérdidas de mano de obra y materiales.

Pormenorizar la incidencia de cada causa en el indicador OEE.

Retroalimentar el proceso de toma de decisión.

El OEE (Overall Equipment Effectiveness) es un indicador utilizado en Magneti Marelli

que sirve para medir la eficiencia productiva de la maquinaria industrial y posee los

siguientes niveles de clasificación:

Clasificación del Indicador OEE

Rango Clasificación

OEE < 65% Inaceptable

65% < OEE < 75% Regular

75% < OEE < 85% Aceptable

85% < OEE < 95% Buena

OEE > 95% Excelencia

Es de considerar que, con la utilización de este indicador y la realización de un

minucioso seguimiento de los datos obtenidos, se puede perfeccionar el proceso de toma

de decisión y cuantificar su beneficio siguiendo una metodología de comprobación.

Metodología de Comprobación.






pág. 22

Si la empresa modifica el nivel del indicador OEE de “Regular” a “Aceptable”, será

posible analizar los cambios en el rendimiento y la reducción de los costos entre dos

períodos, de la siguiente manera:

Caso de Ejemplo:

En base a los valores obtenidos de un proceso piloto en un turno tomado al azar y

suponiendo que la situación para 330 piezas fabricadas correctas y 60 piezas fabricadas

defectuosas, pudiera mantenerse contante en el tiempo. (65% < OEE < 75%)

Situación A:

Con la reducción de un 30% en la cantidad de piezas defectuosas, se lograría obtener un

ahorro de 8,33 Horas Mensuales además de la reducción del costo en piezas

defectuosas. (75% < OEE < 85%)

Situación B:

Si pudiéramos reducir el factor que incide sobre la caída de la mano de obra

incrementando un 10% la cantidad de piezas producida (manteniendo la misma relación

“piezas aptas - piezas defectuosas”), se lograría obtener un ahorro de 11,25 Horas

Mensuales.( 75% < OEE < 85%)

Resulta notable que un mismo incremento del indicador OEE puede alcanzarse por un

aumento en la Calidad (Caso A), como por el aumento de la productividad (Caso B).

Situacion A Situacion B Formula

Operador 1 1 1

Tpo Estándar (piezas/hora) 48 48 48

Hs Trabajadas 8,05 8,05 8,05

Prod Estandar 386,4 386,4 386,4 Tpo Estándar * Hs Trabajadas

Prod Total 330 330 363

Prod No OK 60 40 66

Productividad % 85,40 85,40 93,94 (Prod Total)*100/Prod Estandar

Calidad % 81,82 87,88 81,82 ((Prod Total - Prod No OK) / Prod Total)*100

OEE % 69,88 75,05 76,86 Productividad * Calidad / 100

Inaceptable Aceptable Aceptable

Piezas Efectivas Hora 33,54 36,02 36,89 OEE% / 100 * Tpo Estándar

Piezas Efectivas Turno 270 290 297 Piezas Efectivas Hora * Hs Trabajadas

Horas Efectivas por Turno 5,63 6,04 6,19 OEE% / 100 * Hs Trabajadas

Valor Hora 20 20

Ahorro Horas Turno 0,42 0,56 Horas Efectivas Turno (Despues - Antes)

Ahorro Pesos Turno 8,33 11,25 Valor Hora * Ahorro Horas Turno

Dias Laborales 20 20

Ahorro Horas Mensuales 8,33 11,25 Ahorro Horas Turno * Dias Laborales

Ahorro Pesos Mensuales 166,67 225,00 Ahorro Pesos Turno * Dias Laborales






pág. 23

Aporte teórico

El estudio realizado en este trabajo de tesis brinda los aportes teóricos alcanzados

durante el desarrollo de la solución de Inteligencia de Negocio, tanto de los conceptos

empleados en el desarrollo, como de las prácticas utilizadas en la implementación. Por

otra perte, se utilizó en el trabajo una metodología novedosa para guiar el proceso de

construcción del Data Warehouse (Metodología Hefesto), con la que se logró llegar sin

inconvenientes a los objetivos planteados, pudiendo tomarse este trabajo como un caso

de éxito en el empleo de dicha metodología. Finalmente, se presentaron herramientas de

Data Mining para el análisis masivo de datos que podrían ser utilizadas dentro de un

marco teórico para encaminar futuros trabajos de investigación en el campo de minería

de datos.

Aporte práctico

Con el desarrollo de este trabajo de grado Magneti Marelli recibe una solución de

Inteligencia de Negocio completamente desarrollada e implementada para que los

usuarios puedan aprovechar las ventajas y beneficios aportados por este sistema. El

mismo, permite facilitar el acceso a la información y, sobre todo, ayuda a mejorar el

proceso de toma de decisión empresarial.

Métodos y medios de ingeniería

Metodología

El proyecto estuvo guiado con la utilización de la metodología HEFESTO. Versión 2.0.

Metodología HEFESTO.

Esta metodología permite la construcción de un Data Warehouse de forma sencilla,

ordenada y de manera intuitiva. Dada su flexibilidad, la metodología puede ser

embebida en cualquier ciclo de vida mientras se cumplan las condiciones esenciales

para ser implementada. Estas fueron las razones principales por la cuál se la ha

adoptado para guiar este trabajo.






pág. 24

Figura 2.5. Fuente: “HEFESTO: Metodología para la Construcción de un Data Warehouse”

(BERNABEU, 2010).






pág. 25

MARCO CONTEXTUAL






pág. 26

Cada vez más las organizaciones tienen la necesidad de responder rápidamente ante

fluctuaciones de mercado producidas mayormente por cambios sociales y económicos,

tanto locales como globales. Estas situaciones de inestabilidad amenazan cualquier

proyecto empresarial y obliga a las empresas a tomar mayores recaudos para asegurar

sus éxitos ya sea minimizando riesgos potenciales, detectando nuevas oportunidades o

pudiendo avizorar cualquier situación de cambio, sea éste, favorable o desfavorable.

Por otro lado, en la última década, se ha incrementado notablemente el uso de ciertas

aplicaciones destinadas a la gestión del conocimiento a partir del análisis de los datos

históricos dentro de las organizaciones con el objetivo de mejorar la actividad

empresarial. Este tipo de programas entran, hoy en día, dentro del concepto de

“Inteligencia de Negocio” o “Business Intelligence”. Algunas de ellas, se están

popularizando debido a la sorprendente reducción del costo total de inversión requerido

para su empleo que, tiempo atrás, era prohibitivo para cualquier empresa pequeña. Esta

situación se ve aún más favorecida, debido a la aparición de novedosas herramientas de

libre uso y modificación, en materia de Inteligencia de Negocio, que cuentan con la

madurez y confiabilidad suficiente para que sean adoptadas por más usuarios alrededor

del mundo.

A medida que fue creciendo el aporte de las comunidades colaborativas en el desarrollo

de herramientas de Inteligencia de Negocio de Código Abierto (OSBI, por sus siglas en

ingles), mayor número de empresas aplicaron estos softwares en sus propios negocios,

logrando reducir considerablemente el costo de inversión. Así fue que, a mediados del

año 2009, cuando Magneti Marelli se acercó para consultar por un problema existente

en una de sus áreas se pensó inmediatamente, dada las características del problema, en

una implementación de este tipo, que no sólo posibilitara resolver el inconveniente sino

que además, les permitiera como empresa incursionar en mundo de las herramientas

analíticas de datos modernas.

Ésta era una excelente oportunidad para probar una herramienta OSBI en un ambiente

real de trabajo y permitir que alguna otra empresa, de características similares, pueda

guiar su propia implementación a partir de las experiencias demostradas en este

proyecto.

Entorno del Objeto de Estudio

Magneti Marelli es una empresa fabril especializada en construir caños de escape para

automóviles. Sus productos son demandados principalmente por empresas automotrices,

quienes utilizan estos componentes para ensamblar vehículos.

La empresa cuenta con varias líneas de fabricación en las que se produce un modelo de

tubo de escape distinto. En algunos casos, puede incluso construirse más de un modelo

en la misma isla de trabajo. Es interesante mencionar que la línea de fabricación de






pág. 27

Magneti Marelli es semi-automatica. Es decir que, cuenta con una serie de mecanismos

que los operarios comandan por medio de botones para facilitar las tareas y aumentar la

productividad reduciendo, de esta forma, el esfuerzo realizado por el operario. Muchos

recursos se destinan al diseño de estos mecanismos para proteger la seguridad del

operador y mejorar su calidad de trabajo.

El proceso de fabricación comienza con las operaciones de corte y doblado de los tubos

y las chapas. A medida que se avanza sobre la línea de producción se puede observar

cómo el material es conformado y ensamblado hasta llegar al final del proceso dónde se

realiza una última operación para el control de calidad sobre el producto terminado. Una

vez aquí, se llevan a cabo las pruebas de hermeticidad y el control visual sobre el

componente. Si el resultado es positivo, la pieza es marcada como Producto OK y es

destinada a un Rack especial (unidad contenedora para el transporte de piezas). En el

caso contrario el operador debe identificar si la pieza puede ser re-trabajada o si,

desafortunadamente, no es posible recuperarla. Siempre que la misma pueda ser re-

trabajada, ya sea en dicha operación o en alguna de las operaciones anteriores, se la

marca con una fibra de color especial, indicando la zona donde se encuentra el

problema. De esta manera la pieza regresa a un punto anterior de la línea de fabricación

para ser recuperada. Sin embargo, si el componente defectuoso no puede ser re-

trabajado es marcado como una pieza KO (No-OK o también llamado, pieza de Scrap),

y es depositado en un rack especial de piezas para reciclar.

Al finalizar la jornada laboral, cada operario, debe completar una planilla con el detalle

de su producción. Entre los datos de registros más importantes se encuentran: la hora de

ingreso y de cierre; la cantidad total de Piezas OK y Scrap fabricadas; los tiempos de

paradas no programadas consumidos. Todos estos tiempos registrados están basados en

la estimación personal de los operarios, ya que no tienen un método de medición precio.

Relación tesista y Objeto de estudio.

Con el objetivo de afianzar el compromiso entre ambas partes se convino enmarcar este

trabajo dentro de una relación de tipo cliente/proveedor, donde el tesista quedó como

director responsable por el desarrollo del software para todo el ciclo de vida del

proyecto.

El tesista aplicó los conocimientos adquiridos en el cursado de la carrera Ingeniería en

Sistemas para estudiar en profundidad e implementar completamente una solución

OSBI en la Empresa Piloto, de manera de poder evaluar el comportamiento de la

solución en un ambiente real y verificar si es posible adaptarla a las necesidades de la

organización.

Es de esperar que si el proyecto es exitoso, la organización continúe utilizando la

solución por mucho tiempo más, incluso después de finalizado el proyecto inicial, y es






pág. 28

posible que requiera desarrollar e incorporar nuevas características que se ajusten a las

necesidades latentes de la entidad. Con lo cual, también se hace presente la necesidad de

ampliar el alcance del proyecto paulatinamente. De una manera u otra, cuando se

comienza un proyecto de esta envergadura se debe tomar conciencia, desde el principio,

que si se logra alcanzar el nivel de resultados esperado muy probablemente se deba

pensar en la continuidad del proceso de desarrollo de dichas herramientas. Algo que no

es muy frecuentemente contemplado por los altos mandos de las organizaciones. Por

esta razón, lo más importante a tener en cuenta es el compromiso y la decisión que hay

que tener para invertir en el desarrollo del software, sabiendo que con el tiempo se

volverán cada vez más esenciales los recursos necesarios para continuar el proyecto.

Al revisar los requerimientos que debe cumplir el sistema, es posible pensar en el

desarrollo de una solución de Inteligencia de Negocio. Estas soluciones tienen como

objetivo el tratamiento de la información disponible en la organización obtenida a partir

de algún sistema específico, una aplicación ERP, u otro software utilizado dentro de la

empresa, con el fin de responder a los interrogantes que no son atendidos por el propio

sistema de información y permitir, a partir de ahí, encontrar nuevo conocimiento que

facilite la toma de decisión.

Las soluciones de Inteligencia de Negocio fueron históricamente muy costosas, por

tener gran complejidad y mayor tamaño que el resto de las alternativas existentes. Pero

esto fue cambiando con la aparición de algunas soluciones de uso libre. Hoy en día,

están disponibles en Internet para que cualquier persona pueda descargarlas y utilizarlas

en sus propios negocios. Por esta razón se utilizaron algunas de las herramientas libres

mencionadas para construirle a Magneti Marelli la Solución BI de alto nivel sin tener

que recurrir al uso de softwares costosos y difíciles de acoplar a las necesidades de la

propia empresa pudiendo conservar, además, el derecho de modificar o extender la

aplicación, si fuese necesario.

La selección de una herramienta de uso libre para aplicaciones de inteligencia de

negocio presenta el inconveniente que, dada la complejidad y el tamaño de las mismas,

se hace imprescindible que el desarrollador domine el campo de estudio antes de

abordar el problema. El riesgo de fracasar en este tipo de proyectos es potencialmente

mayor cuando no se conocen las limitaciones de cada herramienta empleada. Esto

ocurre con frecuencia debido a que el equipo de implementación nunca termina de

conocer a fondo la tecnología usada incluso después de terminar siquiera la propia

implementación.

Por otro lado, las Soluciones propietarias que compiten con las OSBI son y seguramente

seguirán siendo por más tiempo, inalcanzables para organizaciones medianas y

pequeñas por ser altamente costosas. Esto motiva fundamentalmente a la investigación

de las herramientas libres aplicadas en el campo de Inteligencia de Negocio.






pág. 29

Análisis de problemas observados.

Las herramientas destinadas a brindar información para la toma de decisión empresarial

son, aún hoy, escasamente utilizadas. A pesar de volverse con el tiempo más populares,

surge un factor que afecta negativamente su aceptación y tiene que ver más con la

cultura organizacional de la empresa que con cuestiones técnicas de implementación.

Existe cierta resistencia por parte de los directivos a adquirir nuevas herramientas por la

incertidumbre que ello implica. Esto sucede mayormente en PyMEs jóvenes donde es

posible desarrollar la actividad con el empleo de herramientas analíticas tradicionales

guiadas por la experiencia e intuición de los gerentes de la organización. Sin embargo,

cuando una organización crece aumentan las variables de negocio y, con ello, también

aumenta la complejidad. Llegado este momento, los gerentes tienen la necesidad de

buscar nuevos instrumentos que permitan evaluar el panorama general de la

organización con el objetivo de facilitar la gestión. Esta es la razón que los lleva a

buscar y adquirir herramientas que no sólo permitan asistir las decisiones estratégicas

sino que, además, se ajusten adecuadamente a la cultura organizacional que poseen,

permitan la escalabilidad de la solución (término informático referido al crecimiento del

sistema), mantengan un valor de inversión mínimo (idealmente, igual a cero) y puedan

ser implementadas en el menor tiempo posible (idealmente, en la inmediatez).

Esta situación suele convertirse en una odisea difícil de superar por la sencilla razón que

los obliga a tomar fuertes decisiones en muy corto tiempo, al mismo tiempo que deben

seguir dando soluciones a los problemas que dieron lugar a la búsqueda de la nueva

alternativa.

Para Magneti Marelli, esta necesidad comenzó a manifestarse con la aparición de varios

interrogantes del negocio carecientes de respuestas sólidas para sustentar decisiones

importantes. La necesidad de controlar y mejorar el rendimiento de la organización es

una tarea fundamental y, según venían percibiendo, se estaba volviendo realmente

complicado mejorar los procesos productivos al no contar con el detalle suficientemente

para hacerlo de manera previsible. Habían visto que para poder analizar el

comportamiento los procesos productivos adecuadamente necesitaban más información

de cada proceso y de los parámetros que rigen sus comportamientos.

Desde el inicio, el problema había quedado perfectamente definido por el Gerente de

Planta, quien comentó durante la primera entrevista realizada lo siguiente:

“Es necesario que, con el uso del sistema, determinemos el nivel de calidad y de

productividad alcanzada en un proceso productivo cuando se fabrique un producto

determinado.”…

“En el caso de no alcanzar la máxima calidad, es importante identificar las cantidades

de piezas defectuosas y las causas que produjeron dichos defectos. De la misma manera,

para el caso de la productividad, en el caso de no alcanzar el objetivo de producción y,






pág. 30

con ello, no se logre la máxima productividad, es importante identificar la cantidad de

horas de pérdida de mano de obra y las causas que produjeron dichas pérdidas.”

Toda esta información era adquirida a partir de los datos obtenidos desde las líneas de

producción. Aproximadamente desde un año antes del primer contacto con la Gerencia

de Magneti Marelli, se venían registrando todos los datos en planillas que, de ahora en

más, llamaremos “Declaraciones de Producción”. Dichas declaraciones eran

completadas por los operadores para dejar asentados los detalles de la producción de

manera diaria.

Imaginemos que para la obtención de algún indicador relevante, como puede ser el

rendimiento que tuvo un operario en un día de trabajo, o bien, el rendimiento que se

obtuvo dentro de una celda de producción, u otro indicador similar, era necesario que

una persona se aboque a la tarea de recabar todas las planillas involucradas y calcule

manualmente el valor deseado. Esta tarea debía ser repetida varias veces al cambiar

algunas de las variables o perspectivas de análisis deseado. Asi, por ejemplo, si más

tarde era necesario evaluar el mismo indicador seleccionado pero dentro de otro

proceso, turno, empleado, o incluso de un día diferente de trabajo, había que repetir toda

la operación nuevamente para calcular el nuevo valor. Esto provocaba que el tiempo

invertido en la obtención de los indicadores fuera excesivamente alto para que sea

aplicable en términos prácticos.

De esta manera, el sistema propuesto debía capturar adecuadamente los datos generados

y mantenerlos en un medio de almacenamiento apropiado para permitir, posteriormente,

realizar el tratamiento masivo de datos a travez de un servicio de consulta dinámico,

preciso y confiable. Por tal motivo se evaluó, en la etapa de diseño, la posibilidad de

agregar variables que no habían sido contempladas al inicio del proyecto con la

finalidad de minimizar la aparición de problemas potenciales en el momento de

construir la solucion. Esto permitió tambien atender mejor a las necesidades de los

usuarios finalizada la etapa de implementación.






pág. 31

MARCO TEÓRICO






pág. 32

Marco Teórico del Objeto de Estudio

Software Open Source

El término Open Source, o en castellano código abierto, se emplea para definir a todo

software desarrollado y distribuido libremente. Este tipo de software es licenciado de

forma tal que cualquier persona posee la libertad de adquirir, utilizar y modificar, parte

de la aplicación o su totalidad, si así lo desea.

Un proyecto de implementación de software Open Sorce, generalmente es coordinado

por un grupo de desarrolladores reunidos como una comunidad virtual quienes, además

de contribuir con la construcción de la aplicación, llevan a cabo las tareas de la

distribución y el versionado de la misma. Asimismo, son los responsables de recibir

aquellos aportes ofrecidos por usuarios de todo el mundo, ajenos al proyecto, que

desean compartir sus propias mejoras realizadas al programa. Más tarde, cuando estos

programas alcanzan cierta estabilidad y reúnen nuevas características son publicados

para que toda la comunidad tome provecho de las ventajas alcanzadas en las versiones

siguientes. En definitiva, todos los agentes involucrados sean desarrolladores, usuarios,

u otro tipo de participante, aprovechan la sinergia del trabajo comunitario para obtener

conjuntamente una solución determinada que, de otra manera, no habrían podido

obtener por sí solos.

Otra característica de los proyectos de código abierto, es que persiguen principalmente

el beneficio que se obtiene del empleo de las herramientas construidas, haciendo énfasis

exclusivamente en la parte práctica y técnica. Esta característica los diferencia del

“Software Libre”, que no sólo se focaliza en los aspectos constructivos de un software

sino que pone mayor atención en la libertad y la solidaridad social de sus usuarios.

Es importante mencionar que, aunque una herramienta sea “Open Source” no implica

necesariamente que su implementación sea totalmente gratuita. El hecho de que no

exista la necesidad de pagar una licencia por el uso de un software no incluye que el

trabajo de implementación también lo sea. Por el contrario, en el momento en que se

pone en marcha un proyecto de este tipo surge la necesidad de invertir muchos recursos

en la tarea de personalizar y adaptar la solución elegida a las necesidades de la empresa.

Todas estas actividades siempre tienen un costo significativo y terminan formando parte

del costo total de inversión del proyecto.

Por otro lado, tanto las herramientas Open Source como Software Libre que se pueden

encontrar publicadas en cualquier sitio de distribución oficial de acceso público, no

cuentan con ningún tipo de soporte técnico más que el que se brinda por la propia

comunidad, a menos que se contrate un servicio adicional o se adquiera específicamente

una licencia para ello. Estos aspectos deben ser tenidos muy en cuenta cuando se elige

una solución determinada. Una decisión incorrecta puede provocar una serie de graves

inconvenientes durante el proceso de implementación. Por ejemplo, puede provocar un

incremento sustancial no previsto en el costo de inversión si la empresa selecciona

http://es.wikipedia.org/wiki/Software






pág. 33

inadecuadamente un grupo de soporte poco experimentado o si debe contratar algún

tipo de soporte, de manera repentina, en mitad del trabajo.

Cualquiera sea el caso a la hora de cambiar o implementar un nuevo sistema

informático, sobre todo si el mismo va a estar orientado a la gestión estratégica de la

empresa, es conveniente disponer de un Director de Proyecto ya sea interno o externo.

Éste será el responsable de analizar toda la información necesaria, tanto de la empresa

como de las soluciones existentes en el mercado para poder estudiar adecuadamente

todas las alternativas disponibles y tomar una decisión que contemple los riesgos de

manera de no comprometer el éxito del proyecto.

Aun así, para muchas organizaciones la elección de un programa Open Source o de un

Software Libre puede llegar a ser la mejor alternativa. Con el empleo de algunas de

estas tecnologías, organizaciones pequeñas lograrán resolver sus principales

necesidades a un bajo costo. No obstante, para una correcta implementación es menester

estudiar y asumir todos los costos y riesgos involucrados. Es posible que muchas

PyMEs prefieran, o no tengan otra alternativa, que recurrir al empleo de herramientas de

distribución libre. La razón principal es que el costo de emplear estas herramientas no

tiene incluido el valor de las licencias de los programas y, en general, este es un

elemento restrictivo de dichas tecnologías. Por este motivo, es de suponer que existen

elementos suficientes para afirmar que una solución Business Intelligence de tipo Open

Source puede ser más que atractiva para organizaciones que tienen tamaños y recursos

reducidos.

Business Intelligence o Inteligencia de Negocio.

Para comprender qué es una solución de Inteligencia de Negocios es necesario dominar

cada uno de los conceptos que están involucrados en su definición. Aquí abordaremos

estos temas para aplicarlos posteriormente en el diseño y en la implementación de la

solución que se desarrolla en la investigación.

La primera definición de Business Intelligence presentada, fue extraída de Wikipedia.

Seguramente no será la más amplia ni, quizás, la más completa. Pero nos permitirá

conocer los conceptos básicos necesarios desde una óptica adecuada para dominar la

implementación rápidamente: “Se denomina inteligencia empresarial, inteligencia de

negocios o BI (del inglés Business Intelligence) al conjunto de estrategias y

herramientas enfocadas a la administración y creación de conocimiento mediante el

análisis de datos existentes en una organización o empresa” (WIKIPEDIA. Consultado:

20/12/2009).

El término puede parecer bastante genérico o muy abarcativo, pero es muy concreto

desde el punto de vista de lo que desea alcanzar con ello. Para comprenderlo con

precisión, es necesario repasar primero los conceptos mencionados de manera aislada.

http://es.wikipedia.org/wiki/Idioma_ingl%C3%A9s

http://es.wikipedia.org/wiki/Conocimiento

http://es.wikipedia.org/wiki/Dato

http://es.wikipedia.org/wiki/Organizaci%C3%B3n

http://es.wikipedia.org/wiki/Empresa






pág. 34

El primer elemento mencionado y más importante de conocer es el referido a los datos.

Estos conforman la materia prima de cualquier conocimiento que podamos extraer o

conjeturar a cerca de algo y, por esta razón, es muy importante saber cómo identificarlos

claramente. Los datos son miembros primarios que componen cualquier tipo de

información. Estos describen condiciones, hechos, situaciones o valores pero, por si

solos, son insuficientes para tomar cualquier decisión debido a que no aportan nada

concreto acerca de una situación dada.

“La importancia del dato reside en su capacidad de asociarse dentro de un contexto para

convertirse en información” (GARRILLO et Al, 2008). “Los datos no tienen capacidad

de comunicar un significado y por tanto no pueden afectar el comportamiento de quien

los recibe” (CARRASCO ARROYO, 2006). Para que éstos adopten un significado

concreto y puedan ser utilizados como fuente de información relevante y oportuna

deben ser procesados previamente.

Como vemos, a partir del procesamiento sistemático de los datos se obtienen resultados

útiles que permiten tomar decisiones. El producto del procesamiento de los datos es

llamado Información.

Se puede definir a la Información como el conjunto de datos procesados que adquieren

cierto significado por alcanzar relevancia o propósito dentro de un contexto

determinado. Cualquier información, correctamente utilizada, permite disminuir

considerablemente la incertidumbre dentro del dominio de un problema, y por lo tanto,

tienen un gran valor para quiénes deben tomar decisiones en tal dominio.

Figura 2.1.

Los diferentes procesos que pueden agregar valor a los datos para transformar a éstos en

información son:

Contextualización: se sabe en qué contexto y para qué propósito se generaron.

Categorización: se conocen las unidades de medida que ayudan a interpretarlos.

Cálculo: los datos pueden haber sido procesados matemática o estadísticamente.

Corrección: se han eliminado errores e inconsistencias de los datos.

Condensando: los datos se han podido resumir de forma más concisa

(agregación).

Como vimos en la definición de Business Intelligence, el conocimiento es el valor más

preciado para la toma de decisión y, por consiguiente, debería también serlo para la

empresa.

http://www.monografias.com/trabajos14/nuevmicro/nuevmicro.shtml






pág. 35

Existen múltiples definiciones de conocimiento, desde las clásicas y fundamentales que

describen al conocimiento como: “una creencia cierta y justificada” (MORA

VENEGAS, 2009), a otras más pragmáticas que definen al mismo como: “una mezcla

de experiencias, valores, información y saber hacer que sirve de marco para la

incorporación de nuevas experiencias e información útiles para la acción” (SANCHEZ

AMBRIZ, 2009).

Podemos decir, más precisamente, que: “El conocimiento es un conjunto de saberes

integrado por información, reglas, interpretaciones y conexiones puestas dentro de un

contexto y una experiencia, que han sucedido dentro de una organización, bien de forma

general o personal” (HERNÁNDEZ FERNÁNDEZ, 2003).

“La Gestión del Conocimiento (en inglés Knowledge Management) es un concepto

aplicado en las organizaciones, que pretende transferir el conocimiento y experiencia

existente entre sus miembros, de modo que pueda ser utilizado como un recurso

disponible para otros en la organización” (PÉREZ PÉREZ et Al, 2008).

Usualmente el proceso de Gestión de Conocimiento incluye técnicas para capturar,

organizar y almacenar el conocimiento de los trabajadores, para transformarlo en un

activo intelectual que aporte beneficios y pueda ser compartido fácilmente.

“En la actualidad, las tecnologías de información permiten contar con herramientas que

apoyan la gestión del conocimiento facilitando su recolección y su transferencia,

incrementando la seguridad y simplificando administración sistemática de la

información junto a las demás herramientas que permiten hacer uso de ese

conocimiento”. (RAMO, 2010)

Estamos en condiciones de definir con mayor exactitud el término Inteligencia de

Negocio. Ahora es posible expresar este concepto de la siguiente manera:

Inteligencia de Negocio, se refiere al conjunto de estrategias y herramientas enfocadas a

la administración y creación de conocimiento mediante el análisis de datos existentes en

una organización con el objetivo de respaldar las decisiones empresariales. La

Inteligencia de Negocios es la habilidad para transformar los datos en información y la

información en conocimiento para optimizar, con su aporte, el proceso de toma de

decisión en los negocios. (WIKIPEDIA, 2010).

“Desde un punto de vista más pragmático, y asociándolo directamente con las

tecnologías de la información, podemos definir Business Intelligence como el conjunto

de metodologías, aplicaciones y tecnologías que permiten reunir, depurar y transformar

datos de los sistemas transaccionales e información desestructurada (interna y externa a

la compañía) en información estructurada, para su explotación directa (reporting,

análisis OLAP2 ,etc.) o para su análisis y conversión en conocimiento, dando así

soporte a la toma de decisiones sobre el negocio”. (LUNA POZO, 2010)

http://www.gestiopolis.com/administracion-estrategia/relevancia-y-alcance-de-la-gestion-del-conocimiento.htm#mas-autor

http://es.wikipedia.org/w/index.php?title=Activo_intelectual&action=edit&redlink=1

http://es.wikipedia.org/wiki/Informaci%C3%B3n

http://es.wikipedia.org/wiki/Conocimiento






pág. 36

Beneficios de las Soluciones BI:

“La inteligencia de negocio actúa como un factor estratégico para una empresa u

organización, generando una potencial ventaja competitiva, que es proporcionar

información privilegiada para responder a los problemas de negocio” (AGUIRRE Y

HERNÁNDEZ, 2010). Con su empleo es posible alcanzar mayores éxitos en cualquier

actividad empresarial.

Entre los beneficios más importantes aportados por el BI, se encuentran:

Permite reducir el tiempo que se requiere para recoger y procesar toda la

información relevante para la empresa.

Automatiza la carga y transformación de la información.

Proporciona herramientas de análisis amigables para tomar decisiones.

Permite a los usuarios utilizar tanto reportes e informes previamente diseñados,

e incluso, generarlos de manera dinámica.

Permite acceder y analizar directamente los indicadores claves de la empresa.

Brinda la posibilidad detectar situaciones fuera de lo normal.

Muestra rápidamente cuáles son los factores que inciden en el buen o mal

funcionamiento de la organización.

Permite consultar y analizar los datos de manera sencilla e intuitiva.

En la actualidad, la capacidad para tomar decisiones ágiles y acertadas en los negocios

se ha convertido en una de las claves que permiten a las organizaciones ser exitosas y

permanecer en el tiempo. En otras palabras, se trata de acceder a la información correcta

en un formato apropiado y en un tiempo adecuado para optimizar los procesos internos

de la empresa, por ejemplo: ventas, producción, prestación de servicios, etc. En

resumen, la Inteligencia de Negocios permitirá a una empresa aprovechar sus datos para

lograr un objetivo propio a la organización. Este objetivo podrá ser, por ejemplo,

acelerar su crecimiento, minimizar el riesgo, incrementar la competitividad, automatizar

las tareas, agilizar el análisis de las variables del negocio o identificar problemas críticos

con mayor rapidez.

La Inteligencia de Negocio atiende interrogantes a diferentes niveles organizacionales

para presentar la información adecuada a los tomadores de decisión en función de la

necesidad, el nivel de agregación o el tratamiento particular que ellos requieran. Según

el nivel organizacional en el cual se esté trabajando, la información recibe un

tratamiento diferente y se presenta a los usuarios también de manera distinta.

No obstante, el hecho que los informes puedan ser diferentes según a quien éstos vayan

dirigidos, también comparten ciertas similitudes como son: la claridad y la calidad para

su presentación. Todos estos instrumentos deben respetar, por regla general, ciertos

principios elementales que favorecen la aceptación general, por parte de los usuarios.






pág. 37

Un sistema de BI está conformado, entre otras cosas, por un conjunto de herramientas

administrativas. Estas herramientas, adoptan diferentes características en función de la

necesidad que deban atender y el nivel organizacional en el que se encuentren. Las

mismas, reciben un nombre particular según la posición dentro de la pirámide

organizacional y se clasifican de la siguiente manera:

Figura 2.2. Fuente: http://www.sinnexus.com/images/data_schema.gif.

Cuadro de Mando Integral

El CMI es una herramienta de administración para las empresas que muestra

continuamente el estado de resultados de la compañía y sus empleados definidos en el

plan estratégico. También es una herramienta que ayuda a la compañía a expresar los

objetivos e iniciativas necesarias para cumplir con la estrategia y proporciona, a los

administradores, una visión global de las prestaciones del negocio.

El Cuadro de Mando Integral está orientado al seguimiento de indicadores más que al

análisis minucioso de información. Es muy común que un CMI sea controlado por la

dirección general de una compañía y, por tanto, requiere que los directivos analicen el

mercado y la estrategia para construir un modelo de negocio que refleje las

interrelaciones entre los diferentes componentes de la empresa, es decir, contar con un

plan estratégico previo a generar el modelo.

Sistemas de Soporte a la Decisión (DSS)

Un Sistema de Soporte a la Decisión (DSS) es una herramienta de Business Intelligence

enfocada al análisis de los datos de una organización. Con frecuencia, se suele suponer

que el proceso de análisis de datos masivo es algo sencillo y fácil de conseguir mediante

la utilización de programas genéricos o mediante el empleo de un software ERP1

sofisticado. Sin embargo, estas aplicaciones poseen una serie de informes predefinidos

1 Enterprise Resource Planning es sistema de información gerencial que integra muchas de las prácticas

de los negocios asociadas con las operaciones de producción y gestión de recursos.

http://es.wikipedia.org/wiki/Administraci%C3%B3n_de_empresas

http://es.wikipedia.org/wiki/Plan_estrat%C3%A9gico






pág. 38

para presentar la información resumida pero no permiten, entre otras cosas, profundizar

en los datos, navegar entre ellos o analizarlos desde diferentes perspectivas.

Sistemas de Información Ejecutiva (EIS)

Un Sistema de Información Ejecutiva o Sistema de Información para Ejecutivos es una

herramienta software basada en un DSS que provee a los gerentes de la organización un

acceso sencillo a información interna y externa de la compañía que es relevante para su

negocio. La finalidad principal de esta herramienta es que el ejecutivo tenga a su

disposición un panorama completo e instantáneo del estado de los indicadores que

afectan al negocio para analizar con detalle, aquellos parámetros que no estén

cumpliendo con las expectativas establecidas y corregir el plan de acción.

De forma más pragmática, se puede definir a un EIS como una herramienta informática

que brinda informes, listados y reportes de las diferentes áreas de negocio para facilitar

el monitoreo de la empresa en general o de alguna unidad en particular.

Data Warehouse

Los sistemas de información usados comúnmente para la gestión operativa,

desafortunadamente, suelen presentar una estructura de almacenamiento rígida y poco

práctica para el análisis masivo de datos. Estos sistemas están preparados para el

procesamiento masivo de transacciones, comúnmente conocidos como OLTP

(OnLine Transaction Processing) y esto, no es muy útil en los sistemas de Inteligencia

de Negocio. Para superar esta limitación, la Inteligencia de Negocio se apoya en un

conjunto de técnicas llamadas „Integración de Datos‟, que facilitan la extracción, la

depuración y almacenamiento de los datos con el objetivo de mantenerlos en una nueva

base de datos optimizada para recibir, desde sistemas específicos, consultas analítica en

línea OLAP (On-Line Analytical Processing). Esta nueva base de datos permite dar

soporte de manera eficiente a la toma de decisión empresarial y recibe el nombre de

Data Warehouse.

“Un Data Warehouse es un almacén o repositorio de datos categorizados, que concentra

un gran volumen de información de interés para toda una organización, la cual se

distribuye por medio de diversas herramientas de consulta y de creación de informes

orientadas a la toma de decisiones. El objetivo del Data Warehouse (DW) es agrupar los

datos con el propósito de facilitar su posterior análisis, de forma que sean fáciles de

acceder y, posteriormente, analizar dicha información” (MESTIZO GUTIÉRREZ et Al,

2008). A este tipo de datos se los conoce como informativos. Los sistemas que realizan






pág. 39

el procesamiento analítico sobre datos informativos, se denominan OLAP (Online

Analytical Processing).

Existen muchas definiciones de Data Warehouse aportadas por de distintos autores.

Quizás la más famosa fue desarrollada por Inmon en 1992: “Un Data Warehouse es una

colección de datos orientados a temas, integrados, no-volátiles y variante en el tiempo,

organizados para soportar necesidades empresariales”. (INMON, 1992 citado por PEÑA

RIVERA et Al, 2005:4).

Características

Orientada al negocio: Los datos en la base de datos están organizados de

manera que todos los elementos de datos relativos un mismo evento estén

agrupados.

Integrada: La base de datos contiene todos los datos de los distintos sistemas

operacionales de la organización en un mismo almacén centralizado. Esta

integración permite compartir una misma codificación para los datos y resolver

los problemas relacionados con las fuentes de datos múltiples, entre otros

aspectos.

Variante en el tiempo: Los cambios producidos en los datos a lo largo del

tiempo quedan todos registrados para que los informes históricos reflejen esas

variaciones.

No volátil: La información no se modifica ni se elimina. Una vez almacenado el

dato, éste se convierte en información de sólo lectura y se mantiene para futuras

consultas.

Ventajas

Transforma datos orientados a las aplicaciones en información orientada a la

toma de decisiones.

Integra y consolida diferentes fuentes de datos (internas y/o externas), de

departamentos empresariales desagrupados, en una única plataforma sólida y

centralizada.

Brinda la capacidad de explorar las diferentes áreas de trabajo y de analizarlas

de manera inmediata.

Permite reaccionar rápidamente a los cambios.

Aumenta la competitividad de la empresa frente al mercado.

Reduce la generación excesiva de información. Sólo utiliza los datos requeridos

y desecha cualquier otra información innecesaria.

Mejora la entrega de información, es decir, asegura que la misma sea completa,

correcta, consistente, oportuna y fácilmente accesible.

Logra un impacto positivo en la toma de decisión empresarial por aprovechar al

máximo el potencial de los recursos disponibles.






pág. 40

Desventajas

Requiere una gran inversión debido a que su construcción no es una tarea

sencilla. La implementación requiere contemplar gran cantidad de aspectos que

van desde la adquisición de la información, el tratamiento de los datos, la

construcción de las consultas analíticas, hasta la capacitación de los usuarios.

Su implementación esta generalmente afectada por una natural resistencia al

cambio por parte de los usuarios.

Los beneficios alcanzados con la utilización de un almacén de datos son

apreciados recién en el mediano y largo plazo.

Como deriva del punto anterior, no todos los usuarios confiarán en la

información provista por el DW en una primera instancia. Pero si lo irán

haciendo a medida que comprueben su efectividad y sus beneficios.

Si se incluyen datos confidenciales tanto propios, como de clientes o

proveedores al depósito. Se estará atentando contra la privacidad de los

afectados, si no se controla adecuadamente el acceso a la información.

Subestimación de los recursos necesarios para la captura, carga y

almacenamiento de los datos.

Subestimación del esfuerzo necesario para su diseño y creación.

Incremento continuo de los requerimientos del usuario.

Subestimación de los beneficios obtenidos con la correcta utilización del DW y

de las herramientas de BI en general.

Data Marts

Por último, hay que mencionar la existencia de los Data Marts (Mercado de Datos).

Estos son una versión más reducida de un Data Warehouse. Frecuentemente, contienen

información específica de algún departamento de la empresa como: marketing, finanzas

o mantenimiento de la red. Podría verse al Data Mart, como un subconjunto del Data

Warehouse cuya finalidad es mantener consistencia en las prácticas de administración

de datos corporativos para mejorar la seguridad y la integridad de la información que se

está utilizando. (MONOGRAFIAS, 2010)

Tal como se puede apreciar en el libro “HEFESTO: Metodología para la Construcción

de un Data Warehouse” (BERNABEU, 2010) en el apartado Arquitectura del Data

Warehousing, un Data Warehouse tiene la siguiente arquitectura lógica:






pág. 41


(BERNABEU, 2010).

Para comprender íntegramente la finalidad del Data Warehouse es importante conocer

cómo es el proceso empleado para su construcción. Este proceso es conocido como Data

Warehousing. El mismo comienza con la recopilación y tratamiento de grandes

volúmenes de datos disponibles en sistema de información de la organización. El

proceso consiste en la extracción de una colección completa de datos para colocarlos en

el almacén de manera una manera organizada. El encargado de extraer los datos

depurarlos, transformarlos y finalmente almacenarlos dentro del DW es el proceso de

Extracción, Transformación y Carga, también conocido como Proceso ETL.

En general, los datos son extraídos desde los sistemas de información operacionales de

la empresa. Aunque también pueden incluirse otras fuentes de datos tales como archivos

Excel, archivos planos, correos electrónicos, que comúnmente encontramos en el

ámbito organizacional de cualquier empresa.

Extracción: obtención de información de las distintas fuentes, tanto internas como

externas.

Transformación: filtrado, limpieza, depuración y agrupación de la información.

Carga: organización y actualización de los datos y sus metadatos en la base de datos.

Metadatos

Uno de los componentes más importantes de la arquitectura de un almacén de datos son

los metadatos. Comúnmente, se definen como "datos acerca de los datos" (SANZ

RODRÍGUEZ, 2010). Estos, describen el sentido de los datos, la estructura de

almacenamiento y la manera en que se relacionan.

http://es.wikipedia.org/wiki/Metadato






pág. 42

Los metadatos son registros que documentan información acerca de la morfología del

esquema utilizado para contener los datos dentro del sistema. Por ejemplo, reúnen

información acerca de cuáles son tablas existen en una base de datos, las columnas que

posee cada una de ellas y el tipo de datos almacenan, entre otras cosas. Estos registros

permiten manipular mejor los datos de la empresa sin la necesidad de conocer, de

antemano, el tipo de dato y la forma en el que están almacenados en la base de datos.

Los datos son de interés para el usuario final, mientras que el metadato cobra interés

para los programas que tienen que manejar estos datos. Sin embargo, el rol que cumple

el metadato en un entorno de almacén de datos es muy diferente al rol que cumple en

los ambientes operacionales. En el ámbito de los Data Warehouse el metadato juega un

papel fundamental, su función consiste en recoger todas las definiciones de la

organización y el significado de los datos dentro del almacén de datos. Estos deben

contener toda la información concerniente a: Tablas; Columnas de tablas; Relaciones

entre tablas; Jerarquías y Dimensiones de datos; Entidades y Relaciones. (WIKIPEDIA,

2010).

Herramientas OLAP

Toda la información que se procesa y se almacena en el Data Warehouse finalmente es

consultada mediante herramientas analíticas de datos especializadas para responder

eficientemente a las peticiones generadas en línea. Estos sistemas son los denominados

OLAP, por sus siglas de On-Line Analytical Processing. Aunque existen otras técnicas

para analizar datos, ésta posiblemente sea la más utilizada. Algunas otras técnicas

conocidas son: la minería de datos (abordada más adelante) y CBAT (Column Based

Analytical Technology). De este último no se hará otra mención.

El objetivo principal de los sistemas OLAP es ofrecer a los usuarios una solución

tecnológica que permita agilizar, de manera notable, las consultas generadas en la

compañía con el fin de presentar los resultados producidos en tiempo y forma adecuado.

Los sistemas OLAP se caracterizan principalmente por permitir realizar análisis

multidimensionales de datos, personalizar las perspectivas de análisis para navegar entre

ellos, seleccionar la manera más cómoda de presentar la información, generar informes

preestablecidos e incluso programar la entrega periódica de los resúmenes.

En general, estos sistemas deben:

Permitir realizar complejas consultas sobre los datos de manera simple.

Facilitar el análisis.

Permitir cambiar las perspectivas de análisis.

Procesar eficientemente grandes volúmenes de datos.






pág. 43

Arquitectura Interna de un OLAP.

Existen dos arquitecturas principales para los sistemas OLAP: el modelo

multidimensional denominado MOLAP y el modelo relacional denominado ROLAP.

Aunque, también es posible construir una solución intermedia de tipo Híbrida conocida

como HOLAP.

La arquitectura MOLAP usa bases de datos multidimensionales para proporcionar el

análisis. Su principal premisa es que el OLAP está mejor implementado para almacenar

los datos de manera multi-dimencional. Por el contrario, la arquitectura ROLAP supone

que las capacidades OLAP están perfectamente implementadas sobre bases de datos

relacionales. Un sistema MOLAP usa una base de datos propietaria multidimensional en

la que la información se almacena multidimensionalmente para ser visualizada en varias

dimensiones de análisis. (FIGUEROA GONZÁLEZ, 2007).

Modelos Relacionales (ROLAP).

En una arquitectura ROLAP se accede a los datos almacenados dentro del Data

Warehouse de manera relacional con el objetivo de proporcionar el soporte para los

análisis OLAP. Se supone, para este modelo, que las capacidades OLAP se comportarán

mejor al estar soportadas en bases de datos relacionales.

El sistema ROLAP utiliza una arquitectura de tres niveles. La base de datos relacional

maneja los requerimientos de almacenamiento de datos y el motor ROLAP proporciona

la funcionalidad analítica. El nivel de base de datos usa bases de datos relacionales para

el manejo, acceso y obtención del dato. El nivel de aplicación es el motor que ejecuta

las consultas multidimensionales de los usuarios. (FIGUEROA GONZÁLEZ, 2007).

Los análisis multidimensionales ejecutados por los usuarios finales, a través del motor

ROLAP, son transformados dinámicamente a sentencias SQL. Las cuales, se ejecutan

contra la base de datos relacional para generar los resultados obtenidos a partir del

cruzamiento de los datos de cada tabla.

Modelos multidimensionales (MOLAP).

En un modelo multidimensional, por el contrario, los datos son organizados alrededor

del tema de análisis particular para la organización. La estructura de este modelo está

conformada como una matriz multidimensional o híper cubo. Un Híper Cubo consiste

en un conjunto de celdas pertenecientes a una tabla identificadas por la combinación de

los miembros de las diferentes dimensiones y, cada una de ellas, contiene el valor de la

medida analizada como resultado de la combinación de la dimensiones.

El sistema MOLAP utiliza una arquitectura de dos niveles: la base de datos

multidimensional y el motor analítico. La base de datos multidimensional es la






pág. 44

encargada del manejo y obtención de los datos y conforma el nivel de aplicación. Este

es el responsable de la ejecución de los requerimientos OLAP. Mientras que el nivel de

presentación se integra con el de aplicación para proporcionar un interfaz con la que los

usuarios finales pueden visualizar los análisis OLAP. Una arquitectura cliente/servidor

permite a varios usuarios acceder a la misma base de datos de manera concurrente.

(CHINCHILLA ARLEY, 2011).

En este modelo, la información procedente de los sistemas operacionales, se carga en el

sistema MOLAP mediante una serie de rutinas por lotes. En esta etapa se realizan

operaciones de agregación sobre los datos para calcular cada uno de los hechos de

interés, al mismo tiempo en que se generan las dimensiones de negocio (LUNA POZO,

2010).

Componentes del modelo multidimensional:

- Hecho: El hecho representa al objeto a analizar. El mismo contiene los valores de las

medidas de negocio (WIKIPEDIA, 2010). Cada una de las medidas queda definida

mediante la intersección de una serie de dimensiones relacionadas a ella. Por lo general,

los hechos son casi siempre valores numéricos, enteros o reales, a los cuales se les

puede aplicar alguna función matemática determinada como, por ejemplo, la

agregación.

- Dimensiones: representan cada uno de los ejes en un espacio multidimensional. Estos,

suministran el contexto en el que se obtienen las medidas. Algunos ejemplos son:

tiempo, producto, cliente, departamento, entre otras. Las dimensiones se utilizan para

seleccionar y agrupar los datos en un nivel de detalle deseado. Los componentes de una

dimensión se denominan niveles y se organizan en jerarquías. En definitiva, las tablas

de dimensiones definen cómo están organizados los datos lógicamente y proveen el

medio para analizar el contexto del negocio. Por ejemplo, podemos ver que la jerarquía

para la dimensión tiempo es la siguiente: Día, Mes y Año. (TAMAYO et Al, 2006).

Modelo Lógico de un Data Warehouse

El modelo multidimensional de un DW se construye aplicando un criterio determinado

que, entre otras cosas, permite definir la estructura interna del almacén de datos. Los

diseños posibles de un Data Warehouse son: el esquema en estrella, el esquema copo de

nieve y la constelación de hechos. Cada uno de estos esquemas tiene ventajas como

desventajas y deben ser elegidos en función de la necesidad de la empresa y las

características del modelo. La selección de un esquema más adecuado, dependerá

principalmente del criterio que se utilice al realizar el estudio sobre el problema y los

factores que afectarán el desempeño general del sistema. Entre ellos, están: el

rendimiento de las herramientas al ejecutar consultas, el tamaño del almacén y el

mantenimiento los datos.

http://es.wikipedia.org/wiki/Tipo_de_dato_entero

http://es.wikipedia.org/wiki/Tipo_de_dato_real






pág. 45

Esquema en estrella: Este esquema posee una tabla central llamada tabla de

“Hechos”, donde se almacenan los elementos correspondientes al dominio del

problema que se debe analizar. La misma, está rodeada por tablas de

“Dimensiones” que contienen información necesaria para generar las consultas.

La forma que adopta el modelo, de una de tabla central más grande (hechos)

rodeada tablas o radiales más pequeños (dimensiones), hacen que el esquema se

asemeje a una estrella, dándole nombre a este tipo de construcciones (ROJAS,

2009). Dada su simpleza y la velocidad de respuesta, éste es el esquema ideal

para realizar análisis multidimensionales sobre los datos en los sistemas OLAP.

Como ventaja adicional, éste esquema soporta las consultas de datos agregados y

las consulas de datos de mayor detalle con una velocidad de respuesta bastante

similar.

Esquema copo de nieve: Es una variante del esquema en estrella que presenta

las tablas de dimensión normalizadas. La finalidad de normalizar las tablas es la

eliminación de la redundancia de datos y con ello la reducción del espacio de

almacenamiento. La principal desventaja de este esquema es la caída del

rendimiento para generar las consultas. Esto se debe a que el gestor de consultas

debe crear más tablas de dimensiones y relaciones entre tablas (JOINs). Lo que

provoca una caída significativa en la velocidad de las respuestas.

Constelación de hechos: es una conformación de varios esquemas en estrella o

copo de nieve que comparten las dimensiones. Este esquema es más complejo

que arquitecturas anteriores porque que contiene múltiples tablas de hechos.

Aunque el esquema constelación es más complejo tiene la gran virtud de ser más

flexible. Sin embargo, cuando el número de las tablas vinculadas aumenta la

arquitectura puede llegar a ser muy compleja y difícil de mantener.

Salidas del Data Warehouse

Como venimos viendo, un Data Warehouse es un almacén de datos desde donde se

extrae información periódicamente para uso interno de una organización. La

información es obtenida por medio de una serie de herramientas que acceden a la base

de datos de diferentes maneras para responder a la necesidad particular del usuario.

Entre las formas principales de consultar la base de datos están: las herramientas OLAP,

las herramientas de consulta Ad-Hoc, los Tableros de Control (Dashboard) e incluso

pueden existir aplicaciones creadas por terceros con algún fin particular.

Los sistemas OLAP, en general, son herramientas de consulta y exploración de

datos multidimensionales que permiten extraer la información contenida dentro

del DW. Estas herramientas constituyen el nexo entre el depósito de datos y los

usuarios y, por lo general, poseen interfaces gráficas amigables para permitir

generar, por medio de una serie de pasos sencillos, consultas complejas de forma

http://es.wikipedia.org/wiki/Tabla_de_hechos

http://es.wikipedia.org/wiki/Tabla_de_hechos

http://es.wikipedia.org/wiki/Tabla_de_dimensi%C3%B3n


http://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos







pág. 46

sencilla. El motor que procesa dichas consultas es denominado Query Manager.

Éste es el encargado de gestionar las solicitudes, interactuar con el almacén de

datos, generar los resultados para finalmente entregarlos al usuario en diversos

formatos.

Las Herramienta de Consultas Ad-Hoc pertenecen a un tipo específico de

solución, gestionada directamente por los usuarios finales, empleada para

generar reportes de distinta índole. Estas herramientas brindan la posibilidad al

usuario de manipular directamente las tablas y las uniones existentes para

diseñar y ejecutar sus propias consultas.

El tablero de control es una herramienta que permite entregar información de

gestión de manera resumida y oportuna para la toma de decisión.

Los resultados obtenidos desde una herramienta de tipo Query Manager son entregados

al usuario en varios formatos según la necesidad y se clasifican de la siguiente manera:

Figura 2.4.

Reportes y Consultas: Son pantallas gráficas e intuitivas que brindan la

posibilidad de generar informes avanzados y detallados en el área del negocio

que se esté analizando. El usuario solo debe seguir una serie de pasos para

generar estos reportes. Por ejemplo, podrá seleccionar los elementos que

necesita visualizar, elegir las condiciones y los criterios de agrupación,

seleccionar otros atributos que considere significativos y finalmente ejecutar la

consulta. Posteriormente, el reporte construido podrá ser guardado y consultado

por el mismo usuario de forma periódica. (BERNABEU, 2010)

Vista de Análisis: Son instrumentos que permiten la navegación y exploración

dinámica de los datos de manera interactiva, pudiendo seleccionar las diferentes

dimensiones del análisis. Las mismas, están preparadas para realizar operaciones

complejas como en la perforación y cruzamiento de datos para obtener un mayor

detalle a partir de la información consultada inicialmente. Estas herramientas

están optimizadas para responder rápidamente a las consultas realizadas con una

elevada velocidad de respuesta.






pág. 47

Tablero de Control: Estos pueden entenderse como una colección de reportes y

consultas interactivas que hacen referencia a un tema en particular presentados

en conjunto dentro de un único panel. Este instrumento, permite analizar la

situación general de la empresa mediante lectura de los indicadores más

importantes. Con la simple observación del panel es posible distinguir

rápidamente aquellas áreas de la empresa que requieren una atención de mayor

urgencia.

Metodología Hefesto

Fuente: “HEFESTO: Metodología para la Construcción de un Data Warehouse” (BERNABEU, 2010).

Introducción

Hefesto es una metodología desarrollada recientemente por el Ing. Darío Bernabeu cuya

finalidad es guiar el modelado del Data Warehouse de manera sencilla, ordenada y de

forma intuitiva. Con la ayuda de esta metodología es posible obtener, en poco tiempo,

una visión integral del problema y del modelo constructivo, suficientemente sólida, para

desarrollar una implementación completa del sistema requerido. Estas, son las razones

más fuertes que se tuvieron en cuenta para decidir su utilización en el proyecto de tesis.

La propuesta Hefesto fue impulsada en base a una amplia y exhaustiva investigación

realizada, la comparación de metodologías existentes y experiencias previas aportadas

por el mismo autor, en el estudio y confección de distintos almacenes de datos

construidos. Actualmente la misma se encuentra en la versión 2.0.

Proceso de Diseño

Para llevar a cabo la construcción controlada de una solución de Inteligencia de

Negocio, de manera de minimizar los riesgos del proyecto durante la ejecución, la

metodología Hefesto sugiere distribuir el proceso en cuatro fases:






pág. 48


(BERNABEU, 2010).

Hefesto propone, en la primera etapa, identificar de las necesidades de los usuarios para

conocer las preguntas claves del negocio. Luego, se continúa con el diseño de los

indicadores que van a responder a estos interrogantes junto con las perspectivas de

análisis requeridas. Más tarde, se construirá el modelo conceptual de datos del DW.

En etapas posteriores, se deberán analizar las fuentes de datos OLTP para determinar los

factores constructivos de cada indicador, se señalarán las correspondencias con las

fuentes de datos y, por último, se determinará el campo de estudio de cada perspectiva.

Una vez hecho esto, se podrá continuar con la construcción del modelo lógico del

depósito de datos. En esta etapa, deberá quedar definido el tipo de esquema utilizado en

la implementación. También, se construirán las tablas de dimensiones y las tablas de

hechos para, finalmente, efectuar las uniones correspondientes.

Por último, se definirán los procesos de extracción, transformación y carga para capturar

los datos desde las diferentes fuentes de datos y, finalmente, almacenarlos en el DW.

Ventajas del modelo Hefesto

Los objetivos y resultados esperados en cada fase se distinguen fácilmente y son

sencillos de comprender.

Se basa en los requerimientos del usuario, por lo cual su estructura es capaz de

adaptarse con facilidad y rapidez ante los cambios en el negocio.

Reduce la resistencia al cambio, ya que involucra al usuario final en cada etapa

para que tome decisiones respecto al comportamiento y funciones del DW.

Utiliza modelos conceptuales y lógicos, los cuales son sencillos de interpretar y

analizar.






pág. 49

Es independiente del tipo de ciclo de vida que se emplee para contener la

metodología.

Es independiente de las herramientas que se utilicen en la implementación.

Es independiente de la estructura física que contengan el DW y de su respectiva

distribución.

Cuando se culmina con una fase, los resultados obtenidos se convierten en el

punto de partida para llevar a cabo el paso siguiente.

Se aplica tanto para Data Warehouse como para Data Mart.

Aplicación metodológica

En este apartado se describirá la metodología Hefesto con el objetivo de conocer cada

uno de los conceptos aplicados en el trabajo de tesis y las etapas por las que se va

transitar durante la implementación. A continuación, se presenta un resumen de la

metodología, tomada de la versión 2.0 del libro “Metodología para la construcción de

un Datawarehouse”. Para mayor información, se sugiere referirse a la fuente original.

Antes de comenzar a utilizar esta metodología, es altamente recomendable realizar un

estudio previo sobre la empresa. Con el cual, será posible sentar las bases esenciales

para todas las decisiones que se tomen respecto de la implementación y el diseño del

DW. Por otro lado, nos permitirá conocer su funcionamiento, las necesidades la misma,

las personas involucradas, entre otros aspectos. A partir de esta información, se podrá

armar un contexto sólido para desarrollar el trabajo, implementar el sistema y diseñar el

depósito de datos de la manera más adecuada.

El objetivo principal de esta fase es obtener e identificar la información clave para

gestión de la organización. Es decir, aquella información que asegura que la toma de

decisión de sea un proceso eficaz y eficiente, que permite alcanzar más fácilmente las

metas de la empresa.

Lo primero que se debe realizar es identificar los requerimientos del usuario a través de

una serie de preguntas que expliciten los objetivos de la organización. Este proceso se

puede realizar de diversas maneras en función del criterio que aplique el agente

encargado de llevar a cabo la tarea. Algunos ejemplos de técnicas empleadas son: las

entrevistas, los cuestionarios, la observación directa, etc. El objetivo es identificar las






pág. 50

variables del negocio que permitirán, posteriormente, estudiar la información

organizacional desde diferentes perspectivas de análisis.

Una vez que se han establecido las preguntas claves de negocio se debe proceder a la

descomposición de las mismas para extraer, de ellas, cuáles serán los indicadores

utilizados y las perspectivas de análisis apropiadas. Este es un proceso en el que se debe

identificar cada uno de los elementos y componentes que formarán parte del modelo

conceptual descripto en el siguiente paso.

En esta etapa, se construirá un modelo conceptual a partir de los indicadores y

perspectivas obtenidas en el paso anterior. El proceso de construcción del modelo

conceptual consiste en reunir los indicadores y perspectivas identificadas para ubicarlas

en un mapa lógico que represente claramente su significado y su relación con el

dominio del problema.

La representación gráfica del modelo conceptual es la siguiente:


(BERNABEU, 2010).

Descripción del Modelo Conceptual






pág. 51

A la izquierda se colocan las perspectivas seleccionadas que estarán unidas a un óvalo

central que representa la unión y lleva el nombre de la relación que existe entre ellas. La

relación constituye el proceso o área de estudio elegido. De dicha relación y

entrelazadas con flechas, se desprenden los indicadores. Estos se ubican a la derecha del

esquema.

En este paso, se deben analizar las fuentes OLTP para definir la manera en que se

obtendrán los indicadores y también para establecer las respectivas correspondencias

entre el modelo conceptual, creado en el punto anterior, y las fuentes de datos.

En este paso es necesario definir cuál es el cálculo utilizado para obtener cada uno de

los indicadores a partir de la información disponible en el modelo de datos.

Completado el punto anterior, es necesario establecer la relación entre el modelo

conceptual y las fuentes de datos disponibles con el objetivo de establecer,

inequívocamente, la correspondencia que existe entre todos los componentes utilizados

para la obtención de los indicadores.

Al quedar establecidas las relaciones y correspondencias en los OLTP, se procede con la

selección los campos que serán incluidos en cada una de las perspectivas para

determinar el nivel de granularidad del modelo. Cuanto mayor sea el nivel de detalle de

los datos se tendrán mayores posibilidades analíticas. Todos los campos que se incluyan

serán utilizados, más adelante, para la manipulación de la información una vez que

quede terminado el sistema. Por ello, será necesario indagar el diccionario de datos y

consultar al personal de sistema para determinar inequívocamente el significado de cada






pág. 52

uno de los elementos disponibles y seleccionar adecuadamente los campos que tengan

mayor relevancia.

El objetivo de este paso es ampliar el modelo conceptual. La tarea consiste en colocar

debajo de cada perspectiva todos los campos elegidos y debajo de cada indicador su

respectiva fórmula de cálculo. Los resultados deberán verse gráficamente de la siguiente

manera:


(BERNABEU, 2010).

Modelo Conceptual ampliado.

Para diseñar el Modelo Lógico utilizado en la construcción del Data Warehouse es

necesario basarse en el modelo conceptual desarrollado en las etapas anteriores. Lo

primero que se debe hacer es definir el tipo de modelo más adecuado, Seguidamente, se

deberán crear las tablas de Dimensión y las tablas de Hechos. Por último, habrá que

definir todas las uniones entre las tablas.






pág. 53

Lo que hay que hacer en este punto es elegir el tipo de esquema más adecuado para

definir el depósito de datos. Es necesario revisar las características de cada uno de los

esquemas posibles y seleccionar aquel que mejor se adapte a los requerimientos y

necesidades de los usuarios.

El proceso consiste en diseñar las tablas de dimensiones siguiendo el procedimiento que

corresponde al esquema elegido para del modelo lógico de datos. Cada una de las

perspectivas definidas en el modelo conceptual se corresponderá con una tabla de

dimensión. El proceso de creación de la tabla dimensión, descripto en la metodología,

debe ser repetido tantas veces como perspectivas haya en el modelo conceptual.

En este paso, se deben definir las tablas de hechos que guardarán los valores de interés

utilizados para generar cada uno de los indicadores definidos.

Según el tipo de esquema utilizado es necesario definir las uniones correspondientes

entre las tablas de dimensiones y las tablas de hecho correspondientes.

Una vez ubicados en esta parte del proyecto, deberíamos tener completamente definido

el modelo lógico del DW. El paso siguiente es definir las operaciones que se encargarán

de poblar con información el repositorio de datos. A esta lista de operaciones se las

conoce como Procesos ETL. Los mismos se encargarán de tomar la información desde

diversas fuentes de datos, realizar ciertas transformaciones a los mismos y finalmente

almacenarlos de manera integrada dentro del DW. Estas transformaciones tienen el






pág. 54

propósito de asegurar la integridad de la información en el almacén. Entre las

operaciones principales que realizan se encuentran: la integración, el filtrado y la

depuración. El diseño de los procesos ETL, se lleva a cabo con la asistencia de

herramientas destinadas a tal fin. Por esta razón, solo será necesario enfocarse en la

generación de las sentencias SQL que serán utilizadas para extraer todos los datos de

requeridos desde las fuentes de información. También será posible incluir, entre los

procesos ETL, cualquier otro procedimiento que sea requerido para facilitar el

mantenimiento del modelo de datos.

Es recomendable comenzar un proceso ETL desde la carga de datos de las tablas de

dimensiones y luego continuar con la carga de las tablas de hecho, teniendo en cuenta la

correcta correspondencia entre los miembros. En el caso de utilizar un esquema de tipo

copo de nieve para el Data Warehouse, siempre que exista un jerarquía en algunas de las

dimensiones, será necesario comenzar con la carga las tablas de nivel principal (menor

detalle) y posteriormente, continuar con las tablas de nivel inferior (mayor detalle). Una

vez definido el mecanismo utilizado para poblar el DW, será necesario establecer las

políticas de actualización y refresco de los datos.

Al concluir completamente las etapas descriptas en la metodología Hefesto se cuenta

con la información de diseño necesaria para comenzar, de manera consecutiva, con el

diseño de los cubos multidimensionales. Los mismos deben tener claramente descriptos

cuáles son los indicadores, los atributos y las jerarquías utilizadas. Desde el momento

que se tengan definidos de los cubos multidimensionales se está en condiciones de

comenzar la implementación del sistema.

Data Mining

El Data Minning, es el término utilizado para describir al conjunto de técnicas

empleadas para descubrir conocimiento oculto en bases de datos. Esta disciplina,

combina técnicas tradicionales y operaciones específicas de la inteligencia artificial en

la extracción de conocimiento a partir del análisis de grandes volúmenes de datos

presentes en una organización. Conforme al paso el tiempo, el término "Minería de

Datos" (Data Mining) ha tenido más aceptación para referirse específicamente a la

aplicación de estas técnicas en general.

En otras palabras, Data Mining es el conjunto de técnicas aplicadas a la exploración de

grandes volúmenes de datos con el objetivo de obtener predicciones automatizadas

acerca de comportamientos y de tendencias que permitan descubrir o interpretar nuevo

conocimiento implícito dentro de un determinado contexto.

Las herramientas de Data Mining permiten explorar gran cantidad de datos dispersos en

alguna fuente de datos con el objetivo de predecir tendencias o comportamientos futuros

de una empresa. Estas herramientas complementan fuertemente el proceso de toma de






pág. 55

decisión empresarial al aportar cierto tipo de conocimiento adicional, que de otra forma,

no se habría encontrado. Con la utilización de herramientas de este tipo, es posible

generar nuevas oportunidades de negocio.

Algunas características de estas herramientas son:

Mejorar el funcionamiento de la organización.

Optimizar el manejo de sus bases de datos.

Predicción automatizada de tendencias y comportamientos.

Obtener ventajas comerciales.

Mejorar calidad de productos.

Descubrimiento automatizado de modelos desconocidos.

Descubrimiento de anomalías y acciones fraudulentas por parte de clientes.

Objetivos

Descripción: El principal producto del proceso de la minería de datos es el

descubrimiento de reglas. Las reglas mostrarán nuevas relaciones entre las

variables y nuevas excepciones de acuerdo a la empresa que empele estas

técnicas. Esto será de gran utilidad durante la planificación estratégica de la

misma.

Predicción (Forecasting): Las nuevas reglas o comportamientos descubiertos

pueden ser utilizados para predecir algunas variables de salida. Las predicciones

comúnmente se emplean en conjunto con algunas técnicas tradicionales de

estadística junto a otras técnicas provenientes de la inteligencia artificial.

Modelos

Para poder aplicar las técnicas de Data Mining es necesario establecer un marco de

trabajo que permita construir y evaluar el comportamiento de un primer modelo

propuesto en una situación conocida, para luego, aplicar este mismo modelo en

condiciones desconocidas pero de similares características. El objetivo final, es obtener

conclusiones a partir de los resultados logrados. Este proceso se denomina Modelado.

Un ejemplo muy conocido para explicar lo que es un modelado es el siguiente: “Si se

desea buscar un galeón español hundido en algún mar. Lo primero que podría hacerse es

investigar acerca de otros tesoros españoles que hayan sido encontrados en el pasado.

Notaría que esos barcos frecuentemente fueron encontrados fuera de las costas de

Bermuda y que existen ciertas características similares respecto de las corrientes

oceánicas y las rutas que probablemente se habrían tomado por los capitanes de barco

en esa época. Al identificar esas similitudes es posible construir un modelo que incluya

las características comunes a todos los sitios donde se encontraron tesoros hundidos. A

partir de esta nueva información, será posible buscar más tesoros en lugares donde






pág. 56

exista mayor probabilidad de encontrarlos. Con un poco de esperanza, si tiene un buen

modelo, probablemente se podrá hallar un tesoro”. (LOOR DÍAZ, 2006)

La implementación de Data Minin es un proceso que puede ser dividido en diversas

fases con el objetivo de guiar el proyecto de manera controlada. Estas fases,

independientemente de la técnica que se seleccione para realizar la extracción de

conocimiento, son:

Filtrado de datos: El formato de los datos contenidos en la fuente de datos

nunca es el idóneo y, la mayoría de las veces, no es posible utilizar ningún

algoritmo de minería. Mediante este proceso se filtran los datos (se eliminan

valores incorrectos, no válidos o desconocidos), se obtienen muestras de los

mismos (mayor velocidad de respuesta del proceso), o se reduce el número de

valores posibles (mediante el redondeo y el agrupamiento) (VALLEJOS, 2006).

Selección de variables: Aún después de haber pre-procesados los datos, se

sigue teniendo una cantidad excesiva de información. La selección, es una

característica que permite, eligiendo adecuadamente las variables más

influyentes en el problema, reducir el tamaño de los datos sin sacrificar

drásticamente la calidad del modelo obtenido en el proceso de minería

(VALLEJOS, 2006).

Extracción de Conocimiento: Mediante la extracción se obtiene un modelo de

conocimiento que representa patrones de comportamiento observados en los

valores de las variables del problema o las relaciones de asociación entre dichas

variables. También es posible usar, simultáneamente, varias técnicas diferentes

para generar distintos modelos en éste paso (VALLEJOS, 2006).

Interpretación y evaluación: Finalmente se procede con la validación del

modelo. En este paso se pretende comprobar que los resultados sean válidos y

satisfactorios. Si se hubieran empleado varios modelos diferentes, éstos deberán

ser comparados entre sí en busca de aquel que se ajuste mejor situación del

problema. Puede resultar también, que ninguno de los modelos alcance el

resultado esperado, en tal caso, se tendrá que alterar alguno de estos modelos

tantas veces hasta superar la etapa (VALLEJOS, 2006).

Beneficios

Contribuye con el proceso de toma de decisión empresarial al proporcionar un

mejor sentido de orientación, tanto táctico como estratégico.

Permite que usuarios asignen mejor la prioridad de las acciones y decisiones.

Así por ejemplo, podrán resolver el siguiente interrogante: qué segmentos de

clientes son menos atractivos para la empresa.

Refuerza el poder de decisión de los usuarios que mejor entienden del problema

y del entorno mismo del problema. A su vez, brinda las herramientas para

comprobar resultados de las acciones efectuadas.






pág. 57

Permite generar Modelos Descriptivos sobre los datos que serán utilizados para

explorar automáticamente, visualizar y comprender la información, junto a sus

patrones de comportamiento.

Permite la construcción de Modelos Predictivos. Con ellos, luego se podrán

obtener relaciones no descubiertas por el proceso del Data Mining y expresarlas

como nuevas reglas de negocio. Estos outputs (salidas del sistema) podrán

difundirse dentro de la organización en formatos tradicionales para facilitar la

gestión estratégica y la planificación de recursos en la empresa.

Herramientas empleadas en Data Mining.

En esta sección se presentan algunas herramientas software empleadas para trabajar con

Data Mining.

Weka: Suite de minería de datos de libre distribución.

Weka es una colección de máquinas virtuales para implementar algoritmos y realizar

tareas de minería de datos. Los algoritmos pueden aplicarse directamente a un conjunto

de datos o pueden utilizarse desde un programa de Java. Weka contiene herramientas

para el procesamiento de datos, clasificación, asociación, visualización, entre otras

cosas. También está bien preparado para desarrollar esquemas. Weka es un software

abierto licenciado bajo GNU.

MLC++: Conjunto de librerías y utilidades de minería de datos.

Es una biblioteca o librería de clases escritas en el lenguaje C++. Proporciona

algoritmos que pueden ser usados por usuarios finales, analistas, profesionales e

investigadores. El objetivo principal es proporcionar una variedad de herramientas que

ayuden a implementar procesos de minería de datos, acelerar el desarrollo de nuevos

algoritmos mineros, y proporcionar herramientas de comparación y despliegue de

información.

Xelopes: Librería distribuida bajo licencia pública GNU para el desarrollo de

aplicaciones de minería de datos.

Es una librería multi-plataforma utilizada para la ejecutar procesos de Data Mining.

Proporciona algoritmos de minería de datos muy eficaces para ser integrados de manera

transparente en aplicaciones particulares. Esta librería, soporta la selección automática






pág. 58

de los parámetros utilizados en las llamadas a los métodos del programa para que los

mismos puedan ser desplegados de forma automática.






pág. 59

MODELO TEÓRICO






pág. 60

Introducción

Dentro de la fase Modelo Teórico del proyecto se procederá con el diseño del modelo

requerido durante la implementación del sistema. Finalizada esta etapa, quedarán

completamente definidos cada uno de los artefactos necesarios para la elaboración el

sistema de inteligencia de negocio.

Adoptando el modelo de trabajo propuesto en la metodología Hefesto, vamos a dividir

la construcción del sistema en cinco etapas fundamentales: Requisitos, Análisis, Diseño,

Implementación y Prueba. De las cuales, las primeras tres estarán contenidas dentro de

la sección “Modelo Teórico” del capítulo 3 y abarcarán desde la recopilación de los

requerimientos del sistema, su análisis y el diseño de los modelos de datos. Mientras

que los restantes, serán contemplados dentro de la sección “Concreción del Modelo” del

capítulo 4, en la cual se realizará la implementación y la prueba general del sistema.

A continuación de describen las etapas fundamentales desarrolladas dentro del “Modelo

Teórico”:

Planificación

Requerimientos

o Requerimientos funcionales del sistema

o Requerimientos no funcionales del sistema

Análisis y Diseño

o Diseño del modelo

o Análisis de Requerimientos

o Análisis de los OLTP

o Modelo Lógico del DW

o Integración de Datos.

o Implementación

o Creación de Informes

o Creación de cubos multidimensionales

Dentro del capítulo “Concreción del Modelo” se desarrollan las siguientes secciones:

Implementación

Pruebas

Análisis de Resultado

Experiencias Alcanzadas

Puesta en marcha






pág. 61

Programación de actividades

Diagrama de Actividades

Diagrama de Actividades del Proyecto BI en Magneti Marelli.

Tabla 3.1






pág. 62

Diagrama De Gantt

Figura 3.1.

Requerimientos funcionales del sistema

En la primera etapa de desarrollo se realizaron las tareas de relevamiento. Estas

permitieron recabar información referida a la actividad de la organización, como

también, acerca de las necesidades presentes. Se realizaron, en su momento, diferentes

entrevistas a los miembros que estaban directamente involucrados en el proyecto para

identificar los requerimientos esenciales del sistema en función de la necesidades que

tenían. En esta sección, se van a documentar cada uno de los requerimientos

identificados de manera de poder utilizarlos posteriormente para el diseño del modelo

lógico. A continuación se listan los elementos de interés identificados:

1. Indicador OEE:

Se identificó la necesidad de construir un indicador que permita evaluar el rendimiento

general de la organización en términos de desempeño de la línea productiva. El

indicador propuesto fue el OEE (Overall Equipment Effectiveness o Eficiencia General

de los Equipos), cuyo objetivo es medir la eficiencia productiva de la maquinaria

industrial.






pág. 63

2. Indicador Calidad:

El indicador representa el porcentaje de unidades no conformes con respecto al número

total de unidades fabricadas. Las unidades producidas pueden ser clasificadas en dos

tipos: Conformes (piezas buenas) y No Conformes (piezas malas o rechazadas). A

veces, las unidades No Conformes pueden ser recuperadas por los operarios y

finalmente terminar siendo clasificadas como piezas Conformes. Este indicador sólo

considera a las piezas que salen conformes la primera vez, y no a aquellas piezas que

necesitan ser reprocesadas. Por tanto las unidades que posteriormente van a ser

reprocesadas deben considerarse inequívocamente como piezas rechazadas.

3. Indicador Productividad:

Este indicador resulta de dividir la cantidad de piezas realmente producidas por la

cantidad de piezas que se podrían haber producido. El valor de “cantidad de piezas que

se podrían haber producido” se obtiene de multiplicar el tiempo de producción por la

capacidad de producción nominal de la máquina. El valor de “capacidad nominal de la

maquina” es un valor ideal máximo de producción obtenido en una máquina

determinada. Este valor puede estar provisto por el fabricante de la máquina en cuestión

o bien, es posible utilizar un valor de estándar de fabricación para determinar el ciclo de

fabricación de una operación determinada. Este parámetro se puede obtener mediante un

método de medición realizado sobre el proceso de producción.

4. Tiempo de Setup:

El “Tiempo de Setup” es el periodo de tiempo empleado para ajustar el equipamiento

antes de comenzar la fabricación de un componente. El Tiempo de Setup está

directamente relacionado con las variaciones del producto y la planificación de la

producción realizada.

5. Cantidad de Setup:

Es el número total de operaciones de Setup o de ajuste, realizadas en una línea de

producción.






pág. 64

6. Tiempo de Paradas No Programadas.

Este indicador contiene el tiempo total consumido de pérdida de mano de obra

provocado por las detenciones no programadas en la línea de producción.

7. Cantidad de Piezas Defectuosas:

El indicador contiene la cantidad total de piezas fabricadas que tienen algún defecto de

fabricación.

Requerimientos no funcionales del sistema

En este momento es importante detenerse a describir en detalle las características de la

plataforma empleada para soportar el Data Warehouse. Lo fundamental es entender

cómo es la arquitectura de la aplicación que se va a utilizar, su funcionamiento y los

pasos necesarios para realizar su configuración.

La principal razón por la que se decidió emplear la aplicación Pentaho Community

Edition para la implementación del Data Warehouse es debido a que la herramienta es

Open Source y, por lo tanto, está totalmente liberada para cualquier uso sin ningún tipo

de restricciones. Todas las herramientas que contiene Pentaho CE están distribuidas

bajo licenciamiento GNU GPL (General Public License), por lo que son de uso Libre.

El mismo criterio fue utilizado para elegir el sistema de base de datos empleado para

almacenar la información del DW. De igual forma, se eligió el sistema de gestión de

base de datos MySQL, el cual tiene el mismo tipo de licenciamiento.

Es de destacar que, como veremos más adelante, Pentaho fue diseñado e implementado

para trabajar dentro de un esquema de tipo Cliente-Servidor. Este software y todos sus

componentes asociados conforman un Servicio de Consulta que esta contenido dentro

de un equipo de tipo Servidor.

Los componentes o Softwares necesarios para construir la Solución de Negocio basados

en esta arquitectura son: Pentaho Reporting, Pentaho Data Integration, Pentaho

Metadata y Pentaho Analysis Services.






pág. 65

Arquitectura Lógica

Figura 3.2.

El diagrama expuesto arriba representa el esquema lógico del sistema de información

diseñado para la implementación. El mismo esta subdividido en dos partes principales.

A la izquierda, se encuentra el sistema de información empresarial, en donde se produce

y se almacena la información diaria del negocio. A la derecha, se distingue el sistema de

Inteligencia de Negocio donde se procesa y almacena la información dentro del Data

Warehouse para ser, finalmente, consultada por las herramientas de reportes.

Para comprender mejor el esquema, es necesario saber que el flujo normal de los datos

se realiza de forma horizontal y de izquierda a derecha. El ciclo de vida de la

información, comienza con la recolección de los datos generados en forma diaria, desde

los distintos puntos de adquisición de datos diseñados especialmente para este fin.

Luego, estos datos son almacenados de manera estructurada dentro de una base de

datos. Todos componentes que se utilizan para la recopilación de datos y su

almacenamiento pertenecen, como podemos ver en el gráfico, al sistema de información

empresarial. Una vez que la información fue colectada desde los puntos de adquisición,

la misma es procesada y trasladada a una nueva base de datos especialmente preparada

para soportar las consultas multi-dimensionales de manera eficiente. En este paso se

incorpora cualquier otra información que tenga pertinencia con la necesidad

organizacional, sea a partir de bases de datos o incluso desde archivos administrativos

utilizados en la empresa. Tales como, archivos Excels, archivos planos, etc. En el






pág. 66

esquema propuesto, el sistema de Inteligencia de Negocio, incluye todos los artefactos

intervinientes desde la obtención de los datos desde las fuentes organizacionales, el

procesamiento y almacenamiento en el nuevo almacén, junto a las herramientas de

consultas utilizadas para generar los reportes.

El ciclo de vida de la información concluye cuando los datos pre-procesados son

consultados, de manera dinámica, por los diversos usuarios de la organización

empleando, para ello, las herramientas interactivas disponibles en la plataforma que fue

seleccionada.

Infraestructura requerida

Servidor Pentaho

El componente principal de la implementación es el Servidor. Este equipo debe

soportar la aplicación de Servicios de Consulta de Pentaho CE. Por lo tanto, es

necesario revisar la documentación para conocer cuáles son los requerimientos

técnicos que publica el fabricante para ejecutar el programa adecuadamente.

Según el fabricante Pentaho los límites indicados a continuación no son estrictos

tanto en la capacidad computacional como en el hardware de red que se deba

utilizar. No obstante, se sugiere superar los requerimientos mínimos para obtener

un resultado aceptable.

Requerimientos de Hardware del Servidor Pentaho

Hardware Características

RAM Al menos 2GB

Hard drive space Al menos 1GB

Processor Dual-core AMD64 or

EM64T

Tabla 3.2.






pág. 67

Servidor del SGBD

El sistema de gestión de base de datos MySql, va a ser instalado en el mismo

equipo donde se encuentra el servicio Pentaho CE. Por lo que el hardware

utilizado deberá superar las capacidades mínimas de ambos productos, debiéndose

tomar convenientemente un margen de acuerdo al criterio del diseñador de la

arquitectura.

Los requerimientos necesarios para correr un servidor de base de datos MySql,

según lo informa su fabricante, son los siguientes:

Requerimientos de Hardware del Servidor de Base de Datos


RAM Al menos 128MB

Hard drive space Al menos 150MB

Processor X86 700 Mhz

Tabla 3.3.

Terminal Cliente

Los equipos de cada usuario (las maquinas clientes) necesitarán acceder a los

servicios Web brindados por el servidor Pentaho. Los requerimientos de hardware

de estas máquinas serán muy reducidos debido a que sólo necesitarán correr un

Navegador de Internet. Por esta razón, se sugiere la instalación de una

computadora en cada terminal de usuario que supere los requerimientos mínimos

descriptos a continuación:

Requerimientos de Hardware de la Máquina Cliente


Processor X86 700 Mhz

Tabla 3.4.






pág. 68

Selección de la Tecnología

Pentaho

Pentaho es una plataforma de Inteligencia de Negocio que incluye los componentes

esenciales para poder implementar una solución integrada. En otras palabras, cuenta con

una serie de herramientas de gestión y análisis de la información, junto a herramientas

de presentación y procesamiento de grandes volúmenes de datos requeridos en una

implementación de esta envergadura. Esta plataforma estará configurada para procesar

la información transaccional de la organización y presentarla de manera oportuna para

su análisis.

Pentaho cuenta con la posibilidad de entregar los reportes solicitados a los usuarios en

diferentes formatos de archivo para simplificar la gestión de la información en la

empresa. El sistema permite utilizar los formatos más comunes como son: archivos pdf,

HTML, hojas excels, entre otros. Esta plataforma permite, a su vez, consultar informes

o reportes preestablecidos, aunque también es posible diseñar informes personalizados

de tipo Ad Hoc de manera sencilla e intuitiva.

Por otro lado, cuenta con una herramienta de presentación denominada Community

Dashboard Framework con la que se construyen los tableros de control de gestión de

manera amigable e interactiva.

Pentaho utiliza un motor Web Apache. Por lo que su acceso para el mantenimiento

puede ser realizado de manera remota mediante algún explorador de Internet conocido.

Cuenta además, con una infraestructura de tipo JMS (Java Message Service) para enviar

resúmenes por correo electrónico y programar dichas tareas a través del sistema de

planificación llamado Quartz.

La plataforma mencionada fue seleccionada por diversas razones. En primer lugar, se

tuvo en cuanta el hecho de que la herramienta es libre y gratuita. Por otro lado, se

contemplaron otras cuestiones no menores, como por ejemplo, la versatilidad para

ejecutarse en diferentes Sistemas Operativos y la aparición paulatina de nuevas

experiencias en el empleo de esta plataforma junto a la existencia de una extensa

comunidad que la está respaldando día a día y que, además, está aportando

continuamente para su desarrollo. Otro factor se contempló para su elección fue la

capacidad y la escalabilidad que tiene la herramienta para brindar excelentes soluciones

en diferentes niveles de complejidad y tamaño de problemas, permitiendo atender las

necesidades de pequeñas y grandes empresas eficientemente. Finalmente, por su

facilidad para el uso y por tener una curva de aprendizaje accesible para el empleo de la

solución por parte de los usuarios y de los desarrolladores.

http://es.wikipedia.org/wiki/Java_Message_Service






pág. 69

Extracción Transformación y Carga

La plataforma Pentaho CE cuenta con la herramienta Pentaho Data Integración (PDI)

para el diseño y construcción de los procesos ETL. Éstos, son los procesos que

recolectan, desde las distintas fuentes de información, los datos que alimentan el Data

Warehouse. Pentaho Data Integration, no solo brinda las herramientas para realizar la

recolección de datos, también ofrece los elementos necesarios para automatizar dichos

procesos y monitorear todas las ejecuciones. Esta herramienta cuenta con una extensa

biblioteca de procesos útiles para llevar a cabo la integración de los datos de manera

intuitiva. La misma puede ser empleada dentro de arquitecturas pequeñas y simples

hasta en aquellas que son más complejas.

Con una amplia gama de recursos de conectividad para acceder diversas fuentes de

datos, tanto estructuradas como semi-estructuradas, Pentaho Data Integration permite

consolidar los datos obtenidos desde múltiples orígenes y los transforma de modo

consistente para una posterior consulta. Gracias a su arquitectura de procesamiento

paralelo, la herramienta puede ejecutar las transformaciones más complejas en cuestión

de segundos. Su arquitectura tiene la capacidad de realizar la agrupación dinámica de

los datos para mejorar aún más el rendimiento y, al mismo tiempo, ofrece a los

desarrolladores una plataforma de tipo empresarial que se ajusta perfectamente a las

exigencias actuales de un Data Warehouse.

Mondrian

Este es un Motor OLAP escrito en el Lenguaje Java que permite el análisis interactivo

de grandes cantidades de datos almacenados en las bases de datos. El motor utiliza el

lenguaje de consulta MDX para componer los datos de manera multidimensional

mientras que, por otro lado, traduce las consultas MDX en sus correspondientes SQLs

para consultar todos los datos requeridos al Sistema de gestión de Base de Datos

existente (SGBD).

El termino OLAP (Online Analytical Processing), hace referencia al análisis de largas

cantidades de datos en tiempo real. A diferencia de OLTP (Online Transaction

Processing), donde las operaciones son principalmente de lectura y actualización

realizadas bajo número reducido de registros, OLAP tiende a trabajar con grandes

volúmenes de datos, donde las operaciones son normalmente de lectura. El término

“online” define al tipo de consulta “eficiente y a término” de grandes cantidades de

datos (normalmente millones de registros almacenados en varios gigabytes de espacio

ocupado), donde es necesario responder rápidamente a las peticiones de los usuarios

permitiendo la exploración dinámica de los datos.






pág. 70

MySQL

MySql es un Sistema de Gestión de Base de Datos de tipo relacional, multihilo y

multiusuario. El motor de base de datos de MySql puede ser utilizado de manera libre

bajo las condiciones contenidas dentro de la licencia GNU GPL. Aunque, aquellas

empresas que quieran incorporarlo en productos privativos deben comprar una licencia

específica para tal fin.

Se ha elegido a MySql para realizar el almacenamiento de los datos del Sistema de

Información Operacional y los del Data Warehouse. Las principales ventajas de este

SGBD son: su rápida instalación, su potente configuración, su alta performance, además

de su libertad para el uso.

Diseño del modelo

En esta sección se va a proceder con la construcción del modelo lógico del DW como lo

indica la metodología Hefesto. Cada una de las etapas, se corresponden exactamente

con los pasos que están descriptos en el capítulo 5.5 titulado “Pasos y aplicación

metodológica”. Para mayor información, se recomienda referirse al libro “HEFESTO:

Metodología para la Construcción de un Data Warehouse”.

Análisis de requerimiento

1. ¿Cuál es el rendimiento de cada célula de producción para cada producto

fabricado por empleado, en un tiempo y un turno indicado?

2. ¿Cuál es la cantidad de Piezas OK fabricadas en un proceso determinado

de un producto dado, en un tiempo y un turno indicado?

3. ¿Cuál es la cantidad de piezas defectuosas fabricadas en un proceso

determinado de un producto dado, en un tiempo y un turno indicado?

4. ¿Cuál es el tiempo total de producción alcanzado por producto,

consumido por un empleado, en un proceso determinado, en un tiempo y

un turno indicado?

http://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_base_de_datos

http://es.wikipedia.org/wiki/Modelo_relacional

http://es.wikipedia.org/wiki/Hilo_en_sistemas_operativos

http://es.wikipedia.org/wiki/Multiusuario

http://es.wikipedia.org/wiki/Licencia_p%C3%BAblica_general_de_GNU






pág. 71

5. ¿Cuál es el tiempo total de pérdida de mano por producto, consumido por

un empleado en un proceso determinado, en un tiempo y un turno

indicado?

6. ¿Cuál es la Cantidad de Operaciones de Setup (ajustes) realizados por un

empleado en un proceso, producto, turno, y tiempo determinado?

7. ¿Cuál es el Tiempo de Setup consumido por un empleado, en un proceso,

producto, turno, y tiempo determinado?

Nota:

Cantidad de Setup: es el número de veces que un empleado realiza el ajuste de

máquina para comenzar a producir un nuevo producto.

Tiempo de Setup: es el tiempo estándar estimado en el que cada operador debería

preparar la maquina antes de trabajar con cada producto.

Con las preguntas claves del negocio ya identificadas, lo siguiente es hacer la

descomposición de cada elemento para comprender y determinar inequívocamente

cuáles son los indicadores que se van a utilizar y cuáles son las perspectivas de análisis

que se aplicarán en modelo.

Indicadores:

Rendimiento

Cantidad de Setup

Tiempo de Setup

Cantidad Piezas OK

Cantidad Piezas Defectuosas

Horas Trabajadas

Horas Pérdida Mano de Obra

Perspectivas de análisis:

Tiempo

Turno






pág. 72

Producto

Proceso

Empleado

Estado de Producto

Clasificación de Tiempo

No Conformidad

Parada No Programadas

En este paso se realizará la construcción del modelo conceptual. El resultado de esta

etapa será una primera aproximación al modelo del DW que permitirá a los usuarios

revisar y comprender el alcance del proyecto principalmente.

Relación Indicadores:

Figura 3.3.

Relación Producción:

Figura 3.4.






pág. 73

Relación Productividad:

Figura 3.5.

Dada la similitud de los indicadores <Cantidad de Piezas OK>, <Cantidad de Piezas No

OK>; <Horas Trabajadas> y <Horas de Pérdida de Mano de Obra> respectivamente, se

decidió unir y tratar a éstos valores, de manera unificada como dos indicadores. La

estrategia consiste en sumar ambos valores y poder discriminarlos según su tipo. Para

ello, se decidió crear una nueva la perspectiva de análisis con la que se podrá determinar

el tipo de indicador consultado. Esta estrategia va a permitir, ni más ni menos, que

simplificar el modelo OLTP.

Con esta modificación lógica se pretende pasar de tener cuatro indicadores, inicialmente

definidos, a solo dos: Cantidad de Piezas (indicador 4) y Horas Trabajadas (indicador

5), cuyas perspectivas serán: Estado Producto (OK; NO-OK) y Tiempo Clasificación

(Productivo; No Productivo) respectivamente.

También es necesario crear dos indicadores más para el cálculo del Rendimiento. El

indicador de Calidad y Productividad. A partir del producto de ambos se obtiene el

valor de rendimiento requerido.

Relación Indicadores:

Figura 3.5.






pág. 74

Relación Producción:

Figura 3.6.

Relación Productividad:

Figura 3.7.

Análisis de los OLTP.

Esta etapa que sigue consiste en analizar las fuentes OLTP para determinar cómo serán

calculados los indicadores y posteriormente establecer las correspondencias entre el

modelo conceptual, creado en el paso anterior, y las fuentes de datos. Luego, se deberán

definir los campos que serán incluidos en cada perspectiva y, finalmente, se ampliará el

modelo conceptual con la nueva información obtenida de este paso.






pág. 75

Hechos Identificados:

1. Hecho: “Rendimiento OEE”

Fórmula: 100 Calidad dadProductivi

Función de promedio: AVG

Descripción:

El indicador presenta el valor de rendimiento calculado en función de la

calidad y la productividad obtenida en los procesos de fabricación.

2. Hecho: “Cantidad Setup”

Fórmula: Cantidad de Items existentes en un Resumen de Producción

declarado.

Fórmula de Sumarización: SUM

Descripción:

El indicador representa la cantidad total de productos empleados en un

resumen. Lo que indica cuantas veces se requiere poner a punto un proceso

para fabricar un producto determinado.

3. Hecho: “Tiempo Setup”

Fórmula: 60 Setup Tiempo

Función de Sumarización: SUM

Descripción:

El Tiempo de Setup es el empleado para poner a punto una máquina antes de

comenzar a producir un producto determinado. Por cada cambio de producto

que se efectúa, el operario debe realizar la puesta a punto nuevamente. El

valor de tiempo medio consumido para la puesta a punto, está normalizado y

varía en función de cada proceso de fabricación. El indicador “Tiempo

Setup” viene a representar la sumatoria de los Tiempos de Setup utilizados

en cada uno de los procesos de fabricación existentes.

4. Hecho: “Cantidad Piezas”






pág. 76

Fórmula: Cantidad

Función de Sumarización: SUM

Descripción:

El indicador representa la sumatoria de las unidades que se han fabricado de

un producto en particular.

5. Hecho: “Horas Trabajadas”

Fórmula: TiempoFloat

Función Sumarización: SUM

Descripción:

El indicador representa las horas totales trabajadas.

Lista de Hechos Adicionales:

6. Hecho: “Productividad”

Fórmula: Trabajado Tiempo Estandar Producción

100 Total Producida Cantidad

Función de promedio: AVG

Descripción:

El indicador contiene el grado de productividad alcanzado en todos los

procesos de fabricación.

7. Hecho: “Calidad”

Fórmula:

100Total Producida Cantidad

DefectosCon Producida Cantidad Total Producida Cantidad

Función promedio: AVG

Descripción:

El indicador contiene el grado de calidad alcanzado en todos los procesos de

fabricación.






pág. 77

El objetivo de este paso es identificar claramente las correspondencias existentes

entre el modelo conceptual y las fuentes de datos disponibles. Por ello, se debe

observar cada uno de los elementos inluidos para verificar, posteriormente, la

existencia de las entidades requeridas dentro del OLTP.

Es importante tener en cuenta que, a esta altura del proyecto, no se cuenta con un

modelo OLTP debido a que no existe ningún sistema de información que esté en

funcionamiento en la empresa. Por esta razon, se tendrá la libertad para definir cada

una de las entidades que se vayan a requerir en las etapas siguientes de la

metodología. Solamente habrá que pensar en los componentes que son necesarios

para el modelo, asumiendo que estarán disponibles una vez que se construya el

sistema de información que abastecerá de datos al Data Warehose. Sistema que será

construido más adelante en base a las entidades que aquí se definan.






pág. 78

Dimensiones

Figura 3.8.






pág. 79

Figura 3.9.






pág. 80

Indicadores:

Figura 3.10.






pág. 81

Relaciones identificadas:

La Tabla Turno se relaciona con la perspectiva Turnos.

La Tabla Empleados se relaciona con la perspectiva Empleados.

La Tabla Material se relaciona con la perspectiva Productos.

La Tabla Tiempo Clasificación se relaciona con la perspectiva Tiempo

Clasificación.

La Tabla Proceso se relaciona con la perspectiva Procesos.

La Tabla Paradas No Programadas se relaciona con la perspectiva Parada No

Programadas.

La Tabla No Conformidades se relaciona con la perspectiva No Conformidades.

La Tabla Estado Productos se relaciona con la perspectiva Estado Productos.

El campo fechaDeclaración de la tabla ProducciónCabecera se relaciona con la

perspectiva Tiempo.

El campo cantidad de la tabla ProducciónDetalle está relacionado al indicador

“Unidades Productividad”

El campo tiempoFloat de la tabla producción TiempoDetalle se relaciona al

indicador “Horas Trabajadas”

El campo cantidad total de la tabla producción resumen multiplicado por 100 (cien)

dividido por el valor del campo estándar fabricación de la tabla material

correspondiente al producto utilizado en dicha producción, es utilizado para generar

el indicador Productividad.

El campo CantidadTotal de la tabla ProducciónResumen menos el valor del campo

ScrapTotal de la misma tabla, dividido por el campo CantidadTotal, todo

multiplicado por 100 (cien), es utilizado para generar el indicador Cantidad.

Pera generar el indicador Rendimiento OEE se realiza el cálculo utilizando el

resultado del producto de los indicadores de Calidad y Productividad, dividido en

100 (cien).

Para determinar el nivel de granularidad, es decir, el nivel de detalle de este modelo, lo

primero que hay que hacer es encontrar el significado de los campos de las tablas

involucradas accediendo al diccionario de datos o a través de la consulta directa al

responsable del sistema. Dado que en este proyecto no se dispone de un modelo OLTP

tampoco se cuenta con un diccionario de datos. Lo que se debe hacer entonces, es

especificar todos los campos necesarios para cada perspectiva previendo que, más

adelante, el sistema será creado manteniendo la correlatividad con las definiciones

establecidas esta parte del proyecto.

A continuación se describen los campos que serán incluidos en cada una de las

perspectivas del modelo construido:






pág. 82

Respecto de la perspectiva Empleados:

Campos de la Perspectiva Empleados

Campo Significado / Utilidad

Legajo Contiene el legajo del empleado asignado por la empresa.

Apellidos Contiene el apellido del empleado.

Nombres Contiene el nombre del empleado.

Dni Contiene el DNI del empleado.

esOperario Valor binario para determinar si el empleado es operario de

planta.

NombreCompleto Contiene una concatenación entre el campo Apellidos y

Nombres.

Tabla 3.5.

Respecto de la perspectiva Tiempo:

En el caso de la perspectiva Tiempo definimos los campos indicados en la tabla en

función de la granularidad requerida para atender una necesidad concreta. Es decir,

poder realizar el seguimiento de cada uno de los hechos en función del año, trimestre,

mes, día, día de la semana.

Campos de la Perspectiva Tiempo


Anio Contiene un valor numérico de año.

Trimestre Contiene un valor numérico de trimestre.

Mes Contiene un valor numérico de Mes.

Semana Contiene un valor numérico de Semana.

Dia Contiene un valor numérico de Día.

diaSemana Contiene un valor numérico que indica que día es dentro de






pág. 83

la semana.

trimestreLetra Contiene el nombre del Trimestre.

mesLetra Contiene el nombre del Mes.

mesLetra3 Contiene el nombre abreviado del Mes.

semanaLetra Contiene el nombre de la semana.

diaLetra Contiene el nombre del día.

Tabla 3.6.

Respecto de la perspectiva Producto:

Campos de la Perspectiva Producto


Producto Contiene el nombre del Producto.

EstandarFabricación Contiene el valor Estándar de Fabricación.

TiempoSetup Contiene un valor numérico con el Tiempo estimado para

el Ajuste de Máquina.

Tabla 3.7.

Respecto de la perspectiva No conformidades:

Campos de la Perspectiva No Conformidades


NoConformidad Contiene el nombre de la No Conformidad.

Tabla 3.8.






pág. 84

Respecto de la perspectiva Paradas no Programados:

Campos de la Perspectiva Paradas No Programadas


ParadaNoProgramada Contiene el nombre de la Parada No Programada.

Tabla 3.9.

Respecto de la perspectiva Procesos:

Campos de la Perspectiva Procesos


Proceso Contiene el nombre del Proceso.

Tabla 3.10.

Respecto de la perspectiva Tiempo Clasificación:

Campos de la Perspectiva Tiempo Clasificación


TiempoClasificación Contiene el nombre de clasificación usado para el tiempo de

producción.

Tabla 3.11.

Respecto de la perspectiva Turnos:

Campos de la Perspectiva Turnos


Turno Contiene el nombre del Turno.

Tabla 3.12.






pág. 85

Con el fin de graficar los resultados obtenidos en los pasos anteriores, se completa el

modelo conceptual ampliado. El mismo contiene todos los campos elegidos para cada

perspectiva y, debajo de cada indicador, su respectiva fórmula de cálculo.

Perspectivas de la Relación Indicadores:

Figura 3.11.

Perspectivas de la Relación Producción:

Figura 3.12.






pág. 86

Perspectivas de la Relación Productividad:

Figura 3.13.

Modelo lógico del Data Warehouse

El modelo lógico seleccionado para confeccionar el Data Warehouse es el esquema de

tipo estrella. Se elige este modelo por las ventajas que el mismo brinda, es decir, su alto

rendimiento y su mayor velocidad de respuesta a las peticiones de los usuarios. Estos

beneficios, se obtienen con la reducción significativa de las uniones establecidas entre

tablas al momento en el que se ejecutan los procesos de consultas, en perjuicio de tener

que ocupar un poco más de espacio en disco para almacenar la información dentro de la

base de datos.

La idea es generar una base de datos sencilla donde se almacene, de manera anticipada,

todos los hechos previamente calculados para permitir el análisis sobre los datos con un

tiempo de respuesta muy bajo y atender, al mismo tiempo, gran número de consultas de

manera eficiente cuando éstas sean requeridas.

Para diseñar las tablas de dimensiones correspondientes al modelo estrella, se van a

aplicar tres pasos sugeridos por la metodología Hefesto. Estos son:

1. Elegir un nombre que identifique a la tabla dimensión.

2. Agregar un campo que represente su clave principal.






pág. 87

3. Redefinir el nombre de aquellos campos que no fuesen suficientemente claros para

entender el modelo.

Lista de Tablas Dimensionales

Perspectiva Empleado:

Figura 3.14.

Perspectiva Producto:

Figura 3.15.

Perspectiva No Conformidades:

Figura 3.16.






pág. 88

Perspectiva Paradas No Programadas:

Figura 3.17.

Perspectiva Proceso:

Figura 3.18.

Perspectiva Producto:

Figura 3.19.






pág. 89

Perspectiva Tiempo:

Figura 3.20.

Perspectiva Tiempo Clasificación:

Figura 3.21.

Perspectiva Turno:

Figura 3.22.

A continuación se definen las tablas de Hechos. Estas van a registrar toda la actividad

que se desarrolle en la organización respectiva al dominio del problema que se desea

analizar.

La confección de las tablas de Hecho se hizo siguiendo los siguientes pasos:






pág. 90

1. Asignar un nombre a la tabla que represente a la información analizada, área de

investigación, negocio enfocado u otro.

2. Definir una clave primaria compuesta por la combinación de las claves primarias de

cada tabla de dimensión relacionada.

3. Crear tantos campos de hechos como indicadores hayan sido definidos en el modelo

conceptual y nombrarlos, preferentemente, de la misma forma que se nombró a los

indicadores. Si esto no es posible, podrán ser identificados de una forma diferente

siempre y cuando se entienda claramente su significado.

Lista de Tablas de Hechos:

1. La tabla de hechos tendrá el nombre “dw_indicadores”.

a. Su clave principal será la combinación de las claves principales de las tablas

de dimensiones antes definidas: “idProduccion”, “idTurno”, “idProceso”,

“idOperario”, “fechaDeclaración”.

b. Se crearán cinco hechos, que serán renombrados como: “OEE”, “Cantidad

Setup”, “Tiempo Setup”, “Productividad”, “Calidad”.

c. Se agregan al modelo los campos idProduccionCabecera y fechaProcesado,

para tener mayor trazabilidad acerca de los registros insertados y poder

anticipar cualquier requerimiento futuro.

Figura 3.23.

2. La tabla de hechos tendrá el nombre “dw_producción”.


de dimensiones antes definidas: “idProducción”, “idTurno”, “idProceso”,

“idOperario”, “fechaDeclaración”, “idEstadoProducto”,

“idNoConformidad”.

b. Se creará un hecho que se corresponde con el indicador creado y será

renombrado como: “cantidad”.






pág. 91


con el objetivo de tener mayor conocimiento acerca de los registros

insertados y poder anticipar cualquier requerimiento futuro.

Figura 3.24.

3. La tabla de hechos tendrá el nombre “dw_productividad”.


de dimensiones antes definidas: “idProducción”, “idTurno”, “idProceso”,

“idOperario”, “fechaDeclaración”, “idEstadoProducto”,

“idNoConformidad”.

b. Se creará un hecho, que se corresponde con los el indicador creado y será

renombrado como: “Horas”.


con el objetivo de tener mayor conocimiento acerca de los registros

insertados y poder anticipar cualquier requerimiento futuro.

Figura 3.25.






pág. 92

Se presenta el resultado completo del modelo del Data Warehouse en base al esquema

estrella construido.

Uniones correspondientes a la tabla dw_indicadores:

Figura 3.26.






pág. 93

Uniones correspondientes a la tabla dw_producción:

Figura 3.26.

Uniones correspondientes a la tabla dw_productividad:

Figura 3.27.






pág. 94

Procesos ETL

A continuación se presenta el diseño los procesos ETL, también conocidos como los

procesos de Obtención, Transformación y Carga, que serán responsables de actualizar el

modelo de datos del Data Warehouse. Los mismos, serán los encargados de calcular,

controlar y validar los datos para que sean cargados sin errores en la base de datos del

Data Warehouse.

Proceso Principal ETL

Figura 3.27.

Para entender mejor este diagrama, es necesario describir el funcionamiento del proceso

que lleva a cabo la carga del Data Warehouse. El proceso ETL comienza con el paso

“Start” en la parte superior del diagrama. A partir de allí, se continúa con los pasos de

control de inserción de registros para agregar solo los últimos cambios al modelo. De

forma consecutiva se procede con carga de cada una de las dimensiones, y finalmente se

procede con la carga de cada una de las tablas de hechos teniendo en cuenta la

predominancia para su creación, en función de la dependencia que existe entre ellas. Es

decir, se comenzará por las tablas con menor grado de dependencia para evitar






pág. 95

problemas de validaciones entre las claves primarias. También es posible realizar tareas

administrativas y otras de mantenimiento dentro del mismo proceso ETL.

Sistema de Notación del Diagrama

La notación establecida para identificar inequívocamente cada uno de los pasos dentro

del diagrama es la siguiente:

Se define un identificador de tipo alfa numérico conformado por dos caracteres para

cada elemento que compone el diagrama. El primer carácter identifica al tipo de acción

ejecutada. (M: Mecanismo de Control; D: Dimensión; H: Hecho; A: Proceso

Adicional;), mientras que el segundo carácter, establece un número secuencial para cada

tipo de elemento.

Sistema de Notación del Diagrama de Procesos ETL

Letra Descripción

M Mecanismo de Control

D Dimensión

H Hecho

A Proceso Adicional

Tabla 3.13.

Control en las Inserciones de los Registros

El proceso que realiza la actualización del Data Warehouse puede ser realizado de dos

maneras. La primera consiste en regenerar de todos los registros del almacén cada vez

que se corre el proceso ETL. Es decir, en cada ejecución, se borran y se vuelven a

agregar todos los registros en cada tabla. En cambio, en la segunda alternativa, solo se

actualizan en el modelo los registros que fueron agregados a la base de datos después de

la última corrida del proceso. Estas políticas pueden ser aplicadas indistintamente para

refrescar todas las tablas del modelo, aunque también, pueden ser combinadas

dependiendo de la necesidad que se tenga en cada caso.

En este proyecto se optó por utilizar la primera de las estrategias para la de regeneración

completa de los registros en las tablas dimensionales. Mientras que, para el caso de las

tablas de hechos, se decidió aplicar el segundo mecanismo que permitirá cargar sólo los

datos ingresados después de la última ejecución de los procesos ETL. La razón por la

cual se tomó esta decisión, es que las tablas de hecho poseen una gran cantidad de

registros, lo que hace que sea poco práctica la carga completa de las mismas si se quiere






pág. 96

minimizar el tiempo de acceso a la información más reciente. En otras palabras, recrear

todos los registros de las tablas de hechos tomaría varios minutos y es posible, incluso,

que el almacén quede en un estado inconsistente para las consultas de los usuarios. En

cambio, si se aplica una política para la actualización parcial de la información se

emplearán apenas unos segundos para cargar aquellos campos que fueron agregados

desde la última ejecución del proceso.

Para implementar este mecanismo es preciso agregar una restricción adicional en todas

las tablas de hechos con la que será posible controlar, en función de la hora de inserción,

la lista de registros que serán agregados. Este mecanismo consta de 4 pasos que se

explicarán, con mayor detalle, a continuación:

Cuando el proceso comienza, se establece una fecha de inicio (DW_FECHA_INICIO) y

otra de fin (DW_FECHA_FIN) en una tabla temporal. Estos registros van a servir para

controlar cuáles serán las cabeceras que deben ser cargadas. De esta manera los

registros que cumplen con esta condición son procesados e insertados en las tablas de

hechos.

Para que el mecanismo funcione correctamente es necesario establecer, antes de cada

ejecución, el valor del campo que contiene la fecha de fin con la fecha actual del

sistema, utilizando para ello la función “current_date” de MySql. Esta operación se

realiza con el paso ETL denominado “tabla_configuración_completar_fecha_fin” (paso

1). Al finalizar la ejecución de todo el proceso ETL se corre el paso

“tabla_configuración_completar_fecha_inicio” (paso 2) para establecer el valor de fecha

de inicio con el mismo valor que la fecha de fin. De esta forma, es posible asegurar que

solamente se carguen al almacén los registros agregados después de la última corrida

del proceso de actualización del Data Warehouse.

Finalmente, es importante realizar una operación adicional para asegurar la integridad

de la información almacenada en la base de datos. La misma, consiste en borrar todos

los registros que pudieron haber sido procesados ante una eventual ejecución inconclusa

del proceso ETL. Esta situación, puede darse por ejemplo, ante un corte inesperado de

energía. Un inconveniente como este puede provocar, con alta probabilidad, que en una

segunda ejecución se dupliquen registros en las tablas involucradas. Lo que ciertamente

es inadmisible.

Para evitar que se dupliquen registros en el DW se realizan dos operaciones. La primera,

al inicio del Proceso General, consiste en borrar los registros con el valor de campo

fechaProcesamiento mayor al valor del campo UltimoProcesamiento de la tabla

Configuración (paso 3). La segunda operación, al final de la corrida de todos los

procesos, se actualiza el valor UltimoProcesamiento con la fecha actual del sistema

(paso 4), de la misma manera que se hizo antes con el valor del campo

DW_FECHA_FIN.






pág. 97

Proceso tabla_configuración_completar_fecha_fin.

(M1)

Proceso Transformación_BorrarRegistrosMalProcesados.

(M2)

Lista de Tablas de Dimensiones

Dimensión Estado Productos.

(D1)

Se seleccionan todos los registros de la tabla estado productos y se cargan en la tabla

dimensional dw_estadoproductoslookup.






pág. 98

Dimensión No Conformidades.

(D2)

Se seleccionan todos los registros de la tabla no conformidades y se cargan en la tabla

dimensional dw_noconformidadeslookup.

Dimensión Paradas No Programadas.

(D3)

Se seleccionan todos los registros de la tabla paradas no programadas y se cargan en la

tabla dimensional dw_paradasnoprogramadaslookup.






pág. 99

Dimensión Proceso.

(D4)

Se seleccionan todos los registros de la tabla proceso y se cargan en la tabla dimensional

dw_procesoslookup.

Dimensión Empleados.

(D5)

Se seleccionan todos los empleados de la tabla empleados que cumplen con la condición

de no ser usuarios de sistema además haber realizado al menos una declaración, y se

cargan en la tabla dw_empleadoslookup.






pág. 100

Dimensión Turnos.

(D6)

Se seleccionan todos los registros de la tabla turnos y se cargan en la tabla dimensional

dw_turnoslookup.

Dimensión Tiempo.

(D7)

La dimensión tiempo se obtiene con la ejecución de una consulta descripta más

adelante, la cual, permite generar todos los registros necesarios para formar esta

dimensión.

Primero se obtiene el valor mínimo y máximo de fechas que se poseen entre todas las

declaraciones exigentes en la tabla producción cabecera. Luego se llama al

procedimiento “mm_proc_tiempolookup” pasándole por parámetro dichos valores. El

procedimiento genera todos los registros de fechas entre la fecha de inicio y fin que

fueron indicados.

Selección de fecha mínima y máxima de la lista de cabeceras de producción






pág. 101

Procedimiento mm_proc_tiempolookup

Dimensión Tiempo Clasificación.

(D8)

Se seleccionan todos los registros de la tabla TiempoClasificaron y se cargan en la tabla

dimensional dw_tiempoclasificacionlookup.






pág. 102

Dimensión Producto.

(D9)

Se seleccionan todos los registros de la tabla material y se cargan en la tabla

dimensional dw_productoslookup.

Lista de Tablas de Hechos

Tabla de Hechos dw_indicadores:

(H1)

Se colectan todas las cabeceras que no fueron anuladas de la tabla ProducciónCabecera

unida a las tablas producción resumen, productos y empleados, para obtener toda la

información relevante en el Hecho “Indicadores”. A esta consulta se agrega una

restricción adicional que será explicada más adelante.






pág. 103

Restricción adicional.

Tabla de Hechos dw_productividad:

(H2)

Se seleccionan los registros de la tabla ProducciónCabecera para todas las cabeceras que

no hayan sido anuladas. Todos los registros que cumplan con esta restricción son unidos

a la consulta de las siguientes tablas para obtener toda la información relevante en el

Hecho “Productividad”: ProducciónResumen, TiempoDetalle, TiempoClasificacion,

Producto, y Empleado. A esta consulta se agrega una restricción adicional que será

explicada más adelante.






pág. 104

Restricción adicional:

Tabla de Hechos dw_produccion:

(H3)

Se colectan los datos de la tabla ProducciónCabecera para todas las cabeceras que no

fueron anuladas, unida a la consulta a las siguientes tablas para completar toda la

información relevante en el Hecho “Producción”: ProducciónResumen,

ProducciónDetalle, Empleado. A esta consulta se agrega una restricción adicional que

será explicada más adelante.






pág. 105

Restricción adicional.

Proceso tabla_configuración_Completar_Fecha_Inicio.

(M3)

Proceso Transformación_CompletarFechaÚltimoProcesamiento.

(M4)






pág. 106

Tareas Adicionales

Al finalizar todas las tareas ETL esenciales, se procede a realizar algunos procesos de

mantenimiento sobre el Data Warehouse, listados a continuación:

Borrado de Hechos Anulados.

(A1)

Cleasing:

(A2)

(Fragmento del Codigo)






pág. 107

Borrado de Archivos Temporales

(A3)

Actualización de Cache.

(A4)

Restricción Adicional en Tablas de Hecho:

La restricción que se agrega a todas las consultas realizadas en las tablas de Hecho,

asegura que sean procesados solo los registros que fueron cargados de manera posterior

al último procesamiento del proceso ETL.






pág. 108

En la consulta anterior, si el campo DE_FECHA_INICIO nunca fue establecido se

tomará como referencia una fecha muy menor para completar la restricción. Además, se

hace una comprobación adicional para establecer que todos los registros sean anteriores

a la fecha establecida por el campo DW_FECHA_FIN con el objetivo de impedir que se

procesen registros insertados durante la ejecución del proceso ETL.

De esta forma queda completamente definido el mecanismo que sirve para actualizar el

Data Warehouse con la información más reciente agregada al sistema. Esto permite, sin

dudas, minimizar la carga del servidor, minimizar el tiempo de respuesta en las

consultas y mantener al sistema lo más actualizado posible en un corto tiempo.

Creación de cubos multidimensionales

A continuación se crearán los cubos multidimensionales tomando como base el modelo

lógico diseñado en los pasos anteriores con la ayuda de la metodología Hefesto.

Aunque, para ello, no sea estrictamente necesario emplear de manera rigurosa el

procedimiento descripto en el manual Hefesto. No obstante, se decidió continuar con la

construcción de los cubos de la misma manera que allí se explica, por entenderse que es

conceptualmente válido y útil en el proceso de desarrollo.

Cubo Indicadores:

Creación de Indicadores

Figura 3.28.

1. Nombre del Indicador: “Productividad”.






pág. 109

De la tabla de hechos “ProducciónResumen” se toma el hecho “CantidadTotal”, que

representa la producción total de una declaración de producción junto con el hecho

“TiempoTrabajado”, y de la tabla “Material” se obtiene el campo

“EstandarFabricación” que contiene la cantidad de piezas que debería fabricarse por

hora de cada producto. Todos estos campos son necesarios para crear el indicador

“Productividad” aplicando la siguiente fórmula:

ajadoTiempoTrab bricacion EstandarFa

100talCantidadToAVG

2. Nombre del Indicador: “Calidad”.

De la tabla de hechos “ProducciónResumen”, se toma el hecho “CantidadTotal” y el

hecho “ScrapTotal” para crear el indicador “Calidad” aplicando la siguiente Fórmula:

100talCantidadTo

ScrapTotaltalCantidadToAVG

3. Nombre del Indicador: “OEE”.

De la tabla de hechos “ProducciónResumen”, se toma el hecho “CantidadTotal” y el

hecho “ScrapTotal” para crear el indicador “Calidad” aplicando la siguiente fórmula:

100CalidaddadProductiviAVG

4. Nombre del Indicador: “Cantidad Setup”.

Se interpreta que para cada registro de la tabla “ProduccionResumen” existe un

producto que ha sido preparado mediante una operación de Setup, por lo que se aplica la

siguiente fórmula para generar el indicador “Cantidad Setup”:

(*)Count

5. Nombre del Indicador: “Tiempo Setup”.






pág. 110

De la tabla “Material”, se toma el valor del campo “TiempoSetup” para crear el

indicador “Tiempo Setup” aplicando la siguiente fórmula:

60pTiempoSetu

Representación del Cubo “Indicadores”:

Figura 3.29.

Creación de Atributos

1. De la tabla de dimensión “dw_tiemposlookup”, se tomará el campo “Anio”,

“trimestreLetra”, “mesLetra”, “semanaLetra”, “diaLetra”, “diaSemanaLetra”

para la creación de los atributos de la dimensión “Tiempo”.

2. De la tabla de dimensión “dw_procesoslookup”, se tomará el campo “Proceso”

para la creación de los atributos de la dimensión “Procesos”.

3. De la tabla de dimensión “dw_productoslookup”, se tomará el campo

“Producto” para la creación de los atributos de la dimensión “Productos”.

4. De la tabla de dimensión “dw_turnoslookup”, se tomará el campo “Turno” para

la creación de los atributos de la dimensión “Turnos”.

5. De la tabla de dimensión “dw_empleadoslookup”, se tomará el campo “Legajo”,

“Apellidos”, “Nombres”, “Dni” para la creación de los atributos de la dimensión

“Operarios”.






pág. 111

Representación del Cubo Indicadores:

Figura 3.30.

Cubo Producción:


Figura 3.31.

1. Nombre del Indicador: “Cantidad”.

De la tabla de hechos “ProducciónDetalle”, se toma el hecho “Cantidad” para crear el

indicador “Cantidad” aplicando la siguiente fórmula:

CantidadSUM






pág. 112

Representación del Cubo “Producción”:

Figura 3.32.













“Operarios”.

6. De la tabla de dimensión “dw_estadoproductoslookup”, se tomará el campo

“EstadoProducto” para la creación de los atributos de la dimensión “Estado

Producto”.

7. De la tabla de dimensión “dw_noconformidadeslookup”, se tomará el campo

“NoConformidad” para la creación de los atributos de la dimensión “No

Conformidades”.






pág. 113

Representación del Cubo Producción:

Figura 3.33.

Cubo Productividad:


1. Nombre del Indicador: “Horas”.

De la tabla de hechos “ProducciónTiempoDetalle”, se toma el hecho “TiempoFloat”

para crear el indicador “Horas” aplicando la siguiente fórmula:

tTiempoFloaSUM

Representación del Cubo “Productividad”:

Figura 3.34.






pág. 114













“Operarios”.

6. De la tabla de dimensión “dw_tiempoclasificacionlookup”, se tomará el campo

“TiempoClasificación” para la creación de los atributos de la dimensión

“Tiempo_Clasificaciones”.

7. De la tabla de dimensión “dw_paradasnoprogramadaslookup”, se tomará el

campo “ParadaNoProgramada” para la creación de los atributos de la dimensión

“Parada_No_Programadas”.

Representación del Cubo Productividad:

Figura 3.35.

Creación de Jerarquías

Por último se procede con la creación de las jerarquías a los distintos cubos

multidimensionales:






pág. 115

Dimensión Tiempo:

1. Se definió la jerarquía “Por Anio” para el atributo “Por Anio”, que se aplicará

sobre los atributos recientemente creados, “Anio”, “Trimestre”, “MesLargo”,

“Semana”, “Día”, “Día de la Semana”:

Gráficamente:

Figura 3.36.

Dimensión Operarios:

1. Se definió la jerarquía “Empleados Por Nombre” para el atributo “Operarios”,

que se aplicará sobre los atributos disponibles recientemente creados:

“Nombre”:

2. Se definió la jerarquía “Empleados Por Nombre” para el atributo “Operarios”,

que se aplicará sobre los atributos disponibles recientemente creados: “Legajo”:

Gráficamente:

Figura 3.37.






pág. 116

CONCRECIÓN DEL MODELO






pág. 117

En esta etapa del proyecto se lleva a cabo la concreción del sistema. Aquí, se describe

cómo se realizó la implementación de la plataforma, cuáles fueron las pruebas

realizadas y qué resultados se obtuvieron al finalizar la instalación. Más adelante, se

exponene las experiencias alcanzadas por los usuarios con el empleo de las herramientas

instaladas y, por último, se detallan los métodos de puesta en marcha desarrollados en

este proyecto.

Implementación:

Lenguajes de Programación

Los reportes publicados con la plataforma Pentaho fueron generados con el empleo de

lenguajes de programación y marcación web. Los artefactos que se construyen con el

empleo de estos lenguajes, trabajan de manera colaborativa para generar informes

dinámicos. El resultado de utilizar de estas técnicas de desarrollo es poder representar

gran volumen de información de manera sencilla para facilitar su interpretación. Estos

informes permiten que los usuarios naveguen entre los resultados, cambien las

perspectivas de análisis de manera dinámica y puedan obtener respuestas a demanda

para cada uno de sus interrogantes, permitiéndoles incluso, aumentar o reducir el nivel

de detalle de la información consultada.

A continuación de describen los lenguajes de programación y marcación utilizados para

generar el Panel de Gestión desarrollado en este proyecto:

HTML

HTML, acrónimo de HyperText Markup Language (Lenguaje de Marcado de

Hipertexto), es el lenguaje de marcado predominante para la elaboración de páginas

web. Se emplea para describir la estructura y el contenido de una página web mediante

texto. HTML se escribe en forma de "etiquetas", identificadas por corchetes angulares

(<,>). El mismo puede describir, hasta cierto punto, la apariencia de un documento. Por

otra parte, permite la inclusión de diversos script (por ejemplo Javascript), para

modificar y enriquecer el comportamiento de los navegadores web del cliente.

JavaScript

JavaScript es un lenguaje de scripting basado en objetos y utilizado para acceder, a su

vez, a otros objetos de aplicaciones externas. Principalmente, se utiliza en un navegador

web para permitir el desarrollo de interfaces de usuario mejoradas y páginas web

dinámicas.

Todos los navegadores modernos interpretan el código JavaScript que se encuentra

embebido dentro de las páginas web. JavaScript corre dentro del agente de usuario, y se

http://es.wikipedia.org/wiki/Lenguaje_de_marcado

http://es.wikipedia.org/wiki/P%C3%A1ginas_web

http://es.wikipedia.org/wiki/P%C3%A1ginas_web

http://es.wikipedia.org/wiki/Par%C3%A9ntesis

http://es.wikipedia.org/wiki/Gui%C3%B3n_%28inform%C3%A1tica%29

http://es.wikipedia.org/wiki/Javascript

http://es.wikipedia.org/wiki/Navegadores_web

http://es.wikipedia.org/wiki/Script_%28inform%C3%A1tica%29

http://es.wikipedia.org/wiki/Navegador_web

http://es.wikipedia.org/wiki/Navegador_web

http://es.wikipedia.org/wiki/Interfaz_de_usuario

http://es.wikipedia.org/wiki/P%C3%A1gina_web

http://es.wikipedia.org/wiki/Agentes_de_usuario






pág. 118

ejecuta al mismo tiempo en el que las sentencias se van descargando junto con el código

HTML.

Xaction o Secuencias de Acción

Todas las actividades realizadas en la Plataforma Pentaho BI se definen por Secuencias

de Accion definidas dentro de documentos XML. Las secuencias de acción describen

las diferentes actividades que se pueden realizar en un momento dado, como son las

consultas de base de datos, la generación de informes, los envió de e-mail. Además,

éstas definen el orden en que las acciones encadenadas ocurren. Toda la información

generada dentro de una secuencia de acción puede transmitirse a otras acciones dentro

de una misma sesión de usuario.

Internamente las secuencias de acción definen cuales son los elementos deben estar

disponibles para la ejecución (las entradas), los procesos que se llevarán a cabo (el

workflow) y los resultados que estarán disponibles cuando la tarea haya finalizado.

Para generar todos estos artefactos es posible utilizar la herramienta llamada “Action

Secuence Editor” que viene disponible como un plugin de Eclipse. Esta herramienta

permite los desarrolladores crear y editar secuencias de acción dentro de las soluciones

propias de Pentaho.

AmCharts

AmCharts es un script escrito en lenguaje PHP y Flash que sirve para generar gráficos

animados y cuadros estadísticos muy atractivos y elegantes. Estos gráficos se crean a

partir de información estadística entregada en un formato adecuado pasada como

parámetro. Para ello, es necesario abastecer la fuente de datos que se desea representar

en un archivo XML o un archivo CSV correctamente formateado.

AmCharts permite crear visualizaciones tanto en 2 dimensiones o en 3 dimensiones.

Además, brinda la posibilidad de modificar diversos parámetros para personalizar las

gráficas según cada situación, como por ejemplo, el radio y el ángulo de las gráficas; la

posición de los objetos (etiquetas, leyendas, títulos, fuente); los colores de todos los

elementos, el fondo, etc.

A continuación se muestran algunos gráficos de ejemplos construidos con la

herramienta AmChars.

http://es.wikipedia.org/wiki/HTML






pág. 119

o Gráfico de tipo Torta

Figura 4.1.

o Gráfico de Serie en función del Tiempo

Figura 4.2.






pág. 120

o Gráfico de Barras

Figura 4.3.

JQuery.

JQuery es una biblioteca de JavaScript que permite interactuar más fácilmente con los

documentos HTML, manipular el árbol DOM, manejar eventos, desarrollar animaciones

y agregar interacción con la tecnología AJAX a páginas web. El mismo es un software

de código abierto por lo que es libre su utilización para proyectos privados. Esta

herramienta se utiliza para construir las pantallas del Panel de Gestión de la aplicación

construida en esta implementación.

A continuación de muestran algunos componentes de ejemplo que vienen incluidas en

las librerías de Jquery.

http://es.wikipedia.org/wiki/Biblioteca_(inform%C3%A1tica)

http://es.wikipedia.org/wiki/JavaScript

http://es.wikipedia.org/wiki/HTML

http://es.wikipedia.org/wiki/Document_Object_Model

http://es.wikipedia.org/wiki/AJAX

http://es.wikipedia.org/wiki/Software_libre_y_de_c%C3%B3digo_abierto

http://es.wikipedia.org/wiki/Software_libre_y_de_c%C3%B3digo_abierto






pág. 121

o Selector de Fecha

Figura 4.4.

o Divisor de Paneles tipo Tabulado

Figura 4.5.

o Divisor de Paneles tipo Acordeón

Figura 4.6.






pág. 122

Arquitectura y componentes

La plataforma Pentaho tiene un esquema de tipo Cliente-Servidor. Esta plataforma,

consta de un servicio web que se ejecuta en un equipo servidor desde donde se brinda

un punto de acceso para todas las consultas de negocio.

Adoptando esta arquitectura, se diseñó para Magneti Marelli un servidor preparado para

soportar todos los servicios requeridos que incluye: el servicio Web propio de Pentaho,

un servidor de Base de Datos, el motor Mondrian contenido en la plataforma Pentaho, y

el conjunto de procesos ETL ejecutados con una de las herramientas provistas por el

mismo fabricante, conocida como Pentaho Data Integration.

A continuación se muestra el diagrama de componentes:

Arquitectura Física

Figura 4.7.

Esquema de directorios y artefactos

La aplicación desarrollada en este trabajo de tesis fue implementada íntegramente sobre

una plataforma Windows, por lo tanto todas las herramientas descriptas y los pasos

indicados en esta sección, estarán sujetos al empleo de dicha arquitectura.

A continuación se describen cada uno de los pasos necesarios para dejar completamente

operativo el servidor requerido para esta implementación:

Instalación de Java Runtime Environment






pág. 123

La plataforma Pentaho es una aplicación que requiere para su ejecución tener instalado

el complemento de Java JRE (Java Runtime Environment) en la misma terminal.

En los pasos siguientes se describe como realizar la instalación del JRE específicamente

en un sistema operativo compatible con Windows.

1. Ingresar a la dirección web indicada y descargar el instalador del JRE (Java

Runtime Environment):

http://javadl.sun.com/webapps/download/AutoDL?BundleId=41723.

Cuando se haya descargado el ejecutable, se debe hacer doble clic en él para iniciar la

instalación.

Figura 4.8.

Lo primero que debemos seleccionar es el tipo de instalación. Se sugiere escoger la

instalación típica, por ser la más sencilla y rápida. En este paso, es necesario leer y

aceptar la licencia del software que se encuentra en la sección “Contrato de licencia”

dentro de la pantalla de instalación. Se debe aceptar la licencia para comenzar la

instalación, pulsando el botón Aceptar.

http://www.ayudabittorrent.com/descargar-jre

http://www.ayudabittorrent.com/descargar-jre

http://javadl.sun.com/webapps/download/AutoDL?BundleId=41723






pág. 124

Figura 4.9.

En este momento se produce la instalación del software.

Figura 4.10.

Luego pulse en el botón Finalizar para terminar el proceso de instalación.

2. El siguiente paso es establecer la variable global “JAVA_HOME” del sistema

operativo para que Pentaho pueda detectar cuál es el JRE disponible. Para esto,






pág. 125

es necesario abrir el panel de Propiedades del Sistema Operativo de Windows

por medio del comando “sysdm.cpl” ejecutado en una consola de MsDOS.

Figura 4.11.

3. Dentro de las Opciones Avanzadas del Panel de Propiedades del Sistema, hacer

clic en la opción Variables de Entorno.

Figura 4.12.

4. En paso siguiente es necesario presionar el botón “Nueva” de la sección inferior

que hace referencia a las “Variables del Sistema”.






pág. 126

Figura 4.13.

5. El último paso es establecer el valor de la variable JAVA_HOME con la ruta a

directorio de instalación del JRE que se estableció durante la instalación en los

pasos anteriores. Es necesario Aceptar todo y finalmente reiniciar el sistema.

Figura 4.14.

Instalación de MySQL

Para instalar adecuadamente MySql en el Servidor debemos seguir los siguientes pasos:

1. Antes de comenzar es necesario dirigirse a la www.mysql.com y descargar el

binario "Windows (x86) ZIP/Setup.EXE (versión 5.0.27)" al escritorio de

trabajo (directorio a elección). Para poder hacer esto, usted necesitará estar

registrado con una cuenta creada en la página de MySQL.

2. Una vez que haya descargado el paquete "mysql-5.0.27-win32.zip", se podrá

extraer el mismo usando WinZip o alguna aplicación de empaquetado similar.

http://dev.mysql.com/downloads/mysql/5.0.html#downloads






pág. 127

3. Cuando hayan extraído los archivos, haga doble clic sobre el ejecutable

“Setup.exe”. Al hacer esto, se iniciará automáticamente el asistente para la

instalación de MySQL.

Figura 4.15.

Presione "Next".

4. Elija el tipo de instalación "Typical" y presione "Next".

5. Presione el botón "Install" para comenzar la instalación. (Sea paciente, esta

operación puede demorar unos minutos).

6. La pantalla que aparece a continuación le preguntará a usted si desea

subscribirse en la página oficial de MySql. Aquí puede seleccionar "Skip Sign-

Up" para saltear este paso.

7. A continuación, aparecerá una pantalla dando aviso de que el proceso de

instalación ha concluido. Asegúrese que la opción "Configure the MySQL

Server now" este seleccionada y luego presione el botón "Finish".






pág. 128

Figura 4.16.

8. Si todo ha ido bien, el asistente para la configuración de la instancia de MySql

debería aparecer. Haga clic en "Next".

9. Seleccione "Detailed Configuration" y presione "Next".

10. Seleccione "Developer Machine" y presione "Next".

11. Seleccione "Multifunctional Database" y presione "Next".

12. Presione "Next".

13. Seleccione "Decision Support (DSS)/OLAP" y presione "Next".

14. Seleccione "Multifunctional Database" y presione "Next".

15. Asegúrese que la opción "Enable TCP/IP Networking" este seleccionada, que el

Puerto este configurado con el valor "3306", y que la opción "Enable Strict

Mode" también este seleccionada. Presione "Next".

16. Elija "Standard Character Set" y presione "Next".

17. Seleccione "Install As Windows Service", configure el nombre del Servicio con

"MySQL", y elija la opción "Launch the MySQL Server automatically".

Compruebe que la opción "Include Bin Directory in Windows Path" NO este

seleccionada. Presione "Next".

18. En la siguiente pantalla, seleccione la opción que dice "Modify Security

Settings". Ingrese una contraseña para la cuenta de usuario por defecto "root", y

confirme la clave en la entrada de texto que está debajo. Deje sin seleccionar la

opción "Enable root access from remote machines" or "Create An Anonymous

Account". Presione "Next".

19. Haga clic en "Execute". (Esta operación puede tardar algunos minutos. Sea

paciente).






pág. 129

20. Presione "Finish".

21. Para verificar si MySQL fue instalado correctamente, vaya a: Inicio > Todos los

Programas> MySQL > MySQL Server 5.0 > MySQL Command Line Client. Al

hacer esto, el cliente de línea de comando de MySQL aparecerá:

Figura 4.17.

22. Al iniciarse la ventana quedará esperando que ingrese una contraseña. Ingrese la

contraseña que especificó en el paso 18. (Si usted ingreso una contraseña

incorrecta, MySQL automáticamente cerrará la línea de comando)

23. A continuación, escriba los comandos que a se muestran abajo resaltados:

Figura 4.18.

Si se muestra la información como esta en la imagen anterior, entonces MySQL ha

sido instalado correctamente.

Instalación de Pentaho






pág. 130

1. Lo primero es ingresar a la página Web donde están publicados los archivos

necesarios para la instalación del servidor Pentaho. Por lo que debemos ingresar

a la página http://sourceforge.net/projects/pentaho/files/ y descargar el paquete

biserver-ce-3.6.0-stable.zip.

2. A continuación se debe especificar el directorio donde vamos a instalar el

servidor Pentaho, y extraemos los archivos en el directorio seleccionado. Por

ejemplo: “C:\Archivos de programa\Pentaho\biserver-ce”.

3. De aquí en más, se hará referencia al directorio de instalación como

[PENTAHO_HOME]. Así, por ejemplo, cuando se haga referencia al directorio

[PENTAHO_HOME]/pentaho-solutions, se estará hablando del directorio

“C:\Archivos de programa\Pentaho\biserver-ce\pentaho-solutions” para esta

implementación en particular.

Figura 4.19.

Figura 4.20.

Configuración de Pentaho para trabajar con MySQL

Lo siguiente es configurar Pentaho para trabajar con MySQL. Es decir que tendremos

que migrar todas las bases de datos propias de Pentaho. (Las del repositorio, la base de

datos de configuración de Pentaho y la base de datos de ejemplos que vienen dentro del

paquete Pentaho CE).

http://sourceforge.net/projects/pentaho/files/

http://sourceforge.net/projects/pentaho/files/Business%20Intelligence%20Server/3.6.0-stable/biserver-ce-3.6.0-stable.zip/download






pág. 131

1. Lo primero es ubicar los archivos que contienen los scripts necesarios para

realizar la migración, que se encuentran en el directorio

“[PENTAHO_HOME]\biserver-ce\data\mysql5” del servidor Pentaho:

create_repository_mysql.sql

create_quartz_mysql.sql

create_sample_datasource_mysql.sql

migration.sql

sampledatamysql5.sql

2. El siguiente paso es ingresar, por línea de comando, al cliente de MySQL como

se muestra a continuación:

Figura 4.21.

3. Ahora es necesario ejecutar los comandos:

mysql> source “[PENTAHO_HOME]\biserver-

ce\data\mysql5\create_repository_mysql.sql”;


ce\data\mysql5\create_quartz_mysql.sql”;


ce\data\mysql5\create_sample_datasource_mysql.sql”;

mysql> source “[PENTAHO_HOME]\biserver-ce\data\mysql5\migration.sql”;

mysql> source “[PENTAHO_HOME]\biserver-ce\data\mysql5\sampledatamysql5.sql”;

4. Verificamos con el siguiente comando si las bases de datos se importaron

correctamente:






pág. 132

mysql> show databases;

+--------------------+

| Database |

+--------------------+

| information_schema |

| hibernate |

| mysql |

| quartz |

| sampledata |

+--------------------+

5 rows in set (0.01 sec)

Luego de correr estos comandos se deberían poder ver las bases de datos hibernate,

quartz y sampledata que fueron creadas.

5. Localizamos y editamos el archivo de configuración applicationContext-spring-

security-hibernate.properties. Aquí es necesario establecer los parámetros de

conexión que necesitamos para ingresar al servidor MySQL (dirección, usuario

y contraseña), como se muestra a continuación:

Figura 4.22.

Figura 4.23.






pág. 133

Figura 4.24.

6. Al igual que en el paso 5, hacemos lo mismo con el archivo de configuración

applicationContext-spring-security-jdbc.xml:

Figura 4.25.

Figura 4.26.

Figura 4.27.

7. A continuación buscamos el archivo de configuración hibernate-settings.xml y

lo editamos como se muestra más abajo. En este paso, es necesario indicarle al

servidor Pentaho donde se encuentra alojado el archivo de conexión con la base

de datos MySQL:






pág. 134

Figura 4.28.

Figura 4.29.

Figura 4.30.

8. Procedemos como en el paso 5, modificando la configuración del archivo

mysql5.hibernate.cfg.xml:

Figura 4.31.

Figura 4.32.






pág. 135

Figura 4.33.

Nota: Aquí es necesario establecer ciertos parámetros adicionales para que la conexión

con la base de datos se realice utilizando el Driver C3P0. Esto permitirá a Pentaho

conectarse a la base de datos a través de un Pool de Conexiones. Es importante que se

agreguen todos los parámetros como se indican en la imagen. Guardamos y cerramos el

archivo.

9. Buscamos y editamos el archivo de configuración web.xml del servidor Tomcat

incluido en el Servidor Pentaho:

Aquí es necesario establecer el nombre del servidor y el puerto en el que se va a

trabajar. Si se desea cambiar este puerto, también es necesario establecer la nueva

configuración dentro del archivo de configuración del servidor Apache Tomcat que

viene dentro en la Plataforma Pentaho. Más abajo se muestra como realizar esta

operación.

Figura 4.34.






pág. 136

Figura 4.35.

Figura 4.36.

Para configurar el servicio Web se debe localizar el archivo server.xml del servidor

Tomcat y modificar las variables del servidor con los valores establecidos según

corresponda. Por ejemplo, es posible ingresar un puerto de acceso diferente al servicio

que viene establecido por defecto (8080). Una vez que se guarden los cambios en este

archivo, es necesario reiniciar el servicio para que la aplicación tome en cuenta los

nuevos parámetros.

Figura 4.37.

Figura 4.38.






pág. 137

Figura 4.39.

10. Buscamos y editamos el archivo de configuración del servidor Tomcat del

Servidor Pentaho context.xml para establecer los datos de la conexión a la base

de datos:

Figura 4.40.

Figura 4.41.

Figura 4.42.

11. A partir de este momento se está en condiciones de iniciar el servidor Pentaho.

Para esto es necesario ejecutar el archivo start-pentaho.bat.

Figura 4.43.






pág. 138

Figura 4.44.

Pentaho Administration Console

Para empezar a usar Pentaho Administration Console no es necesario realizar ninguna

tarea adicional debido a que el mismo ya viene incluido dentro del paquete Pentaho-CE

que se ha instalado en los pasos anteriores. Esta herramienta está preparada para

conectarse con la plataforma Pentaho de manera automática.

Es conveniente mencionar que para utilizar esta aplicación en un ambiente productivo

es altamente recomendable establecer una contraseña de acceso diferente a la que viene

configurada por defecto para aumentar el nivel de seguridad del sistema. Para poder

realizar esta operación es necesario emplear librerías Jetty incluidas en el paquete

Pentaho.

1. Comprobamos la existencia de las librerías necesarias, como se ve en la

siguiente imagen:

Figura 4.45.

Figura 4.46.






pág. 139

2. Confeccionamos el comando para generar la contraseña, agregamos la clave

seleccionada y ejecutamos el mismo, como se muestra a continuación.

Figura 4.47.

Copiamos la contraseña de tipo OBF que generamos y la pegamos en al archivo

login.properties.

Figura 4.48.

Figura 4.49.

Figura 4.50.

Pentaho Data Intergration

Para instalar PDI es necesario tener instalado Java Runtime Environment (JRE) versión

1.5 o superior. Esta tarea ya se ha realizado en pasos anteriores cuando se instaló el

paquete Pentaho CE. Para comenzar la instalación de PDI es necesario descargar el

programa Kettle, desde la siguiente dirección web:






pág. 140

http://sourceforge.net/projects/pentaho/files/Data%20Integration/3.2.0-stable/

Se debe descomprimir el archivo descargado en el directorio de instalación seleccionado

y a partir de ese momento ya es posible acceder a la aplicación iniciando el archivo

Spoon.bat.

Figura 4.51.

http://sourceforge.net/projects/pentaho/files/Data%20Integration/3.2.0-stable/






pág. 141

Figura 4.52.

Herramientas Adicionales

Instalación wget

Wget es una herramienta útil para realizar peticiones Web en diversos protocolos, como

HTTP o FTP. Esta herramienta será empleada en las tareas de actualización de cache

como veremos en la construcción de los procesos ETL.

Para instalar esta herramienta se debe descargar la aplicación desde la URL indicada a

continuación y extraer el ejecutable wget.exe al directorio de instalación del sistema

operativo Windows: “%systemroot%/System32”. Otra alternativa es ubicar el archivo

en un directorio arbitrario e indicar, posteriormente, su ruta en la variable de entorno del

Sistema Operativo correspondiente (“Path”) para poder invocar el programa desde la

línea de comando.

http://www.interlog.com/~tcharron/wgetwin-1_5_3_1-binary.zip

Figura 4.53.

Figura 4.54.

http://www.interlog.com/~tcharron/wgetwin-1_5_3_1-binary.zip






pág. 142

Pentaho Report Designer

Pentaho Report Designer es una herramienta de Reporting del proyecto JFreeReport, La

misma permite la creación rápida informes sofisticados y visualmente ricos. Esta

herramienta cuenta con un entorno gráfico bastante intuitivo y fácil de utilizar. Además

tiene una estructura muy flexible que permite, al diseñador, generar reportes que se

adapten totalmente al gusto y la necesidad de los usuarios.

1. Para instalar PRD es necesario dirigirse a la página de SourceForge y descargar

el paquete prd-ce-3.6.1-stable.zip.


2. El siguiente paso es extraer los archivos en el directorio de instalación elegido.

Una vez extraídos los archivos, la herramienta está lista para ser utilizada.

Figura 4.55.

Figura 4.56.

La aplicación se inicia ejecutando el archivo report-designer.bat.

http://sourceforge.net/projects/pentaho/files/Report%20Designer/3.6.1-stable/prd-ce-3.6.1-stable.zip/download







pág. 143

Java Developer Kit

Para usar Pentaho Design Studio, herramienta que será utilizada más adelante, es

necesario tener instalado el Java Deverloper Kit. Esta es un una aplicación de java

requerida para poder ejecutar las herramientas de desarrollo basados en java. La

herramienta Pentaho Design Studio, está soportada sobre una plataforma de

desarrollo Eclipse. La cual requiere, como dijimos, tener instalado JDK. A

continuación se describen los pasos necesarios para realizar esta tarea:

1. Para instalar JDK, es necesario dirigirse a la página de Oracle y descargar el

paquete jdk-7-windows-i586.exe desde la siguiente dirección:

http://www.oracle.com/technetwork/java/javase/downloads/java-se-jdk-7-

download-432154.html

Una vez descargado el archivo, se debe hacer doble clic sobre el instalador para iniciar

la instalación.

Figura 4.57.

http://sourceforge.net/projects/pentaho/files/Design%20Studio/3.6.0-stable/pds-ce-win-3.6.0-stable.zip/download

http://www.oracle.com/technetwork/java/javase/downloads/java-se-jdk-7-download-432154.html

http://www.oracle.com/technetwork/java/javase/downloads/java-se-jdk-7-download-432154.html






pág. 144

2. Para comenzar se debe hacer clic en el botón “Next”.

Figura 4.58.

3. En este paso, es posible establecer el directorio de instalación para el JDK

diferente al que viene establecido por defecto. Una vez definido, es necesario

presionar el botón “Next” para continuar.

Figura 4.59.






pág. 145

4. En este paso, el asistente permite establecer un directorio de instalación para el

JRE (Java Runtime Enviroment) que viene incluido dentro en el JDK o aceptar

el directorio propuesto por defecto. Una vez establecido el directorio, es

necesario presionar el botón “Next”.

Figura 4.60.

5. El asistente de instalación confirma que el proceso de instalación ha finalizado

correctamente. Es necesario presionar el botón “Finish” para salir del asistente.

Pentaho Design Studio

PDS es un entorno de desarrollo gráfico implementado sobre una solución Eclipse, que

cuenta con un complemento (Plugin) específico de Pentaho para la creación de

Xactions.

1. Para instalar PDS, es necesario dirigirse a la página de SourceForge y descargar

el paquete pds-ce-win-3.6.0-stable.zip


2. El paso siguiente es extraer los archivos descargados en el directorio de

instalación seleccionado.

http://sourceforge.net/projects/pentaho/files/Design%20Studio/3.6.0-stable/pds-ce-win-3.6.0-stable.zip/download







pág. 146

Figura 4.61.

Figura 4.62.

Como mencionamos en los pasos previos, es necesario tener instalado el Kid de

Desarrollo JDK para poder ejecutar esta herramienta. Llegado a este momento es

posible abrir la aplicación ejecutando el archivo eclipse.exe.

Confección de Cubos OLAP

Los cubos OLAP de Mondrian utilizados en este proyecto se generan mediante el

empleo de la herramienta gráfica schema-Workbench. Esta herramienta permite generar

una serie de archivos XML que contienen información estructurada con la

configuración de los modelos utilizados por el motor Mondrian. Es necesario aclarar

que estos archivos no contienen ningún tipo de datos, solo incluyen Metadata. Es decir,

información adicional del modelo que permite describir como es el esquema de cada

uno de los cubos construidos.






pág. 147

Cubo Producción

Figura 4.63.

Figura 4.64.

Utilizando la herramienta schema-workbench, se crea el archivo Produccion.xml que

contiene la Metadata del Cubo Produccion para Mondrian y se lo deposita dentro del

directorio de trabajo de Pentaho.

Figura 4.65.

Figura 4.66.

Cubo Productividad






pág. 148

Figura 4.67.

Figura 4.68.

De la misma manera que antes, se genera el archivo Productividad.xml que contiene la

Metadata del Cubo Productividad para Mondrian y se lo deposita dentro del directorio

de trabajo de Pentaho.

Figura 4.69.






pág. 149

Figura 4.70.

Cubo Indicadores

Figura 4.71.

Figura 4.72.

Se genera también el archivo archivo Indicadores.xml que contiene la Metadata del

Cubo Indicadores para Mondrian y se lo deposita dentro del directorio de trabajo de

Pentaho.

Figura 4.73.






pág. 150

Figura 4.74.

Finalmente, se indica dentro del archivo de configuración de Pentaho cuáles son los

Cubos y donde se encuentran los archivos que contienen la Metadata para que sean

procesados por el Motor Mondrian.

Figura 4.75.

Figura 4.76.

Figura 4.77.

Luego de modificar este en archivo de configuraron es necesario reiniciar el servidor

Pentaho para que se actualicen los cambios. Siempre que se altere la configuración en

cualquiera de los archivos propio de la plataforma Pentaho, como el que acabamos de

editar, es necesario reiniciar el Servidor. Para realizar esta operación debemos ejecutar

el archivo stop-pentaho.bat, con lo que se detendrá el servicio y luego ejecutar el

archivo start-pentaho.bat para iniciar nuevamente la aplicación.






pág. 151

Figura 4.78.

Figura 4.79.

Figura 4.80.

Instalación de Rapid Miner.

La plataforma Rapid Miner presenta un entorno completo para el tratamiento, la

transformación, el modelado y el análisis masivo de datos. Fue seleccionada para

realizar las operaciones de minería sobre datos, principalmente, por ofrecer una extensa

variedad de opciones para el modelado y por presentar una notable sencillez a la hora de

trabajar con ella.

En la esta sección se mostrará cómo realizar la instalación de ésta herramienta.

1. Lo primero que hay que hacer es dirigirse a la página del proyecto Rapid Miner

y descargar la última versión disponible de la aplicación desde la dirección web

indicada a continuación:

http://rapid-i.com

2. Nos dirigimos a la sección Descargas y dentro de ella, seleccionamos Rapid

Miner.

http://rapid-i.com/






pág. 152

3. Elegimos la plataforma en la que vamos a instalar la aplicación (en este caso

Windows), completamos el formulario de registro requerido y completamos la

descarga.

Figura 4.81.

Figura 4.81.






pág. 153

4. Una vez que se obtiene el instalador, procedemos a ejecutarlo.

Figura 4.82.

5. Una vez que comienza el proceso de Instalación, presionamos el botón “Next”.

Figura 4.82.

6. Para continuar es necesario leer y aceptar la licencia del software que se

encuentra en la sección “License Agreement” dentro de la pantalla de

instalación. Debemos aceptar la licencia presionando el botón “I Agree”.






pág. 154

Figura 4.83.

7. En el siguiente paso es necesario definir el directorio de instalación de la

herramienta. A continuación, se debe presionar el botón “Instalar” para

comenzar el proceso.

Figura 4.84.






pág. 155

Confección del Repositorio de Trabajo

Lo primero que se debe realizar en RapidMiner es crear el repositorio de trabajo. El

repositorio es el contenedor de los componentes y las configuraciones de cualquier

proyecto creado en RapidMiner.

Para ello se utilizará la opción crear nuevo repositorio desde el menú: “File > New”.

Figura 4.85.

Una vez creado el repositorio es necesario importar una tabla de base de datos para

trabajar con ella. Con esto, logramos tener acceso a los datos del Data Warehouse.

Como en este caso, el almacén es una base de datos, se debe seleccionar el método de

importación de datos para conexiones a bases de datos.






pág. 156

Figura 4.86.

1. El asistente de importación solicita los datos de la conexión del servidor de base

de datos donde está contenido el Data Warehouse. Aquí, debemos llenar los

parámetros validos de conexión a base de datos.

Figura 4.87.

2. El siguiente paso es diseñar la consulta SQL que se ha de ejecutar contra la base

de datos para obtener todos los registros que se quieren analizar en el proceso de

Data Minning. En nuestro caso, seleccionamos la tabla de hechos

“dw_indicadores” unida al resto de las tablas de dimensiones afectadas. Las

uniones establecidas a las tablas de dimensión son necesarias si se prefiere ver,






pág. 157

posteriormente, las descripciones de cada atributo y no solo los identificadores

de cada campo. De ser necesario, también es posible aplicar en este momento

algún criterio de filtrado sobre los datos para reducir, lo más posible, la carga en

el procesamiento y mejorar la eficiencia de las consultas, quitando para ello,

cualquier información que resulte innecesaria para los análisis.

Figura 4.88.

3. El paso siguiente es agregar un identificador al proceso de consulta y presionar

el botón de finalizar.






pág. 158

Figura 4.89.

Comprobar la Importación

A partir de aquí se puede comenzar a trabajar con los datos. Si se le da doble click al

proceso de importación recién creado, es posible explorar los registros devueltos por el

motor de consulta de RapidMiner.






pág. 159

Figura 4.90.

El asistente nos preguntará si deseamos trasladarnos a la perspectiva de vista previa.

Debemos contestar “YES”.

Figura 4.91.






pág. 160

Exploración de los Resultados.

La perspectiva “Vista de Resultados” está dividida en cuatro partes. Ellas son: “Meta

Data View”, “Data View”, “Plot View” y la sección “Annotations”.

En esta sección se describirán las primeras tres secciones.

o Meta Data View

Esta vista contiene una pre-visualización de la Metadata, es decir de la información que

se conoce a cerca de los datos. Como puede ser, el nombre del campo, el tipo de datos,

el rango, entre otras características.

Figura 4.92.






pág. 161

o Data View

En esta vista podemos observar la colección de datos almacenados en la base de datos

que responden a la consulta de importación antes generada. Es importante mencionar

que, como existe un proceso de importación previo que emplea una consulta de base de

datos, es posible que los datos estén filtrados. Por ello, es muy importante conocer el

criterio de búsqueda antes de estudiar estos datos en profundidad.

Figura 4.93.

o Plot View

La opción “Plot View” es la que nos permite acceder a la herramienta de representación

de datos. Es una de las principales secciones que tiene el software y es, de hecho, una de

las pantallas más importantes. Esta vista nos permite generar los gráficos necesarios

para analizar los patrones encontrados dentro de una población de datos. También

ofrece una paleta de opciones con, la cual, el analista podrá elegir el tipo de gráfico más

conveniente para un determinado análisis, elegir manera más adecuada para mostrar los

datos y establecer los parámetros necesarios en función de cada uno de ellos.






pág. 162

Figura 4.94.

Prueba General del Sistema

En esta sección se va a presentar el Panel de Gestión que se construyó basado en el

modelo de datos que se diseñó para la empresa Magneti Marelli. Se dará una

descripción de cada una de las pantallas a las que se puede acceder desde la página web

y la información que se puede extraer de ella. De manera posterior se analizará si la

aplicación construida alcanzo a satisfacer las necesidades que la organización planteo al

inicio del desarrollo.

Reportes obtenidos con el Sistema de Inteligencia de Negocio

1. Panel de Gestión Gerencial.

El panel de gestión está dividido en dos secciones principales. La sección denominada

“Filtro”, es la que permite seleccionar las diferentes perspectivas de análisis desde

donde usuario puede elegir y combinar cada uno de los elementos de interés a analizar.

Por ejemplo, pude seleccionar para el análisis un turno, un proceso, un producto o un

trabajador determinado. También puede, en misma ventana, elegir el día exacto en el

que desea focalizar el análisis y, si lo desea, puede elegir un período de fecha completo.






pág. 163

Una vez que el usuario establece el criterio deseado, la página automáticamente se

actualiza para presentar los resultados de la consulta realizada dentro del panel de

información que se encuentra más abajo.

Filtro:

Figura 5.1.

Debajo del panel de Filtro se encuentra el “Panel de Información” donde se presentan

los resultados. Este panel está separado en varias ventanas que son accesibles mediante

un menú horizontal ubicado en la parte superior. El cuál permite al usuario navegar

entre los diferentes gráficos y tablas según la necesidad que se tenga.

Panel de Información:

Pestaña “Rendimiento”

Dentro de la Sección Rendimiento se despliegan dos nuevas pestañas.

o Pestaña “Indicadores”

Esta ventana muestra el estado de los Indicadores de Gestión Calidad, Productividad e

OEE de toda la organización, o parte de ella si se especifica algún criterio diferente en

el panel de Filtro. Por ejemplo, se puede ver el rendimiento general de un Turno, o de

un Proceso determinado, e incluso combinarlas. Es decir, obtener el rendimiento de un

Proceso en un Turno seleccionado.






pág. 164

Figura 5.2. Todos los valores expuestos son solamente demostrativos y no representan la realidad.

o Evolución de los Indicadores

Este panel presenta el estado de los indicadores en un período de tiempo seleccionado.







pág. 165

Pestaña “Calidad”

Esta sección agrupa todos los informes que están relacionados con el análisis de la

Calidad en la organización.

o Pestaña “Evolución de la Producción”

La primera pestaña muestra la cantidad de piezas producidas en la empresa. En color

verde se muestran las piezas Producidas OK y en rojo las piezas defectuosas. En la

misma ventana se pueden ver los totales de producción en todo el período de tiempo

seleccionado.


o Pestaña “Distribución del Scrap por Causa”

Pestaña “Gráfico”

Esta ventana muestra las Cantidades de Piezas Defectuosas totales agrupadas en cada

una de las Causas de Falla. El gráfico tiene una disposición de tipo torta.






pág. 166


Pestaña “Tabla”

La misma información que se detalla en la pestaña anterior se presenta en esta sección

en forma de tabla. Las diferentes causas de defectos y las cantidades totales para cada

una de ellas.







pág. 167

o Pestaña “Distribución del Scrap por Producto”

Esta ventana muestra un gráfico de barras con las cantidades de piezas defectuosas

obtenidas en cada uno de los productos fabricados de mayor a menor incidencia.

Comúnmente este gráfico es conocido como Diagrama Pareto utilizado para conocer

rápidamente la frecuencia de problemas en orden de importancia.


o Pestaña “Evolución del Scrap”

El último gráfico de la sección de Calidad muestra las cantidades de piezas defectuosas

en función del tiempo.







pág. 168

Pestaña “Productividad”

Esta sección agrupa todas las salidas que están relacionadas con el estudio de la

Productividad de la organización.

o Pestaña “Evolución de la Productividad”

La primera pestaña muestra las cantidades de horas trabajadas en la empresa. En color

naranja se muestran las Horas Productivas, mientras que en rojo se muestran las Horas

Improductivas. En la misma ventana se pueden conocer fácilmente los Totales de Horas

consumidos en todo el período de tiempo seleccionado.


o Pestaña “Distribución de las Horas de Parada por Causa”

Pestaña “Gráfico”

Esta pestaña presenta las cantidades de Horas Improductivas totales agrupadas en cada

una de las Causas de Improductividad. El gráfico tiene una disposición de tipo torta.






pág. 169


Pestaña “Tabla”

La misma información que se analiza en la pestaña anterior, se presenta aquí, en forma

de tabla. Las diferentes Causas de Improductividad y sus Cantidades Totales por cada

una de ellas.







pág. 170

o Pestaña “Distribución de las Horas de Parada por Producto”

Esta pestaña muestra un gráfico de barras con las Cantidades de Horas Improductivas

obtenidas en la fabricación de los Productos fabricados ordenados de mayor a menor

por el nivel de incidencia. Comúnmente este gráfico es conocido como Diagrama Pareto

utilizado para identificar fácilmente la frecuencia de problemas en orden de

importancia.


o Pestaña “Evolución de las Horas de Parada”

El último gráfico de la sección de Productividad muestra las cantidades de Horas

Improductivas alcanzadas en función del tiempo.







pág. 171

Pestaña “Tiempo de Setup”

Este gráfico muestra el tiempo total utilizado en la Puesta a Punto de las maquinas en

cada proceso productivo. Con él, se pude ver rápidamente la evolución de las Horas de

Setup en el período de tiempo seleccionado y el total de Horas Utilizadas.


o Análisis Avanzados:

El Panel de Gestión permite también profundizar ciertos análisis sobre la información.

A continuación, se muestra cómo utilizar el la herramienta de gestión para obtener

mayor detalle a partir de los informes generados.

Suponiendo que mantenemos seleccionado dentro del panel de Filtro, el período de

fechas contenido desde el 1ro de Marzo al 31 de Marzo del año 2010. De manera

siguiente, abrimos la pestaña “Evolución de la Producción” de la Sección “Calidad” del

panel inferior y obtenemos el siguiente detalle:

Filtro:

Figura 5.14.

Panel de Información:






pág. 172


Note: aquí se puede ver el total de Productos OK y Productos defectuosos fabricados

en el período seleccionado.

Primer Análisis:

Conociendo el total de Productos defectuosos podemos pasar a la siguiente pestaña y

obtener, al igual que vimos antes, un gráfico de distribución de tipo torta con todas las

causas de Scrap detalladas.






pág. 173


Una vez ubicados en el gráfico es posible realizar, en este momento, un análisis mas

profundo sobre la información obtenida.

El siguiente paso es seleccionar con el Mouse alguna de las causas mostradas en el

gráfico.


Note: al hacer Click sobre una causa la misma se muestra seleccionada.

A continuación, podemos pasar a la pestaña “Distribución de Scrap por Producto” y

obtener un gráfico con la distribución del Scrap por cada Producto, pero solo de la causa

que hemos seleccionado en el paso anterior.






pág. 174


Note: en esta ventana se actualiza el título indicando cuál fue la causa seleccionada

en la ventana anterior.

También es posible, desde esta misma ventana, limpiar toda selección anterior, haciendo

click en la opción “Restablecer Gáfico”.

A continuación se muestra la Distribución por Producto de Scrap sin haber seleccionado

ninguna causa de Scrap.







pág. 175

Note: el título del gráfico “Distribución del Scrap por Producto”, indica que se está

mostrando la distribución general del Scrap por producto, sin analizar ninguna causa

en particular.

Segundo Análisis:

Si mantenemos seleccionada la causa de Scrap y pasamos a la pestaña “Evolución del

Scrap”, es posible obtener un gráfico que muestra el comportamiento del Scrap en el

tiempo solo para la causa seleccionada.







pág. 176


Note: nuevamente el título del gráfico está indicando que existe una selección en una

de las causas de Scrap.

De la misma forma que antes, es posible restablecer el gráfico para limpiar cualquier

selección anterior para obtener la evolución total del Scrap.


Note: el gráfico sin selección alguna representa la evolución general del Scrap.

Tercer Análisis:






pág. 177

De la misma manera como se hizo en la pestaña “Distribución del Scrap por Causa”, es

posible seleccionar algún ítem en la pestaña “Distribución del Scrap por Producto” para

profundizar el análisis.


Note: el título indica que no hay ninguna Causa de Scrap seleccionada, y al hacer

click en gráfico queda seleccionado el producto que queremos analizar.

A continuación podemos pasar a la pestaña “Evolución del Scrap” para analizar como

fue el comportamiento del Scrap para el producto Seleccionado.


Note: el título del gráfico indica que se está presentando la evolución del scrap solo

para el producto seleccionado en el gráfico anterior.






pág. 178

De la misma forma que antes es posible restablecer el gráfico para obtener la evolución

total del Scrap haciendo click en el botón “Restablecer Gráfico”.






pág. 179


Note: el gráfico sin selección representa la evolución general del Scrap.

Cuarto Análisis:

Hasta ahora se vio la posibilidad de obtener la distribución por producto de una causa de

Scrap determinada y obtener, también, la evolución del Scrap para dicha Causa de

Scrap. Por otro lado, se vio como obtener la Evolución del Scrap para un producto

determinado.

Lo que vamos a ver a continuación es la posibilidad de combinar estos análisis. En

otras palabras, veremos cómo obtener la evolución del Scrap para un Producto y una

causa de Scrap determinada.

En primer lugar, es necesario seleccionar la causa de Scrap en la pestaña “Distribución

de Scrap por Causa”.






pág. 180


Note: el orden en que se deben seleccionar los elementos debe ser siempre el mismo,

primero la causa de Scrap, luego el producto de interés.

A continuación cambiamos a la pestaña “Distribución del Scrap por Producto” y

seleccionamos un producto determinado.


Note: Compruebe que la Causa de Scrap esté siendo indicada, y que el producto haya

sido correctamente seleccionado.






pág. 181

Luego es posible avanzar a la siguiente pestaña, “Evolución del Scrap”, y obtener un

nuevo gráfico con el comportamiento del Scrap en el tiempo para el producto y causa de

Scrap seleccionado.


Note: compruebe que el título del gráfico muestre la Causa de Scrap y Producto de

interés.

Al igual que en los casos anteriores, es posible limpiar cualquier selección anterior,

haciendo click en la opción “Restablecer Gráfico”.


Note: el gráfico sin selección representa la evolución general del Scrap.






pág. 182

La sección “Productividad” del panel de Gestión Gerencial tiene el mismo

comportamiento de la sección “Calidad”. Es decir, que podremos obtener mayor detalle

en la información aplicando el mismo modo de trabajo que se demostró en la sección

anterior.

Pestaña “Reportes”

En la sección de reportes se pueden obtener diversos informes de uso administrativo

referidos al Área de Producción.


o Declaraciones de Producción

Este informe presenta un listado con los empleados de la planta, los períodos de tiempo

trabajados, los productos y las cantidades fabricadas en un día determinado. También,

incluye los indicadores de Calidad y Productividad asociados a cada producto.






pág. 183







pág. 184

o Resumen de Producción

En esta pantalla se muestra el listado de los productos y las Cantidades totales de Piezas

Fabricadas y Piezas Defectuosas construidas en un período de tiempo elegido,

agrupadas por Proceso de Fabricación.


o Resumen de Presentismo

Este informe presenta la lista de empleados Presentes y Ausentes en una jornada laboral

seleccionada.






pág. 185


o Resumen de Rendimientos

Este informe reúne el listado de los rendimientos alcanzados por cada uno de los

operarios de la empresa en un período de tiempo establecido.






pág. 186


Reportes obtenidos con las herramientas de Data Mining.

Distribución del Indicador Calidad en función de los Procesos de Fabricación.

En este gráfico podemos observar la distribución de la calidad representada por puntos

de color uniforme entre los diferentes Procesos de Fabricación. Con este informe,

podemos notar rápidamente cual es el proceso que más problemas de Calidad ha

sufrido. A partir de ahí, es posible continuar un estudio completo sobre el Proceso más

afectado.






pág. 187


Distribución del indicador Productividad en función de los Procesos de

Fabricación.

De la misma manera que en el gráfico anterior, es posible analizar la distribución de los

valores de Productividad representados con puntos de color uniforme en cada Proceso

de Fabricación. Con esta tabla podemos ver rápidamente como es el comportamiento de

la Productividad en cada uno de los Procesos e identificar aquellos, cuyo indicador

asume valores no deseados. También puede ser utilizado como método de control para

encontrar valores anormales en el comportamiento de los procesos.






pág. 188


Distribución 3D del Indicador Productividad en función de los Operarios y el

tiempo.

Esta representación tridimensional permite analizar los valores de Productividad de cada

Operario agrupados trimestralmente. Claramente es posible identificar, a partir de estos

datos, cuáles son las variables que se están comportando de manera anormal.







pág. 189

Representación de Bloques del Indicador Productividad en función de los

Operarios, en cada Proceso de Fabricación.

El grafico “Block” muestra una tabla con los valores de productividad representados en

diferentes bloques de colores. Estos bloques tienen la característica de cambiar el color

dentro de un rango establecido de valores posibles, entre el máximo y el mínimo

encontrado, para la población de datos analizado. Con esta herramienta, es posible

saber rápidamente, por el color del bloque, cuales son los Operarios y Procesos que más

se alejan del valor deseado.


Representación de Bloques del Indicador Calidad en función de los Operarios en

cada Proceso de Fabricación.

Al igual que en el caso anterior, podemos encontrar rápidamente donde se encuentran

los valores anormales del Indicador Calidad e identificar cuáles son los operarios y los

procesos con mayor grado de incidencia de problemas.






pág. 190


Representación de Bloques del Indicador Productividad en función de los

Productos, en cada Proceso de Fabricación.

Empleamos la misma herramienta para graficar mediante el diagrama de bloques los

valores de productividad, pero esta vez en función de los Productos y Procesos. Así

podremos ver rápidamente aquellos productos que tienen mayor incidencia en la caída

de la productividad.







pág. 191

Análisis de resultados:

Beneficios Esperados vs Beneficios Alcanzados

Finalizada la etapa de pruebas integrales del sistema se comenzó a utilizar el mismo de

manera productiva. De aquí en adelante, se llevaron tareas de validación de resultados y

medición del desempeño general de la aplicación a fin de detectar posibles desviaciones

y comportamientos inesperados. En este proceso se buscó, entre otras cosas, comprobar

que el sistema responda a las necesidades primarias que fueron planteadas al inicio del

desarrollo.

Lista de requerimientos planteados:

Proveer Información Histórica de Producción.

A través de una interfaz amigable se puede acceder, con el empleo de la herramienta, a

todos los indicadores de gestión de la producción. El panel de gestión, permite tanto la

consulta de datos para un día determinado, como también, permite seleccionar un

periodo de fechas para analizar valores históricos.







pág. 192


Identificar las causas de perdida materiales.

Desde el Panel de Gestión, es posible acceder a la sección “Calidad” para realizar los

análisis referidos a la calidad en el área de producción. Con esta herramienta es posible

obtener un informe, en el cuál, se puede consultar la cantidad de piezas fabricadas OK,

la cantidad de piezas defectuosas y reprocesadas. Desde esta perspectiva, es posible

analizar todas las causas que significaron pérdida de materiales declaradas al momento

de producir.


Al cambiar en la pantalla al modo de “Distribución de Scrap por Causa” se obtiene un

informe con la cantidad pormenorizada de causas de defectos. El mismo puede ser

presentado como un gráfico de torta o como una tabla.






pág. 193


Finalmente, en el modo “Distribución de Scrap por Producto”, se accede a un informe

pormenorizado con la cantidad de piezas defectuosas por producto. También es posible

obtener este mismo informe a partir de una causa de defecto particular.







pág. 194

Identificar las causas de perdida de mano de obra.

De la misma manera que se realiza el análisis de calidad, se puede realizar el análisis de

la productividad en la sección “Productividad” del Panel de Gestión Gerencial. Aquí se

puede obtener un informe detallado de las horas productivas e improductivas declaradas

en el momento que se fabricaron los componentes en la linea de fabricación.


Al igual que antes, el sistema permite, desde la solapa “Distribución de Horas de parada

por Causa”, acceder a un informe con la cantidad pormenorizada de horas

improductivas, sea en un gráfico de tipo torta o en una tabla.


Por último, el panel cuenta con una vista en la que se representa en un gráfico de barras,

la distribución con las cantidades de horas improductivas, agrupadas por producto.






pág. 195


Pormenorizar la incidencia de cada causa en el indicador OEE.

Retroalimentar el proceso de toma de decisión.

Luego de verificar que se cumplimentan los objetivos propuestos en la etapa inicial del

proyecto es posible comprobar, de manera complementaria, la presencia de algunos

beneficios esperados a partir del empleo de las herramientas.

Reducción de Horas Hombre.

Para comprender la implicancia de reducir horas hombres en la empresa se va a explicar

de qué manera se trabajaba antes y como se pasó a trabajar después de la

implementación del sistema. Ambas metodologías de trabajo son prácticamente

incomparables por ser notablemente diferentes entre sí, aunque analizarlas en conjunto,

permite entender el beneficio alcanzado con la utilización de la herramienta.

Antes de la implementación del sistema de Inteligencia de Negocio, toda la información

referida a la producción era registrada a mano por los operarios de la planta. Ellos

detallaban diariamente datos como: cantidad de piezas buenas fabricadas, la cantidad de

piezas defectuosas y las causas de estas piezas. También se agregaba, de manera

adicional, el tiempo trabajado y las paradas de máquina ocurridas. Todas estas planillas

eran posteriormente recopiladas y archivadas para un eventual estudio de la

información. Solo cuando era posible, un empleado administrativo buscaba una planilla

determinada y tomaba el trabajo de calcular manualmente el rendimiento alcanzado por

un operario en un proceso y turno dado. Esta información finalmente era entregada al

jefe de producción, quién la utilizaba para optimizar un proceso productivo. Para

realizar esta tarea el personal administrativo consumía, aproximadamente, una hora en






pág. 196

obtener un sólo indicador de proceso para un operario, en un proceso dado, para un día

determinado.

Después de que el sistema fue implementado era necesario que una persona diariamente

cargue en el sistema todas las planillas de producción generadas para almacenar esta

información de manera digital. Se verificó en la práctica que el personal administrativo

requería de alrededor de cinco minutos para cargar cada una de las planillas al sistema.

En total se tomarían para 30 planillas, correspondientes a 30 procesos, unos 150

minutos diarios. Una vez cargadas las planillas, el sistema permitía consultar todos los

indicadores de proceso requeridos para cada uno de los empleados, en un turno dado, en

un día seleccionado, etc. No solamente esto, además el sistema brindaba soporte para las

consultas de un solo día o un período de fechas, conservando así, el historial de los

datos.

Evolución del Indicador de Rendimiento traducido en costo

A partir de la información que se extrae con el sistema es posible, hoy día, realizar

ciertos análisis para mejorar el gerenciamiento de la empresa. Con la lectura de los

indicadores arrojados por el sistema, como puede verse más abajo, se pueden comparar

dos situaciones diferentes de una misma celda de trabajo y evaluar su evolución. Así,

por ejemplo, se podrán emplear los valores de productividad de un período de fecha

seleccionado y, posteriormente, traducir los mismos en costo, utilizando para ello, un

método adecuado.

Si se tratara, como veremos en este caso, de la evolución del indicador de la

Productividad sería posible, con una fórmula matemática, convertir estos valores a un

parámetro de mayor practicidad. Por ejemplo, podríamos saber las horas de mano de

obra o también, el costo de mano de obra a partir de esta información.

Caso de Ejemplo 1:

Informe de productividad del Proceso “Proceso 125”.






pág. 197


En base al gráfico es posible realizar el siguiente análisis: como sabemos que el estándar

de fabricación del producto “Producto 158” es de 44 Piezas/Hora, podemos decir que al

pasar de un promedio de 60% de Productividad a finales del año 2010, a producir con

un 80% de productividad a finales del 2011, se obtuvo una mejora del 20% y un mejor

aprovechamiento de las horas de mano de obra empleadas para obtener una misma

cantidad de piezas en el período de tiempo seleccionado. Dicho de otra manera,

podríamos asegurar que se pasó de una situación inicial, de fabricar 26.4 piezas

efectivas por hora trabajando al 60%, a fabricar 35.2 piezas efectivas por hora con una

productividad del 80% al final del período para el proceso seleccionado.

Es importante tener en cuenta, al realizar este tipo de análisis, que estas lecturas deben

contemplar variaciones comunes, como:

No todos los días se trabajan los 3 turnos

No todos los días se trabajan 8 horas diarias por turno

No todos los días son laborables.

Pueden existir horas extras.

Estas variables pueden alterar los cálculos que se realicen y afectar negativamente

cualquier tipo de análisis realizado si se emplea erróneamente la información. Por esta

razón, siempre es de gran utilidad emplear en los análisis los indicadores de gestión.

Éstos, permiten contrastar el total de horas trabajadas contra las horas de perdida de

mano de obra sobre el total de horas asignadas. Por ejemplo, un valor de productividad

del 60% puede ser tomado en 10 horas trabajadas o de 100 horas trabajadas. Por esta






pág. 198

razón, el indicador permite realizar conjeturas más acertadas contrastando la

información con otros parámetros de la organización.

No obstante, si uno quisiera un grado mayor de detalle sobre un hecho en particular

podría cruzar mayor información y obtener un análisis más profundo. Por ejemplo,

tomar la cantidad de horas trabajadas de un período a otro y, a partir de allí, estimar los

costos de mano de obra ahorrados o, en otro caso, afirmar que para una misma cantidad

de horas se obtuvo una mayor cantidad de piezas, dependiendo de la perspectiva de

análisis que uno requiera.

Caso de Ejemplo 2:

Informe de productividad del Proceso “Proceso 81”.


En este informe, podemos ver como pasamos de tener aproximadamente el 70% de

Productividad a principios de Enero, a estar por encima del 90 %, entrando al mes de

agosto del mismo año. Lo que supone una mejora del 20% del proceso productivo

seleccionado y un ahorro en mano de obra utilizada en dicho proceso.

Es difícil asegurar que el empleo de la herramienta de gestión haya tenido un impacto

directo en el desempeño general de la organización que pueda ser fehacientemente

comprobado luego de la implementación del sistema de Inteligencia de Negocio. Las

razones para creer esto son diversas. En primer lugar, debe comprenderse que toda

actividad productiva es afectada por múltiples variables, entre las que se también

encuentra, la incorporación de nuevas tecnologías de la información empleadas en el






pág. 199

proceso de toma de decisión empresarial. En segundo lugar, hay que resaltar que el

escenario de trabajo en una empresa se encuentra en una constante situación de cambio.

También por ello, es muy complicado asilar de manera suficiente las variables

intervinientes en una ambiente de trabajo determinado, como para aseverar que una

situación esperada sea producto de una decisión gerencial tomada a partir de la

información obtenida del sistema de Inteligencia de Negocio. Por último, es muy

importante destacar que toda acción que tiene el objetivo de mejorar un proceso

productivo, se realiza siempre a través de un proceso de toma de decisión en el que

interviene necesariamente una persona. Por este motivo, el benefició alcanzado con la

alteración de algún parámetro productivo está sujeto al criterio aplicado en la decisión

más que a la utilización de las herramientas de información empleadas para la

resolución del problema, por más que éstas últimas, sean esenciales en el proceso de

toma de decisión.

Experiencias Alcanzadas

Uno de los momentos claves donde se pudo observar la importancia de incorporar las

nuevas herramientas de negocio en la empresa ocurrió mientras se realizaba la

implementación. En esa ocasión se estaba presentando al gerente de producción y al

gerente de calidad, una funcionalidad novedosa que les iba a permitir explorar la

información con nuevas perspectivas de análisis. Fue sorprendente ver las caras de

asombro que tuvieron cuando comprobaron que una de las creencias que tenían a cerca

del estado de los procesos, era totalmente errada en comparación a la realidad que

estaba siendo ahora reflejada con la herramienta. En ese momento se presentó un

gráfico de tipo Pareto para representar la cantidad de piezas defectuosas agrupadas por

producto. A partir de este grafico pudieron ver, rápidamente, cuales eran los productos

con mayor problema dentro de un proceso determinado. Anecdóticamente, resulto ser

que el producto con mayor problema era aquel que, según creían hasta el momento,

presentaba menos cantidad de defectos.

Esta situación, fue para mí, una experiencia extraordinaria debido a que reveló en

primer lugar, que la información con la que se contaba era insuficiente para comprender

el estado actual de los procesos de fabricación en la empresa. En segundo lugar, hizo

notar la importancia que tienen las herramientas de negocio en el proceso de toma de

decisión de una organización. Finalmente, produjo un cambio cultural provechoso, que

permitió mejorar el compromiso y el nivel de involucramiento de los usuarios del

sistema para finalmente reducir, en cierta medida, el riesgo del proyecto.

El grafico que se mostró en ese entonces era muy parecido a este:






pág. 200


Puesta en Marcha

Durante la etapa de planificación del proyecto se generó un plan de inversión para

adquirir, llegado el momento, todo el hardware requerido que deberá soportar la

aplicación de negocio desarrollada. Se realizó un estudio que permitió establecer cuáles

eran los requerimientos de hardware mínimos necesarios para lograr que las

aplicaciones utilizadas corran dentro de los parámetros recomendados por cada

fabricante. Por otro lado, como el software utilizado es de uso y distribución libre, no

existe un costo asociado para su adquisición. No obstante, es importante mencionar que

la configuración de la plataforma, la construcción del Data Warehouse y el desarrollo

del tablero de control, consumen un esfuerzo perfectamente mensurable. Estos costos

fueron incluidos dentro del plan de inversión presentado a continuación:

INVERSIÓN REQUERIDA

Recursos Humanos

Inversión requerida en concepto de Recursos Humanos

Perfil Requisitos Asignación Inversión (pesos)






pág. 201

Ingeniero de Sistema 152 $ 6080

Analista de Sistema 24 $ 672

Programador 64 $ 1280

Administrador de

Redes

24 $ 480

Total $ 8512

Tabla 5.1.

Equipamiento

Inversión requerida en concepto de Equipamiento

Hardware Descripción Destino Inversión (Pesos)

Servidor Amd Sempron LE-

1250 64 Bit, Mother

Am2, RAM 1 Gb,

Disco Rígido Hd 160

Soportar

Plataforma de

Inteligencia de

Negocio

$ 900

Total $ 900

Tabla 5.2.

Dado que la organización cuenta con recursos de hardware que superan cómodamente

los requerimientos mínimos establecidos para este proyecto, se decidió emplear toda la

infraestructura existente e instalar las aplicaciones en los servidores propios de la

empresa. De esta manera, se evitó invertir innecesariamente en hardware, con lo cuál, se

logró reducir el costo total del proyecto.

En función del rol que posee cada usuario en la empresa y el nivel de acceso que

tendrán a la plataforma se generó un plan de capacitación para los futuros usuarios de la

herramienta. Esta capacitación abarca desde el empleo general del panel de gestión, la

navegación por toda la herramienta de consulta y el acceso a los informes prediseñados.

También se incluyó, dentro del plan de capacitación, aquellas tareas de mantenimiento

necesarias para mantener el sistema operativo. De modo tal, que el personal de la

organización podrá, por si mismo, asegurar el funcionamiento normal del sistema en

adelante.






pág. 202

PLAN DE CAPACITACION

Inversión requerida en concepto de Capacitación

Contenido Cantidad de

Usuarios

Duración

(horas)

Inversión

(pesos)

Acceso a la plataforma. Empleo

de las herramientas de consulta.

Utilización de reportes.

10 6 $ 900

Conceptos generales.

Instalación de la herramienta.

Tareas de mantenimiento

generales. Identificación de

problemas. Plan de

contingencia.

2 12 $ 1500

Tabla 5.3.






pág. 203

CONCLUSIONES






pág. 204

Toda organización, independientemente del contexto en el que se encuentre, puede

mejorar su competitividad en el mercado con el empleo sistematizado de la

información, extraída de los procesos internos, utilizada para la gestión empresarial.

Este tipo de tratamiento realizado sobre la información suele ser un proceso costoso y,

normalmente, llega a demandar gran esfuerzo y voluntad. No obstante, siempre

representa un bien intangible de alto valor para cualquier organización.

En el caso de la empresa Magneti Marelli se identificó la necesidad de acceder a la

información clave del negocio para dar soporte a las decisiones estratégicas en función

de los datos analizados. Por ello, se decidió construir una aplicación informática que

permitió a los usuarios acceder a la información relevante de manera oportuna. Así fue

que se desarrolló una solución Business Intelligence con la que los empleados de la

empresa obtienen, de manera sistemática, toda la información generada en el área de

producción para asistir las decisiones gerenciales de manera diaria. Con este sistema, los

directivos y el personal idóneo de la empresa pueden extraer datos históricos del

negocio y conocer el estado de situación cuando ellos lo requieran. Para esto, fue

necesario construir una plataforma de consulta, un almacén de datos para estructurar la

información y un conjunto de procesos necesarios para mantener actualizado el sistema

de manera periódica. Esta plataforma brinda las herramientas necesarias para poder

indagar entre los datos dentro de un marco pre-establecido. El resultado de este trabajo

permitió arribar a un Sistema de Soporte a las Decisiones totalmente operativo y

confiable.

Una vez finalizada la etapa constructiva del sistema se consultó a los usuarios claves de

la empresa para conocer cuáles eran los reportes de mayor utilidad en función de las

actividades que normalmente tenían. A partir de ello, se diseñó una lista de reportes

estándares con las que se logró automatizar las consultas de mayor frecuencia de uso y

minimizar el tiempo consumido en los procesos administrativos de gran importancia.

También se instaló una herramienta de Data Minning con el que se pudieron realizar

estudios más profundos a partir de la población de datos que se comenzó a colectar

desde el momento en que la organización empezó a utilizar esta solución. Con esta

herramienta, los usuarios avanzados, pueden encontrar periódicamente desviaciones en

las variables de producción.

Para la implementación del sistema de información se recurrió al empleo de

herramientas de tipo Open Source o Software Libre con los que se evitó invertir en

licencias usuarias y, con ello, se logró también reducir el costo del proyecto de manera

significativa. Para esto, fue necesario estudiar en profundidad cada una de las

herramientas involucradas y superar cualquier limitación o inconveniente a medida que

estos iban apareciendo. Finalmente, se obtuvo una plataforma estable y funcional con la

que se pudo responder, con suficiencia, a todos los requerimientos establecidos.

En base a las pruebas realizadas, el análisis de resultado y las experiencias observadas

se llegaron a establecer las siguientes conclusiones:






pág. 205

En primer lugar, la implementación de una solución de Business Ingelligence dentro del

ambiente operativo de la empresa Magneti Marelli Conjuntos de Escape. S.A. fue un

logro significativo que definitivamente marcó una brecha importante entre la situación

en la que se encontraba trabajando antes y después de la adquisición de la solución

propuesta. Como resultado de esta implementación se lograron agilizar las decisiones

empresariales, mejorar la velocidad en el acceso de la información y aumentar la calidad

en los informes utilizados en el ámbito gerencial. La organización, en su totalidad,

comenzó a aprovechar un nuevo recurso que antes no tenía posibilidad de explotar y a

tomar mayores decisiones gerenciales basándose en información que el sistema ofrece

en la actualidad.

En segundo lugar, se alcanzó gran experiencia en el uso de la plataforma Pentaho para

soportar el sistema de Inteligencia de Negocio de manera satisfactoria, a punto tal de

haber arribado a una solución profesional a un costo de inversión conveniente para la

organización. Como consecuencia de ello, se comprobó que este producto tiene la

capacidad suficiente, la infraestructura y la robustez necesaria para ser usada

perfectamente en ámbitos productivos donde las exigencias son mayores. Esto le

permite a Pentaho posicionarse sin dudas como una excelente alternativa en materia de

Inteligencia de Negocio. A partir de los resultados obtenidos en este trabajo, es posible

afirmar que con una decisión segura de invertir en Inteligencia de Negocio y la

utilización de productos de Uso Libre, como las ofrecidas por la empresa Pentaho,

organizaciones chicas y medianas podrán desarrollar, favorablemente, soluciones

Business Intelligence para mejorar su competitividad.

Finalmente, es importante mencionar que el empleo de la metodología Hefesto, tuvo un

impacto positivo sobre el proyecto, por permitir reducir los tiempos utilizados en el

Diseño y la Implementación del almacén de datos. Por otra parte, permitió registrar y

documentar cada una de las etapas del proyecto y generar, al mismo tiempo, el manual

del sistema. Esta metodología fue de gran utilidad durante todo el proyecto y se

convirtió en unos de los factores de éxito más importante para este trabajo. Se espera

que muchos desarrolladores puedan acceder y difundir, cada vez más, nuevas

experiencias alcanzadas con el empleo de Hefesto para construir sus propios Data

Warehouse.

Gracias a la colaboración y la confianza aportada por todo el personal, tanto gerencial

como operativo de Magneti Marrelli y el empeño dedicado hacia un objetivo claramente

definido y compartido por todos los miembros, se logró aplicar una solución de alto

nivel que significa un gran esfuerzo orientado a una búsqueda profesional

completamente lograda en este trabajo de investigación y desarrollo.






pág. 206

Limitaciones encontradas

Respecto de la tecnología empleada, podríamos encontrar que el producto Pentaho,

presenta ciertos problemas que, definitivamente, afectaron el desarrollo normal este

trabajo, y desviaron, en cierta medida, el camino de investigación principal. Durante la

etapa de implementación del sistema BI, surgieron imprevistos que demoraron el

proyecto. Cada inconveniente encontrado, tuvo que ser atendido y resuelto con

muchísima dedicación, invirtiendo gran esfuerzo por parte del desarrollador. Sea por

falta de documentación o falta de esclarecimiento sobre el verdadero problema, se

invirtió mucho tiempo en resolver los incidentes que aparecían principalmente con la

conexión de la plataforma Pentaho hacia la base de datos. Estos errores fueron difíciles

de solucionar y dieron lugar a comportamientos impredecibles de la aplicación. Entre

las dificultades principales se identificaron problemas con el driver utilizado, con el

tiempo de timeout de conexión a la base de datos, con la cache de primer nivel de la

plataforma Pentaho, entre otros. Ciertamente estos problemas fueron resueltos a prueba

y error siguiendo el consejo que otros usuarios publicaban en la Web. Se podría

establecer, a este manifiesto, como una clara limitación de la plataforma. En base a la

experiencia adquirida en esta tesis opino que es, en gran medida, inadmisible que un

grupo de desarrolles, que utiliza la configuración por defecto de la herramienta y emplea

una base de datos tan común como es Mysql, deba encontrar impedimentos tan grandes

a la hora de configurar la herramienta, a punto tal, de enfrentarse con inconvenientes

que aumentan directamente el riesgo del proyecto.

Además de ello, se encontró en Pentaho otra limitación significativa. Durante la

implementación del sistema fue necesario emplear la herramienta Pentaho Design

Studio para construir parte del Panel de Gestión. Esta herramienta está basada en la IDE

de Eclipse, la cual lleva instalado un complemento que permite el desarrollo de los

componentes Xaction. Las Xactions son unidades de procesamiento que realizan una

acción genérica sobre la plataforma Pentaho y son propias de esta herramienta. Las

mismas permiten realizar una extensa variedad de opciones y, entre muchas otras cosas,

son utilizadas para extraer la información del Data Warehouse que se mostrará al

usuario. Resultó que el trabajo de desarrollo de estos componentes se volvió una tarea

muy complicada y dio bastantes disgustos al momento de tratar con ellos. Se encontró

un vacío muy grande que impidió poder generar fluidamente estos elementos, ya que

Pentaho, no brinda ningún soporte ni herramienta para trabajar profesionalmente con la

ejecución de estos Xaction, tal como se requiere al momento de la implementación.

Sólo se ofrece la IDE, Pentaho Design Studio, que facilita la creación de los Xaction

pero no ayuda demasiado durante la ejecución de estas acciones. Pentaho tampoco

sugiere un método alternativo que sea práctico para llevar a cabo esta tarea. Sin dudas

que, de encontrar una herramienta que permitiera depurar los componentes

mencionados, se facilitará completamente la labor del desarrollador.

Por último, no quiero dejar de mencionar que la plataforma tiene serios problemas con

el manejo de los caracteres especiales. Es sorprendente encontrar tantos inconveneintes

para mostrar caracteres de uso tan común, como son los acentos. Este impedimento






pág. 207

genera gran frustración para el equipo de desarrollo, obligandolos generealmente, a

desistir del uso de ellos.

Nuevos Caminos de Investigación

Durante el desarrollo del Panel de Gestión se emplearon diversas tecnologías que debían

interactuar entre ellas para producir las visualizaciones deseadas. Algunas de estas

pertenecen al paquete Pentaho, mientras que otras, fueron instaladas manualmente. Una

de las tecnologías mencionadas es AmCharts. Esta fue utilizada para representar los

datos en forma gráfica dentro de la página web. Por otro lado, se utilizó el Community

Dashboard Framework para coordinar la comunicación entre los componentes y guiar el

flujo del programa dentro de la misma página. El framework AmCharts consiste en un

conjunto de librerías desarrolladas con Adobe Flash que permite manipular los datos y

mostrarlos en pantalla. Es interesante mencionar que el desarrollo de las aplicaciones

Flash, no es del todo estructurado. A pesar de funcionar muy bien, está siendo

reemplazado por la tecnología Adobe Flex, provista por la misma empresa. A diferencia

de Flash, éste es Orientado a Objetos y por lo tanto, tiene una filosofía de trabajo de

mayor nivel para el desarrollo. Cabe mencionar que AmCharts ya ofrece las librerías

para trabajar directamente con componentes Flex pero aún no se justifica emplearlas

simplemente porque el resultado final es el mismo. No obstante, sería de gran valor

desarrollar íntegramente el Panel de Gestión bajo este lenguaje, aprovechando la

existencia de todos componentes listos para ser utilizados. Para realizar este cambio,

habría que reemplazar completamente a CDF (Community Dashboard Framework)

provisto por Pentaho por un modelo desarrollado íntegramente en Flex. Es importante

distinguir, que CDF es una tecnología muy estable, muy completa y además brinda un

servicio muy bueno pero cuenta con una dinámica de trabajo muy rígida y una

visualización de componentes muy pobre.

Tras la realización de este trabajo de tesis, mi apreciación profesional, es que Pentaho

está equivocando la dirección hacia donde debe ir el proyecto en lo que respecta a la

capa de presentación de la plataforma. La razón, es la utilización de una tecnología

conceptualmente obsoleta. En contraste a ello, se sugiere como continuación de este

proyecto, una nueva línea de investigación y desarrollo para construir una

infraestructura de representación y visualización basada completamente en una moderna

tecnología, como es Adobe Flex. Dicha implementación podrá seguramente brindar

resultados superadores, visualizaciones de gran impacto y un método de desarrollo muy

predecible y estructurado. Combinándose con Xaction, Flex permitirá estructurar la

información en objetos, gestionar los eventos de los usuarios y, finalmente, producir una

experiencia extraordinaria para el cliente.






pág. 208

REFERENCIA BIBLIOGRÁFICA






pág. 209

RAMO, Jorge Israel (2010): Gestión del Conocimiento y Tic´s. Disponible en:

http://www.slideshare.net/pablosky21/tics-solemne-i-gestin-del-conocimiento-y-tics.

Consultado: 01/10/2010.

GARRILLO, María Daniela; QUIMBAYO, María Isabel; Vargas, Paula Marcela

(2008): Gestión del Conocimiento. Universidad Central de Venezuela. CEAP. Caracas,

Venezuela. Disponible en: http://www.slideshare.net/guest69f3c3/gerencia-del-

conocimiento. Consultado: 01/10/10.

CARRASCO ARROYO, Salvador (2006): Medir la cultura: Una tarea inacabada.

Universidad de Valencia. Departamento de Economía Aplicada. Valencia, España.

Disponible en: http://www.uv.es/carrascs/PDF/medir%20la%20cultura.pdf. Consultado:

05/11/2009.

MORA VENEGAS, Carlos (2009): La relevancia y el alcance de la Gestión del

Conocimiento. Disponible en: http://www.gestiopolis.com/administracion-

estrategia/relevancia-y-alcance-de-la-gestion-del-conocimiento.htm. Consultado:

06/11/2010.

SANCHEZ AMBRIZ, Gerardo (2009): El desarrollo organizacional. Una estrategia de

cambio para las instituciones documentales. Disponible en:

http://redalyc.uaemex.mx/src/inicio/ArtPdfRed.jsp?iCve=63511932013. Consultado:

20/05/1011.

HERNÁNDEZ FERNÁNDEZ, Lissette (2003). Conocimiento, cambio y

transformación organizacional. Universidad de Zulia. Venezuela. Disponible en:

http://redalyc.uaemex.mx/src/inicio/ArtPdfRed.jsp?iCve=73711580001. Consultado:

16/02/2009.

PÉREZ PÉREZ, Lilier; PALOMINO MARIÑO, Laura M. (2008). Gestión del

Conocimiento y tendencias actuales. Disponible en:

http://www.monografias.com/trabajos-pdf2/gestion-conocimiento-tendencias-

actuales/gestion-conocimiento-tendencias-actuales.pdf. Consultado: 05/10/2009.

AGUIRRE Y HERNÁNDEZ, Fernando (2010). Inteligencia de Negocios. Instituto

Tecnológico de Orizaba. División de Estudios de Posgrado e Investigación. Disponible

en: http://es.scribd.com/AERO007/d/39148762-INTELIGENCIA-DE-NEGOCIOS.


MESTIZO GUTIÉRREZ Sonia Lilia; GUERRA HERNÁNDEZ, Alejandro; PARRA

LOERA, Ramón (2008). Desarrollo de un Centro de Ayuda Inteligente mediante el uso

de Tecnolog´ıas de Internet. Veracruz México. Disponible en:

http://www.uv.mx/aguerra/documents/2008-mestizo.pdf. Consultado: 06/12/2010.

PEÑA RIVERA, Juan David; SUÁREZ DAZA, Jesús Armando (2005). Utilización de

Información Histórica para Decisiones Empresariales. Pontificia Universidad Javeriana.

Facultad de Ingeniería. Santa Fe de Bogotá D.C. Disponible en:

http://www.javeriana.edu.co/biblos/tesis/ingenieria/Tesis204.pdf. Consultado:

16/0/2010.

http://www.slideshare.net/pablosky21/tics-solemne-i-gestin-del-conocimiento-y-tics

http://www.slideshare.net/guest69f3c3/gerencia-del-conocimiento

http://www.slideshare.net/guest69f3c3/gerencia-del-conocimiento

http://www.uv.es/carrascs/PDF/medir%20la%20cultura.pdf

http://www.gestiopolis.com/administracion-estrategia/relevancia-y-alcance-de-la-gestion-del-conocimiento.htm

http://www.gestiopolis.com/administracion-estrategia/relevancia-y-alcance-de-la-gestion-del-conocimiento.htm

http://redalyc.uaemex.mx/src/inicio/ArtPdfRed.jsp?iCve=63511932013

http://redalyc.uaemex.mx/src/inicio/ArtPdfRed.jsp?iCve=73711580001

http://www.monografias.com/trabajos-pdf2/gestion-conocimiento-tendencias-actuales/gestion-conocimiento-tendencias-actuales.pdf

http://www.monografias.com/trabajos-pdf2/gestion-conocimiento-tendencias-actuales/gestion-conocimiento-tendencias-actuales.pdf

http://es.scribd.com/AERO007/d/39148762-INTELIGENCIA-DE-NEGOCIOS

http://www.uv.mx/aguerra/documents/2008-mestizo.pdf

http://www.javeriana.edu.co/biblos/tesis/ingenieria/Tesis204.pdf






pág. 210

LUNA POZO, Marta (2010). Desarrollo y explotación de indicadores de gestión. Un

caso de estudio en el contexto de un ERP. Valencia. Disponible en:

http://riunet.upv.es/bitstream/handle/10251/8624/PFC.pdf. Consultado 15/04/2011.

SANZ RODRÍGUEZ, Javier (2010). Evaluación apriorística de la reusabilidad de

objetos de aprendizaje. Universidad de Alcalá de Henares. Disponible en:

http://dspace.uah.es/jspui/bitstream/10017/8715/1/Evaluaci%C3%B3n%20aprior%C3%

ADstica%20de%20la%20reusabilidad%20de%20los%20objetos%20de%20aprendizaje.

pdf. Consultado: 05/06/2011.

FIGUEROA GONZÁLEZ, Jessica (2007). Implementación de un almacén de datos para

una base de datos DB2 usando instrucciones SQL: Una solución ROLAP. Universidad

Católica del Maule. Facultad de Ciencias de la Ingeniería. Disponible en:

http://www.ganimides.ucm.cl/aurrutia/doc_pdf/Seminario_Jessica_Figueroa.pdf.


CHINCHILLA ARLEY, Ricardo (2011). Mercado de Datos: Conceptos y Metodologías

de Desarrollo. Instituto Tecnológico de Costa Rica. Disponible en:

http://www.tec.ac.cr/sitios/Vicerrectoria/vie/editorial_tecnologica/Revista_Tecnologia_

Marcha/pdf/tecnologia_marcha_24-3/TM%2024-3%20art%206.pdf. Consultado:

20/11/2011.

TAMAYO, Marysol; MORENO, Francisco Javier. Análisis del Modelo de

Almacenamiento MOLAP frente al Modelo de Almacenamiento ROLAP. Universidad

Nacional de Colombia. Ingeniería e Investigación. Bogotá Colombia. Disponible en:

http://redalyc.uaemex.mx/pdf/643/64326317.pdf. Consultado: 08/06/2009.

ROJAS, Mariana Isabel (2009). Monografía de Adscripción: Data Warehouse.

Universidad Nacional del Nordeste. Facultad de Ciencias Exactas, Naturales y

Agrimensura. Corrientes, Argentina. Disponible en:

http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/MonoAdsDiseno.pdf

. Consultado: 16/05/2010.

BERNABEU, Ricardo Dario, (2010). Hefesto: Metodología para la Construcción de un

Data Warehouse. Córdoba, Argentina. Disponible en:

http://es.scribd.com/doc/49131495/HEFESTO-V2-0. Consultado: 11/10/2010

LOOR DÍAZ, Luis Enrique (2006). Agrupación Automática de Descripciones de

Productos. Escuela Superior Politécnica del Litoral. Facultad de Ingeniería en

Estadística Informática. Disponible en: http://www.google.com.ar/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCIQFjAA&url=http%3A%2F%2Fwww.dspace.espol.edu.ec%2Fbitstream%2F123456789%2F5832%2F2%2Ftesis_final.doc&ei=fo1_T-q4NYKs8QShxsy1Bw&usg=AFQjCNHTKbtADb6k4-

WcqaNhgVmLp3WGyA. Consultado: 16/09/2011.

VALLEJOS, Sofía J (2006). Trabajo de Adscripción. Minería de Datos. Universidad

Nacional del Nordeste. Facultad de Ciencias Exactas, Naturales y Agrimensura.

Corrientes, Argentina. Disponible en:

http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/Mineria_Datos_Vall

ejos.pdf. Consultado: 13/05/2009.

http://riunet.upv.es/bitstream/handle/10251/8624/PFC.pdf

http://dspace.uah.es/jspui/bitstream/10017/8715/1/Evaluaci%C3%B3n%20aprior%C3%ADstica%20de%20la%20reusabilidad%20de%20los%20objetos%20de%20aprendizaje.pdf



http://www.ganimides.ucm.cl/aurrutia/doc_pdf/Seminario_Jessica_Figueroa.pdf

http://www.tec.ac.cr/sitios/Vicerrectoria/vie/editorial_tecnologica/Revista_Tecnologia_Marcha/pdf/tecnologia_marcha_24-3/TM%2024-3%20art%206.pdf

http://www.tec.ac.cr/sitios/Vicerrectoria/vie/editorial_tecnologica/Revista_Tecnologia_Marcha/pdf/tecnologia_marcha_24-3/TM%2024-3%20art%206.pdf

http://redalyc.uaemex.mx/pdf/643/64326317.pdf



http://es.scribd.com/doc/49131495/HEFESTO-V2-0

http://www.google.com.ar/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCIQFjAA&url=http%3A%2F%2Fwww.dspace.espol.edu.ec%2Fbitstream%2F123456789%2F5832%2F2%2Ftesis_final.doc&ei=fo1_T-q4NYKs8QShxsy1Bw&usg=AFQjCNHTKbtADb6k4-WcqaNhgVmLp3WGyA




http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/Mineria_Datos_Vallejos.pdf

http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/Mineria_Datos_Vallejos.pdf

magallanes nahuel - bi aplicada_en la gestión de producción.pdf

Documents