DWH

En general, dentro del DWH se distinguen tres áreas principales: 

Área de staging: Que contiene las información bruta extraída de los sistemas operacionales. Es un área temporal donde los datos se preparan y normalizan antes de cargarse definitivamente en el DWH. 

Modelo relacional: Es una base de datos donde la información se encuentra normalizada. Contiene todo el detalle de información. Y toda la historia posible. No hay tablas agregadas. En este punto la información ya está limpia e integrada, y ya se han creado las claves subrogadas. Es preferible un modelo en "copo de nieve" o incluso normalizado totalmente. 

Modelo dimensional: Es la base de datos que utilizan las herramientas de Business Intelligence para obtener la información y hacer los informes o análisis. El modelo dimensional está optimizado para conseguir un buen rendimiento. Existen tablas agregadas. Se prefiere el modelo en estrella. Y, en mi opinión, también debe tener todo o casi todo el detalle de información. 

Soy consciente que el máximo nivel de detalle implica cargar muchos datos, y hacerlo por triplicado, lo que requiere tiempo de carga y espacio en disco. Ya. Conozco las desventajas. Y debemos asumirlas si queremos un datawarehouse que se útil para las necesidades actuales y para las necesidades futuras.

El error 4 de esta serie sobre cómo construir un datawarehouse trata este asunto:

Error 4: Olvidarse del máximo nivel de detalle en el modelo entidad-relación.

Efectivamente, el máximo detalle no lo debemos dejar ni en el operacional, ni en la staging, ni en el modelo relacional. Todo el detalle debe propagarse hasta el modelo dimensional. Sólo de esta manera el sistema Business Intelligence superará el ataque de las consultas ad-hoc.

Habitualmente, esta manera de trabajar sólo la cuestionan los consultores que han intervenido en excesivos proyectos de cuadro de mando. Es habitual que las empresas soliciten un cuadro de mando sin tener antes un datawarehouse ni un sistema de reporting aceptable. En estos casos, cargar todo el detalle puede parecer difícil de justificar. ¿Cómo voy a proponer un DWH de 500Gb si el gerente sólo quiere 4 pantallitas para hacer el seguimiento mensual de un puñado de indicadores? En mi opinión, hay que proponerlo. Sólo disponiendo de un buen DWH podrá asegurarse la continuidad del proyecto BI.

A través de TodoBI he encontrado un artículo muy interesante de Ralph Kimball (¿Algún despistado que no lo conoce?) donde detalla los 12 errores más comunes en la construcción de un datawarehouse.

Se trata de un artículo excelente. Cada vez que he cometido alguno de estos errores, he tenido que rectificar al poco tiempo. No valen los atajos, hay que hacer las cosas bien desde el principio.

Los doce errores más comunes en la construcción de un datawarehouse son: 

• Error 12: Incluir atributos de texto en una tabla de hechos, si se hace con la intención de filtrar o agrupar. 
• Error 11: Abreviar las descripciones en las tablas de dimensión con la intención de reducir el espacio requerido. 
• Error 10: Dividir las jerarquías y los niveles de las jerarquías en múltiples dimensiones. 
• Error 9: No afrontar el tratamiento de las dimensiones lentamente cambiantes. 
• Error 8: Crear “smart keys” para relacionar una tabla de dimension con una tabla de hechos. 
• Error 7: Añadir dimensiones en una tabla de hechos antes de definir su granularidad. 
• Error 6: Crear un modelo dimensional para resolver un informe en particular. 
• Error 5: Mezclar hechos de diferente granularidad en una misma tabla de hechos. 
• Error 4: Olvidarse del máximo nivel de detalle en el modelo entidad-relación. 
• Error 3: Omitir las tablas agregadas y comprimir las tablas de dimension para afrontar los problemas de rendimiento. 
• Error 2: No unificar los hechos entre distintas tablas de hechos 
• Error 1: No compartir dimensiones entre diferentes tablas de hechos.

POST 5: Desarrollo del Modelo Dimensional del Kardex

Una base de datos con “modelo dimensional” es una base de datos que tiene una estructura adecuada para resolver consultas analíticas. Se trata de modelos sencillos que aseguran unos buenos tiempos de respuesta, y que se corresponden bastante con el lenguaje de negocio de los usuarios. Las herramientas de BI se conectan al “modelo dimensional” del DWH. Típicamente, se implementa con alguna de estas dos opciones: 

        Opción A: En una base de datos relacional. 

        Opción B: En una base de datos multidimensional. 

En el caso de que utilices una base de datos relacional (esto es: una base de datos normal y corriente de las de toda la vida), construirás el “modelo dimensional” utilizando una estructura en estrella, o una estructura en copo de nieve.

Y si utilizas una base de datos multidimensional, construirás “cubos”, y utilizarás una tecnología específica para estos menesteres (con sus ventajas e inconvenientes).

Se llama “modelo dimensional”, creo, porque para su creación/definición se hace un estudio sobre los datos de la empresa, identificando las “dimensiones”, y analizando como las dimensiones se relacionan entre sí (creando jerarquías), y como se relacionan con las tablas de hecho (creando “estrellas” o “cubos”).

En resumen, el “modelo dimensional” es el modo óptimo de organizar los datos en los sistemas de Business Intelligence, y puede hacerse mediante bases de datos relacionales (ROLAP), o utilizando bases de datos multidimensionales (MOLAP).

Y, sin duda, este artículo quedaría cojo si no mencionase que Kimball y Inmon tuvieron mucho que ver en la popularización de estas metodologías. Recomiendo esta magnífica entrada de Roberto Espinosa para ampliar los conceptos de modelado multidimensional. O en esta presentación que también hablan del modelado dimensional.

¿Que se puede utilizar si no es la normalización? pues tenemos otras técnicas, entre ellas lo que se conoce como modelo dimensional. En este modelo ya hay que cambiar de perspectiva y también hay que tener en claro en que contexto se utiliza. Si tengo mucha información y quiero generar reportes desde ella para realizar análisis, utilizaremos un modelo dimensional; si por otra parte lo que se quiere es guardar información y que la misma esté lo más completa posible (íntegra), hay que utilizar un modelo normalizado en el nivel adecuado (1FN, 2FN, 3FN, 4FN, etc.).

Retomando los modelos dimensionales y sabiendo donde se han de utilizar, ahora se presenta un informe técnico en base a un estudio realizado donde se generó un modelo dimensional a partir de una estructura normalizada, en dicho informe se aprecia, entre otras cosas; la diferencia en el tiempo de respuesta de las consultas, lo cual asoma que el modelo dimensional resulta conveniente para situaciones de búsqueda de información.

Informe técnico modelo dimensional: Enlace

POST 4: Fase de Diseño.

Ha llegado el momento de comenzar con el proceso de desarrollo y diseño de un sistema que sirva de apoyo para la toma de decisiones en el ámbito académico bien sea cualquier nivel de educación, lo hemos llamado "Krystal" y su lema es "Para medir el desempeño con claridad y coordinación" creado por el Grupo 3.

Una problemática actual tiene que ver con la forma como se lleva el control de la evolución académica de los estudiantes durante cada período educativo que cursan indiferentemente como sea el proceso en el institución donde se harán tal control (semestre, trimestre, anual, etc), esto en los casos donde existe tal control.

Se ha detectado un punto crítico, y es el hecho concreto que la medición del desempeño de los estudiantes muchas veces se hace al final del período académico o simplemente no se hace porque no existen las herramientas necesarias para tal fin, donde ya no hay acción posible que tomar sino que queda la esperanza de un proceso de reparación o la resignación de volver a ver la materia por parte el estudiante y si es el caso del evaluador simplemente aceptar la situación y seguir implantando su materia sin ningún estudio o modificación para la mejora del rendimiento del alumnado.

Por lo expuesto anteriormente, se tiene como objetivo fundamental el proveer un sistema que le permita a los estudiantes realizar fácilmente un seguimiento de su desempeño académico, pudiendo así detectar de forma temprana cualquier desviación que le afecte el resultado final en una materia. Además de ello, también podrían tener su historial de desempeño, donde se mostraría su evolución a lo largo del ciclo de estudio, ayudando esto a visualizar bajo que condiciones son más efectivos académicamente.

De la misma forma, partiendo de la información de los alumnos, los profesores pueden detectar variaciones en el rendimiento de sus estudiantes, agruparlos de acuerdo a su desempeño para dirigir una mayor atención en aquellos que la necesiten, y en fin; disponer de un conjunto de información que le permita tomar decisiones para mejorar los resultados de las materias que imparte.

Y no solo termina en los profesores, el sistema provee la agregación de datos (consolidación), lo cual le permite a las instancias organizacionales por encima del nivel del profesor tener resúmenes que también le ayuden a tomar decisiones oportunas y efectivas, además de mostrarles el estado de salud de los segmentos académicos que están bajo su responsabilidad.

El proyecto ciertamente resulta interesante y a primera vista asoma que puede ser de gran utilidad, sin embargo se requiere un trabajo para lograrlo y he aquí que viene la parte importante de su ciclo de vida. Para ello es importante que cada integrante tenga tareas definidas y que éstas puedan ser ejecutadas sin ningún tipo de dependencia de los demás, y si hay dependencia, que sea mínima; ya que si las tareas de una persona dependen totalmente de otra, es igual a que lo hiciera una sola.

Es importante aclarar que en la primera ejecución de una tarea no se logrará el resultado esperado, sino que a partir de un proceso de realimentación en base a la experiencia adquirida es que se van mejorando las cosas. Entonces podemos evidenciar que todo proceso tiene una historia. Afortunadamente existen herramientas que nos permiten llevar tal control y poder "retroceder el tiempo" hacia el punto que necesitemos durante el desarrollo de un proyecto de software para mejorar lo que se había hecho. Hay muchas, sin embargo nos orientaremos al uso del protocolo "Git" a través del servicio de versionamiento gratuito que ofrece Google (code.google.com).

Explicar "Git" no es el objetivo de este post, la intención es dar una introducción al proyecto que se va a realizar e indicar la herramienta de control utilizada; esto con el fin de que cualquiera que desee indagar un poco más en lo que se está realizando, pueda saber que herramientas necesita para hacerlo.

No hay más introdución que dar por ahora, dejamos a la mano los recursos de este proyecto para que sea el contenido de éstos los que reflejen el proceso de aprendizaje de los participantes.

A continuación tenemos partes del diseño de este proyecto:

• Visión del Sistema
• Planificación del Proyecto
• Monitoreo Académico Krystal - Para Medir El Desempeño

POST 3: Metodología de Kimball

Metodología de Kimball

La Metodología Kimball, es una metodología empleada para la construcción de un almacén de datos (data warehouse, DW) que no es mas que, una colección de datos orientada a un determinado ámbito (empresa, organización, etc.), integrado, no volátil y variable en el tiempo, que ayuda a la toma de decisiones en la entidad en la que se utiliza.

La metodología se basa en lo que Kimball denomina Ciclo de Vida Dimensional del Negocio (Business Dimensional Lifecycle). Este ciclo de vida del proyecto de DW, está basado en cuatro principios básicos:

• Centrarse en el negocio
• Construir una infraestructura de información adecuada
• Realizar entregas en incrementos significativos (este principio consiste en crear el almacén de datos (DW) en incrementos entregables en plazos de 6 a 12 meses, en este punto, la metodología se parece a las metodologías ágiles de construcción de software)
• Ofrecer la solución completa (En este se punto proporcionan todos los elementos necesarios para entregar valor a los usuarios de negocios, para esto ya se debe tener un almacén de datos bien diseñado, se deberán entregar herramientas de consulta ad hoc, aplicaciones para informes y análisis avanzado, capacitación, soporte, sitio web y documentación).

La construcción de una solución de DW/BI (Datawarehouse/Business Intelligence) es sumamente compleja, y Kimball nos propone una metodología que nos ayuda a simplificar esa complejidad. Las tareas de esta metodología (ciclo de vida) se describen a continuación:

Planificación del Proyecto

En este proceso se determina el propósito del proyecto de DW/BI, sus objetivos específicos y el alcance del mismo, los principales riesgos y una aproximación inicial a las necesidades de información.

Esta tarea incluye las siguientes acciones típicas de un plan de proyecto:

• Definir el alcance (entender los requerimientos del negocio).
• Identificar las tareas
• Programar las tareas
• Planificar el uso de los recursos.
• Asignar la carga de trabajo a los recursos
• Elaboración de un documento final que representa un plan del proyecto.

Además en esta parte definimos cómo realizar la administración o gestión de esta sub-fase que es todo un proyecto en si mismo, con las siguientes actividades:

• Monitoreo del estado de los procesos y actividades.
• Rastreo de problemas
• Desarrollo de un plan de comunicación comprensiva que direccione la empresa y las áreas de TI

Definición de Requerimientos del Negocio

La definición de requerimientos, es un proceso de entrevistar al personal de negocio y técnico, aunque siempre conviene, tener un poco de preparación previa. En esta tarea, se debe aprender sobre el negocio, los competidores, la industria y los clientes del mismo. Se debe dar una revision a todos los informes posibles de la organización; rastrear los documentos de estrategia interna; entrevistar a los empleados, analizar lo que se dice en la prensa acerca de la organización, la competencia y la industria y se deben conocer los términos y la terminología del negocio.

Se sugiere entrevistar al personal que se encuentra en los cuatro grupos que se mencionan a continuación:

• El directivo responsable de tomar las decisiones estratégicas.
• Los administradores intermedios y de negocio responsables de explorar alternativas estratégicas y aplicar decisiones
• El personal de sistemas, si existe (estas son las personas que realmente saben qué tipos de problemas informáticos y de datos existen en la organización)
• El personal que se entrevista por razones políticas.

Entre las tareas antes descritas, existe una flecha bidireccional, esto indica que los requerimientos del negocio son el soporte inicial de las tareas subsiguientes, también tiene influencia en el plan de proyecto.

Si avanzamos por el camino central del diagraman, encontramos las tareas asociadas al área de Datos, en esta, diseñaremos e implementaremos el modelo dimensional, y desarrollaremos el subsistema de Extracción, Transformación y Carga (Extract, Transformation, and Load - ETL) para cargar el DW. Las tareas pertenecientes al área, se describen a continuación:

Modelado Dimensional

Es un proceso dinámico y altamente iterativo. Comienza con un modelo dimensional de alto nivel obtenido a partir de los procesos priorizados y descritos en la tarea anterior, y El proceso iterativo consiste en cuatro pasos:

1. Elegir el proceso de negocio: que consiste en, elegir el área a modelizar. Esta es una decisión de la dirección, y depende fundamentalmente del análisis de requerimientos y de los temas analíticos anotados en la etapa anterior.
2. Establecer el nivel de granularidad: La granularidad significa especificar el nivel de detalle. La elección de la granularidad depende de los requerimientos del negocio y lo que es posible a partir de los datos actuales. La sugerencia general es comenzar a diseñar el DW al mayor nivel de detalle posible, ya que se podrían realizar agrupamientos posteriores, al nivel deseado.
3. Elegir las dimensiones: Las dimensiones surgen naturalmente de las discusiones del equipo, y facilitadas por la elección del nivel de granularidad y de la matriz de procesos/dimensiones (que se realiza en la tarea 4.2) Las tablas de dimensiones tienen un conjunto de atributos (generalmente textuales) que brindan una perspectiva o forma de análisis sobre una medida en una tabla hechos. Una forma de identificar las tablas de dimensiones es que sus atributos son posibles candidatos para ser encabezado en los informes, tablas pivot, cubos, o cualquier forma de visualización, unidimensional o multidimensional.
4. Identificar medidas y las tablas de hechos: Este paso, consiste en identificar las medidas que surgen de los procesos de negocios. Una medida es un atributo (campo) de una tabla que se desea analizar, sumando o agrupando sus datos y usando los criterios de corte conocidos como dimensiones. Las medidas habitualmente se vinculan con el nivel de granularidad del punto 2, y se encuentran en tablas que denominamos tablas de hechos (fact en inglés). Cada tabla de hechos tiene como atributos una o más medidas de un proceso organizacional, de acuerdo a los requerimientos. Un registro contiene una medida expresada en números, como ser cantidad, tiempo, dinero, etc., sobre la cual se desea realizar una operación de agregación (promedio, conteo, suma, etc.) en función de una o más dimensiones. La granularidad, en este punto, es el nivel de detalle que posee cada registro de una tabla de hechos.

Diseño Físico

En esta tarea, se contestan las siguientes preguntas:

¿Cómo puede determinar cuán grande será el sistema de DW/BI?

¿Cuáles son los factores de uso que llevarán a una configuración más grande y más compleja?

¿Cómo se debe configurar el sistema?

¿Cuánta memoria y servidores se necesitan? ¿Qué tipo de almacenamiento y procesadores?

¿Cómo instalar el software en los servidores de desarrollo, prueba y producción?

¿Qué necesitan instalar los diferentes miembros del equipo de DW/BI en sus estaciones de trabajo?

¿Cómo convertir el modelo de datos lógico en un modelo de datos físicos en la base de datos relacional?

¿Cómo conseguir un plan de indexación inicial?

¿Debe usarse la partición en las tablas relacionales?

Diseño e Implementación del subsistema de Extracción, Transformación y Carga (ETL)

El subsistema de Extracción, Transformación y Carga (ETL) es la base sobre la cual se alimenta el Data warehouse. Si se diseña adecuadamente, puede extraer los datos de los sistemas de origen de datos, aplicar diferentes reglas para aumentar la calidad y consistencia de los mismos, consolidar la información proveniente de distintos sistemas, y finalmente cargar (grabar) la información en el DW en un formato acorde para la utilización por parte de las herramientas de análisis.

Implementación

La implementación representa la convergencia de la tecnología, los datos y las aplicaciones de usuarios finales accesible desde el escritorio del usuario del negocio. Existen varios factores extras que aseguran el correcto funcionamiento de todas estas piezas, entre ellos se encuentran la capacitación, el soporte técnico, la comunicación y las estrategias de feedback.

Mantenimiento y Crecimiento del Data Warehouse

Para administrar el entorno del Data Warehouse existente es importante enfocarse en los usuarios de negocio, los cuales son el motivo de su existencia, además de gestionar adecuadamente las operaciones del Data Warehouse, medir y proyectar su éxito y comunicarse constantemente con los usuarios para establecer un flujo de retroalimentación, En esto consiste el Mantenimiento. Finalmente, es importante sentar las bases para el crecimiento y evolución del Data Warehouse en donde el aspecto clave es manejar el crecimiento y evolución de forma iterativa utilizando el Ciclo de Vida propuesto, y establecer las oportunidades de crecimiento y evolución en orden por nivel prioridad.

Si avanzamos por el camino inferior del diagraman, encontramos las tareas asociadas al área Aplicaciones de Inteligencia de Negocios, en esta ruta se encuentran tareas en las que diseñamos y desarrollamos las aplicaciones de negocios para los usuarios finales. Las tareas pertenecientes al área, se describen a continuación:

Especificación de aplicaciones de BI

En está tarea se proporciona, a una gran comunidad de usuarios una forma más estructurada y por lo tanto, más fácil, de acceder al almacén de datos. Se proporciona este acceso estructurado a través de lo que llamamos, aplicaciones de inteligencia de negocios (Business Intelligence Aplications). Las aplicaciones de BI son la cara visible de la inteligencia de negocios: los informes y aplicaciones de análisis proporcionan información útil a los usuarios. Las aplicaciones de BI incluyen un amplio espectro de tipos de informes y herramientas de análisis, que van desde informes simples de formato fijo, a sofisticadas aplicaciones analíticas que usan complejos algoritmos e información del dominio. Kimball divide a estas aplicaciones en dos categorías basadas en el nivel de sofisticación, y les llama:

1. Informes estándar: son informes relativamente simples, de formato predefinido, y parámetros de consulta fijos, proporcionan a los usuarios un conjunto básico de información acerca de lo que está sucediendo en un área determinada de la empresa y se utilizan día a día.
2. Aplicaciones analíticas: Son más complejas que los informes estándar. Estas aplicaciones pueden incluir algoritmos y modelos de minería de datos, que ayudan a identificar oportunidades o cuestiones subyacentes en los datos, y el usuario puede pedir cambios en los sistemas transaccionales basándose en los conocimientos obtenidos del uso de la aplicación de BI. Algunas aplicaciones analíticas comunes incluyen:

• Análisis de la eficacia de la promociones
• Análisis de rutas de acceso en un sitio Web
• Análisis de afinidad de programas
• Planificación del espacio en espacios comerciales
• Detección de fraudes
• Administración y manejo de categorías de productos

Por ultimo, en el camino superior, encontramos las tareas asociadas al área Tecnología en esta ruta, se encuentran las tareas relacionadas con software específico, por ejemplo, Microsoft SQL Analysis Services, etc. Las tareas pertenecientes al área, se describen a continuación:

Diseño de la Arquitectura Técnica

El área de arquitectura técnica cubre los procesos y herramientas que se aplican a los datos. En el área técnica existen dos conjuntos que tienen distintos requerimientos, brindan sus propios servicios y componentes de almacenaje de datos, por lo que se consideran cada uno aparte: El back room (habitación trasera) y el front room (habitación frontal). El back room es el responsable de la obtención y preparación de los datos, por lo que también se conoce como adquisición de datos y el front room es responsable de entregar los datos a la comunidad de usuario y también se le conoce como acceso de datos.

Informe Técnico: enlace

POST 2: Creación de un Informe técnico sobre el diagnostico de dos o tres empresas/organizaciones.

Un proceso de negocios describe la lógica sobre cómo una organización crea, entrega y captura valor. 

Los procesos de negocios son básicamente historias que explican cómo trabajan las organizaciones, indicando quiénes son nuestros clientes, cómo generamos utilidades, cuál es la lógica económica subyacente que nos permite entregar valor a los clientes a los que nos dirigimos a un costo apropiado. Es una descripción sistémica de cómo es que las piezas de un negocio embonan. 

Este modelo puede presentarse en forma tradicional con un texto en el que se describen los mercados meta que se han elegido, los ofrecimientos y estrategias organizacionales. Sin embargo, resulta más útil si se presenta en forma gráfica identificando sus componentes claves, permitiendo una mayor compresión lo que facilita el análisis y la toma de decisiones. 

Un buen proceso de negocio es esencial para toda organización exitosa, ya sea que se trate de un nuevo negocio o de una empresa ya establecida. No necesariamente estamos hablando de un modelo matemático, aunque es posible construir un modelo en el que las relaciones entre los bloques clave se pueden cuantificar con una relación numérica. Se trata más bien de una descripción que nos permite reflexionar sobre nuestro funcionamiento e identificar alternativas innovadoras para diferenciarnos de nuestros competidores.

Actividad Práctica:
Con el fin de comprender mejor los conceptos anteriores y conocer un poco la realidad que atraviesan los procesos de negocios de algunas de las empresas venezolanas. Se realizó una encuesta a 2 empresas diferentes. Ver Enlace

POST1: Ejemplo de construccion de BD. Desarrollo del Kardex

Basado en el Kardex da la Facultad de Ciencias, se debe reproducir los mismos registros y estadísticas.

1. Modelo de base de datos: Este modelo debe ser entregado en 3FN. Es decir el modelo conceptual debe ser relacional (esquema relacional)

2. Creación de la base de datos (DDL). En postgres, todas las tablas y relaciones creadas en el paso uno (01), deben ser implementadas.

3. Manipulación de bases de datos. Usted debe generar todos los INSERT de cada uno de sus registros del Kardex, y luego debe realizar todos los querys tanto para el listado de todas las materias por cada semestre cursado, así como también los querys que generen cada una de las estadísticas que este contiene: Eficiencia, promedio, promedio ponderado, UC inscritas, etc...

 Base de Datos: Enlace

Introducción Inteligencia de Negocios

Cuando se estudian las organizaciones, existe un elemento fundamental en el desarrollo de ellas y en especial en las posibilidades hacia el futuro que pueden tener desde el punto de vista de competitividad, productividad y toma de decisiones. 

Dentro de estos parámetros, la administración y gestión de la información se convierten en aspectos fundamentales que les ayuden a ser competitivas, para lo cual tienen que generar una estrategia para el manejo de la información. Con los avances de la tecnología informática y de telecomunicaciones, los datos y la información de una organización se encuentran dispersos en muchas fuentes y es necesario realizar esquemas que permitan recoger todo aquello de importancia para el negocio y colocarlo de una manera sencilla y clara disponible para todos los usuarios quienes son los conocedores del negocio y quienes pueden aprovechar al máximo el análisis detallado de este conocimiento para bien de la empresa. 

El manejo, la administración, la gestión y el control de la información como un arma estratégica, forma parte de la Inteligencia del Negocio, con apoyo de herramientas informáticas y analíticas, que ayudan a las organizaciones a maximizar su rendimiento en los negocios, generando la eficiencia operativa. Así mismo, la Gestión de Conocimiento ayuda a obtener mayor comprensión y entendimiento del entorno y de los procesos desde la propia experiencia en las personas y organizaciones. 

La información, el conocimiento y las organizaciones. 

Dentro de los elementos que ofrecen a las organizaciones la posibilidad de avanzar en este mundo globalizado y lleno de competencia, se encuentra como algo fundamental e importante “El valor del conocimiento residente en la empresa”

Según este planteamiento, el valor del conocimiento es fundamental para el crecimiento de las organizaciones, entonces conocimiento se puede definir y catalogar como: 

• Conocimiento Tácito. 
• Conocimiento del mercado y del negocio. 
• Experiencia. 
• “Know How”. 
• “Feeling”
• Conocimiento Explícito. 
• Datos convertidos en información. 
• Tablas, Gráficos, Indicadores 
• Información descriptiva y predictiva (Minería de Datos) 

El conocimiento tácito es propio de las personas y es fundamental en el proceso de una organización, ya que permite que ellas se desarrollen con base en el talento humano, pero no es suficiente con este conocimiento, es indispensable que las organizaciones desarrollen el conocimiento explícito, ya que éste es el que se genera dentro de la organización y corresponde a lo que sucede día a día en la operación de la empresa y es lo que conocemos como información. Entonces, podemos afirmar que el conocimiento y la información van ligados en el desarrollo armónico de las organizaciones y son claves en el proceso competitivo de ellas. 

Por este motivo, es necesario que la información de la organización sea administrada correctamente para que se tenga un efecto real en los resultados del negocio. Sin embargo, es necesario reconocer los tipos de información que existen en una organización. 

Podemos definir que este proceso es lo que llamamos Inteligencia del negocio a la que algunos la definen como la competencia para tomar decisiones, a través de enfoques dinámicos de los problemas y las oportunidades, bajo el proceso sistemático de encontrar, recopilar, seleccionar, organizar, conservar y presentar la información, desarrollando los recursos y capacidades internas de la organización.

 La inteligencia del negocio comienza una vez se hayan detectado y generada sistemáticamente las fuentes de información a las que se tiene acceso. Esto significa, que no es indispensable tener sistemas transaccionales muy sofisticados para poder iniciar un proceso de inteligencia del negocio y gestión del conocimiento. Igualmente no es necesario contar con herramientas especializadas de gestión gerencial o algo similar, sino que con herramientas comunes que normalmente tiene todo usuario en su computador, p.e Excel, Lotus 123, etc, se pude iniciar un proceso de inteligencia de su negocio capaz de entregar información a niveles de decisión suficientes para que la empresa comience a ser competitiva y esté en capacidad de conocer su entorno y su propia situación de una manera ágil, clara y sencilla. 

A continuación se presenta un esquema de lo que significa la información en la organización y las etapas que se deben seguir para lograr el proceso de inteligencia de negocio y gestión del conocimiento. 

En el esquema, se visualizan 4 etapas asi: 

1. Extracción 
2. Consolidación 
3. Explotación y 
4. Visualización