Documentos de Académico
Documentos de Profesional
Documentos de Cultura
de Inteligencia de Negocios
Tabla de contenido
Etapas de Desarrollo de los Proyectos BI............................................................................................1
1.
Etapa de Justificacin................................................................................................................2
Paso Uno: Estimacin del Caso de Negocio................................................................................2
2.
Etapa de Planeamiento..............................................................................................................7
Paso Dos: Infraestructura Organizacional....................................................................................7
Paso Tres: Planeamiento del Proyecto..........................................................................................7
3.
4.
Etapa de Diseo.......................................................................................................................35
Paso Ocho: Diseo de la Base de Datos.....................................................................................35
Paso Nueve: Diseo ETL (Extract/Transform/Load).................................................................35
Paso Diez: Diseo del Repositorio de Meta Data......................................................................36
5.
Etapa de Construccin.............................................................................................................36
Paso Once: Desarrollo ETL........................................................................................................36
Paso Doce: Desarrollo de la Aplicacin.....................................................................................36
Paso Trece: Minera de Datos.....................................................................................................36
Paso Catorce: Desarrollo del Repositorio de Meta Data............................................................36
6.
Etapa de Despliegue................................................................................................................37
Paso Quince: Implementacin....................................................................................................37
Paso Diecisis: Evaluacin de la Entrega...................................................................................37
Justificacin
Diseo
Planeamiento
Construccin
Despliegue
En cada una de las etapas, ciertos pasos son llevados a cabo para llevar el proyecto de
ingeniera hasta su trmino. Una gua BI est compuesta de diecisis pasos:
1. Etapa de Justificacin
esto significa
Se define el trmino rea funcional como un departamento de una unidad de negocio que se
enfoca en una funcin especfica.
Sea que se est investigando un rea funcional o una unidad de negocio, las preguntas que se
necesitan tener en cuenta seran:
Una revisin de las reas funcionales y procesos crticos rpidamente descubrirn muchas
oportunidades para tomar en cuenta.
Aplicar la inteligencia de negocios en reas funcionales es un excelente lugar para empezar
la prctica BI. Los requisitos para las reas funcionales son generalmente ms fciles de
definir, y los beneficios son fciles de conceptualizar y medir que una solucin BI ms
agresiva que interrelaciona varias reas funcionales. Una aplicacin BI funcional puede ser
tambin relativamente fcil de implementar debido a que la fuente de datos frecuentemente
viene de uno o pocos sistemas OLTP en oposicin a una aplicacin de nivel inter-funcional o
de unidad de negocio que tpicamente necesita de datos de
mltiples
fuentes. Las
mejorar una ventaja competitiva, tienen potencial para el mayor retorno y son formas ms
avanzadas de inteligencia de negocios.
Definir Medidas
Las medidas para un negocio hoy en da deben centrarse en factores de xito crtico para
cada rea funcional, incluyendo parmetros adicionales para medir las estrategias principales,
metas y objetivos de la compaa como un todo. Debe haber una fuerte relacin entre los
indicadores de performance departamental y las mtricas de alto nivel
para medir la
Una vez que se haya comprendido las medidas importantes para una aplicacin, se puede
definir las dimensiones en las cuales las medidas pueden ser descritas.
Para comprender como las dimensiones interactan con las medidas la palabra clave es por;
est indica una referencia de dimensin.
Para definir la informacin necesaria para una aplicacin BI se debe tener en cuenta:
o Determinar las medidas y como se interrelacionan y son calculadas antes de definir las
dimensiones.
o Considerar como se desea analizar las medidas a travs del tiempo.
o Al mismo tiempo de especificar las dimensiones, se debe pensar de donde vendr la
data.
o En vez de pensar en cada dimensin en forma aislada, considerar como mltiples
dimensiones pueden describir una medida particular.
Dimensiones Comunes
La siguiente es una lista de dimensiones comunes encontradas en aplicaciones BI tpicas a
travs de reas funcionales interrelacionadas:
o Ventas y Marketing: productos, clientes, demogrficos (grupo por edad, sexo), canal
de ventas, geografa, promociones, campaas, fuerza de ventas, estados de rdenes,
tipo de venta, tiempo.
o Recursos Humanos: cuadro organizacional, empleados, tiempo, unidad de negocio,
departamento.
o Operaciones: cambios, tiempo, lnea de ensamblado, producto, productos, proveedor,
repositorio.
o Finanzas: moneda, cuentas, escenarios, tiempo, unidad de negocio, departamento.
2. Etapa de Planeamiento
Desde que la inteligencia de negocios es una solucin de soporte a las decisiones inter
organizacionales, debe existir o haber sido desarrollada una infraestructura organizacional
mientras la aplicacin BI es desarrollada. Una estructura organizacional tiene dos componentes:
Fig. 1. Restricciones del Proyecto
Estas preguntas traducidas, respectivamente, a las cuatro mayores restricciones del proyecto
de alcance, esfuerzo (tiempo), presupuesto y recursos es mostrado en la figura XX.
Definiendo el Proyecto BI
La planificacin del proyecto incluye crear un contrato del proyecto, que define al mismo
en trminos de:
Metas y objetivos
Alcance (entregables esperados del
proyecto)
Riesgos
Restricciones
Asunciones
Procedimientos de control de cambios
Procedimientos de control de
documentos
El contrato del proyecto es un acuerdo hecho entre cliente y el grupo IT para el desarrollo de
la aplicacin BI. Si un componente del contrato cambia, el proyecto en su totalidad debe ser
reevaluado y todas las restricciones deben ser renegociadas.
Alcance
El alcance tradicional ha sido medido por el nmero de funciones que el sistema ejecutar.
En los proyectos BI este sera una forma segura de sobreestimar el esfuerzo y los recursos. Las
aplicaciones BI son intensas en manejo de datos, no en funciones. Por lo tanto, el alcance debe
ser medido por el nmero de datos elementales que deben ser extrados del sistema fuente,
transformados y limpiados, y finalmente cargados a la base de datos destino de la aplicacin
BI.
La razn principal para concentrarse en los datos antes que en las funciones es que el
anlisis y la preparacin de los datos de la fuente original llevan mucho tiempo con respecto al
acceso y el facilitar el anlisis de datos a travs de reportes. La regla tpica 80/20 usualmente
implica 80% de esfuerzo para los datos y 20% de esfuerzo para la funcionalidad.
materializacin de un riesgo.
El plan de mitigacin especifica que acciones el equipo del proyecto puede tomar para
prevenir que el riesgo se materialice.
El plan de contingencia especifica las alternativas en caso que el riesgo se llegue a
materializar.
Restricciones
Esfuerzo ( tiempo)
Alcance
Presupuesto
Recursos
Calidad
Restricciones
Calidad
Presupuesto
Recursos
Esfuerzo (tiempo)
Alcance
Asunciones
Una asuncin es algo que se toma por cierto. Es importante documentar las asunciones ya
Las asunciones importantes deben tener su correspondiente riesgo, en caso que la asuncin
sea falsa o no se materialice. Para cada riesgo asociado a una asuncin, se debe identificar sus
disparadores, un plan de mitigacin y un plan de contingencia.
decisiones, el modelo mental debe cambiar y se debe adoptar: El cambio es bueno la gente en
los negocios debe refinar y mejorar sus decisiones, claro est, el cambio incontrolado puede
matar un proyecto.
una lnea base el acuerdo entre el auspiciador del negocio y el grupo de tecnologa de
informacin, como se documento en el contrato del proyecto. Cada solicitud de cambio, una vez
otras restricciones, llmense esfuerzo (tiempo), presupuesto, recursos y calidad, para absorber el
impacto en el cambio del alcance. Por lo tanto dependiendo en cuan crtica es la solicitud de
cambio, el representante del negocio debe decidir s:
a lo largo del proyecto y al igual que los cambios, no deben ser solo registrados sino
administrados. Cada documento debe ser asignado a una persona quien tiene la responsabilidad
para su resolucin. Cada actividad que involucre un documento debe ser fechada y descrita en el
registro de documentos. Al final del proyecto, todos los documentos deben tener una resolucin,
an si la resolucin es una postergacin del documento para una entrega BI futura.
Algunos documentos son menores y pueden ser resueltos sin impacto en el proyecto. Otros
pueden convertirse en un riesgo o solicitud de cambio y se debe tratar oportunamente. Por lo cual,
la administracin de documentos incluye un anlisis de impacto y un control de cambio.
Planificando el Proyecto BI
La planificacin del proyecto no es una actividad de una sola sesin. Desde que un plan de
proyecto est basado en estimaciones, las cuales son frecuentemente no ms que buenos tanteos,
el plan del proyecto debe ser ajustado constantemente.
3.
4.
5.
6.
7.
tareas. El administrador del proyecto debe apoyarse en una lista completa de las actividades ms
necesarias. Naturalmente, no todas las actividades deben ser realizadas en cada proyecto. Ni
siquiera todos los pasos deben ser realizados. El administrador del proyecto selecciona el nmero
mnimo de pasos y actividades necesarias para producir una entregable aceptable bajo las
restricciones impuestas.
Tcnicas de Estimacin
Una vez seleccionadas las actividades y tareas para el proyecto y organizado el proyecto en
sub proyectos, se puede derivar las estimaciones base usando uno de los tres mtodos:
1. Histrico, basado en patrones aprendidos (cunto tomo el ltimo proyecto)
2. Intuitivo, basado en la intuicin y la experiencia
3. Por clculos, basado en el promedio de las posibilidades
La estimacin de las actividades del proyecto BI es mucha ms difcil que la estimacin en
los proyectos tradicionales ya que no existe dos proyectos BI similares. Todas las tcnicas listadas
arriba sugieren un conocimiento previo de algn proyecto Bi anterior.
previo.
La estimacin intuitiva sugiere la prediccin basado en la experiencia previa de cuanto le
tomo desarrollar un actividad similar pero tal vez nunca desarrollo una actividad similar.
La estimacin basada en clculos sugiere conocer el mayor tiempo que tomara desarrollar
una actividad, el menor tiempo y el ms probable, pero es posible no conocer estos tiempos
al nunca haber realizado actividades similares en el pasado.
En todo caso, es mejor consultar con otras personas que ya han desarrollado aplicaciones BI
similares ya que las estimaciones sin un sustento pueden aumentar las sobre estimaciones. Esto
demuestra lo importante que es registrar los tiempos de desarrollo de proyecto BI, se puede
necesitar esta informacin para estimar el prximo proyecto BI.
Asignacin de Recursos
La estimacin del esfuerzo no puede estar completo hasta que se asignen las actividades y
tareas ya que las estimaciones deben tomar en cuenta las habilidades de cada miembro del
equipo, la experiencia en cada rea de estudio as como los factores ambientales que los afectan.
de estudio.
Factores ambientales actividades administrativas y no laborales. La tabla 3 muestra una
lista con algunos ejemplos
Tabla 3. Factores ambientales que pueden afectar la disponibilidad de los miembros del equipo
Factores Administrativos
Factores no Laborales
Vacaciones
Enfermedad
Reuniones
Licencias personales
E-mails
Citas mdicas
Seminarios de entrenamiento
Fiestas religiosas
realizadas en paralelo siempre y cuando se cuente con el grupo humano necesario. El primer paso
para determinar que tareas pueden ser realizadas en paralelo es identificar la dependencia de
tareas y desarrollar el camino crtico.
La mayora de herramientas para la planificacin de proyectos dan soportan los cuatro tipos
de dependencias. Finalizar para empezar y empezar para empezar son las dependencias de tareas
ms comunes; empezar para terminar es la ms infrecuente.
1. Terminar para comenzar indica que la tarea 2 no puee empezar hasta que la tarea 1 termine.
2. Empezar para empezar indica que la tarea 2 puede empezar al mismo tiempo que la tarea 1.
3. Terminar para terminar indica que la tarea 2 no puede terminar hasta que la tarea 1 termine.
4. Empezar para terminar indica que la tarea 2 no puede terminar hasta que la tarea 1 termine.
Para sacar ventaja de las dependencias, se necesita el nmero exacto de recursos con las
Dependencias de Recursos
La limitacin de recursos humanos puede rpidamente revertir el beneficio de tener pocas
dependencias. Por ejemplo, tareas que pueden ser realizadas en paralelo pero no pueden ser
asignadas a mltiples miembros del equipo debido a la limitacin de personal que conlleva a
ejecutar las tareas en secuencia.
Una vez que has identificado la dependencia de tareas y ponderado los recursos, se debe
usar el mtodo del camino crtico (CPM) para determinar la duracin de las tareas. Este provee la
visibilidad necesaria para reasignar recursos o renegociar las restricciones del proyecto.
Crear un plan de proyecto exitoso requiere de algn esfuerzo, pero mantener el plan del
proyecto (ajustarlo) no es una labor tan intensa como sola ser antes de disponer de herramientas
de administracin de proyectos. Adquirir experiencia en el manejo de una herramienta de
planificacin de proyectos lleva algn tiempo y requiere una solido entendimiento de los
principios de administracin de proyectos.
para el alcance propuesto durante la etapa 1, Estimacin de los Casos del Negocio. Claro est,
que probablemente no estn lo suficientemente detallados para empezar el proceso de
planificacin. Como parte de la definicin del alcance, se deben revisar los siguientes
requerimientos: datos, funcionalidades (reportes y consultas), y la infraestructura (tcnica y no
tcnica).
de entrega sin un buen entendimiento de las condiciones de las fuentes de archivos y bases de
datos. Se debe tomar algn tiempo para revisar el contenido de los datos de los archivos y bases
de datos operacionales. Se debe realizar una recoleccin suficiente de informacin para hacer una
prediccin educada sobre el esfuerzo que ser necesario para limpiar los datos.
precio de compra y el mantenimiento anual de las herramientas. De igual forma se debe incluir el
costo de contratistas, consultores y entrenamiento. Un costo indirecto asociado con la curva de
aprendizaje para los miembros del negocio y de tecnologa de la informacin.
una escala de 1 (bajo impacto) a 5 (alto impacto) de acuerdo a la severidad de su impacto sobre el
proyecto BI. De igual forma clasifique la probabilidad de cada riesgo que se materialice con 1
(probabilidad que no ocurra) y 5 (certeza de ocurrencia).
Empezar el Proyecto
Una vez planificado el proyecto, asignado los recursos y programados los entrenamientos,
se esta listo para empezar el proyecto. Esta etapa generalmente viene acompaada con una
reunin de orientacin para todo el equipo. El inicio del proyecto tambin debe incluir el
establecimiento de los canales de comunicacin (avisos, e-mails, pginas web) con el resto de la
organizacin para mantener a los stakeholders y las partes interesadas al tanto del progreso del
proyecto.
de la definicin, alcance, restricciones y cronograma del proyecto BI. Un contrato del proyecto
contiene las siguientes secciones:
Metas y objetivos (tanto metas estratgicas para la organizacin como los objetivos
en estas estimaciones.
Administrador de Base de Datos, El administrador de base de datos necesita entender
el alcance y cronograma del proyecto desde la perspectiva de la DBMS para que pueda estar
disponible para las actividades de diseo de base de datos y aplicaciones, as como para la
Definir el alcance es una de las tareas ms difciles en las aplicaciones BI. El deseo de tener
todo instantneamente es difcil de cubrir, pero mantener el alcance pequeo es uno de los
aspectos ms importantes para definir los requerimientos de cada entregable. Se espera que los
requerimientos cambien a lo largo del ciclo de desarrollo mientras ms se aprende acerca de las
posibilidades y las limitaciones de la tecnologa.
Una vez identificadas las oportunidades BI en la etapa de justificacin se debe compartir y
recolectar ideas de otra gente dentro de la organizacin. El Proceso tiene cinco etapas:
1.
2.
3.
4.
5.
El revisar las preguntas provee una importante pista acerca de las medidas y dimensiones.
Para documentar las pistas, se debe realizar lo siguiente para cada una de las preguntas ms
importantes:
1. Escribir la pregunta en la parte superior de un papelote. Use un papelote por pregunta.
2. Numere el papelote en forma secuencial y ubquelo en la pared. Las preguntas
posteriores de la misma rea funcional debe estar adyacentes.
3. Si la sesin de tormenta de ideas es para oportunidades funcionales interrelacionadas,
use papelotes de diferentes colores para cada departamento para capturar las preguntas
clave.
Papelote #
Medida
Producto
Geografa
Cliente
Tipo
Rep
Llamada
Venta
Tiempo
Unidad de venta
# producto
Regin
NA
NA
NA
Mes
Monto de venta
# producto
Regin
NA
NA
NA
Mes
Costo
# producto
Regin
NA
NA
NA
Mes
Margen
# producto
Regin
NA
NA
NA
Mes
# llamadas
# producto
Distrito
Cliente ID
Nivel 1
NA
Da
Duracin llamada
# producto
Distrito
Cliente ID
Nivel 1
NA
Da
Unidad de venta
# producto
Distrito
Cliente ID
NA
Represent ID
Semana
Monto de venta
# producto
Distrito
Cliente ID
NA
Represent ID
Semana
Unidad de orden
# producto
Distrito
Cliente ID
NA
Represent ID
Semana
Monto de orden
# producto
Distrito
Cliente ID
NA
Represent ID
Semana
Comisin
# producto
Distrito
Cliente ID
NA
Represent ID
Semana
El mayor reto para todos los proyectos BI es la calidad de la fuente de datos. Los malos
hbitos desarrollados a travs de las dcadas son difciles de dejar de lado, y el dao de estos
malos hbitos se traduce en consumo de tiempo y trabajo tedioso para corregirlos. De igual
forma, en el pasado el anlisis de datos estaba confinado a una sola perspectiva de usuarios de
negocio y nunca se reconcilio con las otras perspectivas en la organizacin. Esta etapa tomar
un porcentaje de tiempo significante del cronograma general del proyecto.
Cuando el proceso de tormenta de ideas se ha completado y los requerimientos de
informacin han sido definidos, un grupo pequeo mnimo un analista de negocios y un
experto en tecnologa de informacin o de sistemas sintetiza la informacin del prototipo BI
en una lista de reas de oportunidades BI para una evaluacin ms detallada. Son cuatro las
etapas en el proceso de evaluacin de las oportunidades BI:
1.
2.
3.
4.
para reflejar
una
Tabla 5: ejemplo de una estructura de reas de oportunidades basadas en los datos de la tabla 4
Producto
Geografa
Cliente
Tipo de Llamada
Rep de Ventas
Tiempo
# producto
Regin
NA
NA
NA
Mes
Costo
# producto
Regin
NA
NA
NA
Mes
Margen de ganancia
# producto
Regin
NA
NA
NA
Mes
Monto de Ventas
# producto
Distrito
cust ID
NA
rep ID
Semana
Monto de rdenes
# producto
Distrito
cust ID
NA
rep ID
Semana
Unidad de ventas
# producto
Distrito
cust ID
NA
rep ID
Semana
Unidad de rdenes
# producto
Distrito
cust ID
NA
rep ID
Semana
Comisiones
# producto
Distrito
cust ID
NA
rep ID
Semana
# producto
Distrito
cust ID
level 1
NA
Da
# producto
Distrito
cust ID
level 1
NA
Da
Anlisis de Ventas
Soporte al Cliente
# llamadas
Duracin
de
las
llamadas
Capacidad de Accin
Materializacin
Tctico vs Estratgico
Total
Alto
Alto
Estratgico
Alto
Anlisis de Ventas
Alto
Alto
Tctico
Medio
Soporte al Cliente
Bajo
Bajo
Tctico
Bajo
Anlisis de Margen de
Utilidad del Producto
Se debe recordar que no se est evaluando la importancia del rea funcional en el negocio
como un todo. La evaluacin es acerca del impacto de una oportunidad BI especfica propuesta.
Si la evaluacin inicial de la importancia no da resultados satisfactorios, se debe regresar a la
sesin de tormenta de ideas y pensar si los participantes comprendieron los conceptos de
inteligencia de negocios que rodena a las preguntas propuestas. O tal vez la reunin fue atendida
por gente no idnea para el caso, o tal vez una persona con una visin ms amplia y una actitud
BI real estuvo ausente ese da.
Calificar las oportunidades por dificultad
Escoger las reas de oportunidad BI que son fcil de implementar sin importar el rango de
clasificacin es especialmente importante cuando una organizacin tiene poca experiencia con
la inteligencia de negocios. Es muy importante comprender la dificultad de cada oportunidad
antes de proceder. Por lo cual se sugiere un test para estimar
la dificultad potencial de
implementar una oportunidad, el mismo est basado en tres criterios: interfuncionalidad del
diseo, existencia y accesibilidad de los datos y complejidad de los clculos. Aplicando estos
tres criterios, se estar en la capacidad de asignar un marcacin de fcil, medio o difcil a cada
rea de oportunidad.
Interfuncionalidad del diseo
Las oportunidades interfuncionales son las ms difciles de disear e implementar, la razn
principal
Existen datos para dar soporte a las medidas y dimensiones? S los datos estn faltando
para una dimensin se deber cambiar la dimensin, modificar el proceso de recoleccin
Basados en las respuestas, califique cada rea de oportunidad en una escala de fcil, medio,
o difcil para la disponibilidad de datos.
Complejidad de clculos
Mientras mayor sea la complejidad de los clculos de las medidas incluidas en los
requerimientos
implementacin.
La complejidad de las medidas calculadas puede ser un reto cuando se est obteniendo
informacin de mltiples sistemas OLTP. Este es un tpico problema de poblacin de datos que
se encuentra en aplicaciones interfuncionales que pueden ser solucionados, pero la solucin
implica algoritmos complejos y clculos de medidas que causarn que el sistema sea ms
complejo y por lo tanto ms difcil de implementar.
Inter-Funcionalidad
Disponibilidad de Datos
Clculos
Total
Difcil
Medio
Difcil
Difcil
Anlisis de ventas
Fcil
Medio
Fcil
Fcil
Soporte al cliente
Fcil
Fcil
Medio
Fcil
Anlisis de margen de
utilidad del producto
es la oportunidad, la
Oportunidades Altas/Fciles. Estos son buenos candidatos para una evaluacin posterior
y un rpido inicio.
Oportunidades Medio/Fciles y Bajo/Fciles. Contrapese el valor relativo de la
Los beneficios cuantificables que pueden ser usados en el numerador del clculo de retorno
sobre la inversin pueden ser:
informacin.
Mejorar la comunicacin con los empleados y satisfaccin del trabajo como resultado de
El anlisis para los entregables funcionales, que suelen llamarse anlisis de sistemas, son
mejor hechos a travs de prototipos. Hoy en da hay herramientas y nuevos lenguajes de
programacin, los cuales permiten a los desarrolladores rpidamente aprobar o desaprobar una
idea o concepto. Tambin permiten a los usuarios ver el potencial y los lmites de la tecnologa.
Esto da una oportunidad para ajustar sus requerimientos de entrega y sus expectativas.
Tener ms herramientas significa tener ms meta data tcnica a parte de la meta data del
negocio, lo cual es usualmente capturada y modelada en una herramienta CASE (Computer
Aided Software Engineering). Esta meta data necesita ser mapeada a la otra y almacenada en un
repositorio. Los repositorios de meta data pueden ser comprados o construidos. En cualquiera de
los casos, los requerimientos de qu tipo de meta data capturar y almacenar debe ser
documentada en un modelo meta. De igual forma, los requerimientos de entregar meta data a los
usuarios deben ser analizados.
Una o ms bases de datos estarn guardando la informacin del negocio en forma detallada
o agregada, dependiendo en los requerimientos de reporte de los usuarios. No todos los
requerimientos de reportes son estratgicos, y no todos ellos son multidimensionales. El
esquema del diseo de la base de datos debe concordar con los requerimientos de acceso del
negocio.
Si un repositorio de meta datos es comprado, ser muy probable que se tenga que extender
con caractersticas que son requeridas por la aplicacin BI. Si el repositorio es construido, la
base de datos debe ser diseado basado en el modelo meta desarrollado en el paso previo.
Existen muchas herramientas disponibles para este proceso, algunas son sofisticadas y otras
simples. Dependiendo de los requerimientos de limpieza y transformacin de la data
desarrollados durante el paso de Anlisis de Datos, una herramienta ETL podra ser o no la
mejor solucin. En cualquier caso, pre procesar la data y escribir extensiones para la
herramienta es en muchas ocasiones un trabajo requerido.
Una vez que los esfuerzos con los prototipos han finalizado con los requerimientos
funcionales, el verdadero desarrollo puede empezar con las mismas herramientas de acceso de
usuario y analista, tales como herramientas OLAP, o sobre herramientas diferentes. Esta
actividad es generalmente llevada a cabo en forma paralela a las actividades de repositorio de
meta data y ETL.
Muchas organizaciones no usan sus bases de datos BI a toda su capacidad. De hecho, su uso
es frecuentemente limitado a la generacin de reportes, algunos de ellos no son ni siquiera tipos
nuevos de reportes, si no remplazo de viejos reportes. El verdadero retorno de la inversin de las
aplicaciones BI viene de la inteligencia de negocios escondida en la data de la organizacin, la
cual puede ser descubierta solamente con herramientas de minera de datos.
Una vez que todos los componentes del Data Warehouse son completamente probados, las
bases de datos y las aplicaciones son ejecutadas. Se inicia el entrenamiento a los usuarios y las
funciones de soporte. Estas funciones incluyen soporte help desk, mantenimiento de las bases de
datos de data warehouse, cronograma y ejecucin de trabajos ETL, monitoreo de la performance
y ajuste de las bases de datos.