El enfoque iterativo de la Metodología

Kimball
El ciclo de vida es un roadmap general que describe la secuencia de tareas
necesarias para un correcto diseño, desarrollo e implementación. Esta
secuencia se presenta en el siguiente diagrama:

Ciclo de vida Kimball para proyectos analíticos (DW/BI)

Planificación de un programa/proyecto según

la Metodología Kimball

Usualmente las compañías cuentan con un plan estratégico que marca la pauta
a seguir en los próximos años. La recomendación del framework es tomar
como entrada dicho plan y proponer iniciativas analíticas (proyectos) que
ayuden a medirlo con datos. Estas iniciativas (árboles) en conjunto conforman
el programa analítico (bosque).

Una herramienta muy efectiva para comunicar el programa es la “Enterprise

Data Warehouse Bus Matrix”. En esta matriz cada fila representa un proceso
de negocio y cada columna es una dimensión con la cual se espera dar
contexto a las métricas que se usarán para medirlo.
 Enter
prise Data Warehouse Bus Matrix – Metodología Kimball

Definición de los requerimientos analíticos del

negocio

Es la tarea con el rectángulo más grande, recuerde el mantra que permea el

framework – focus on the business -. Debemos entender cómo los usuarios
operan en su día a día, averiguar qué datos utilizan y cuáles les faltan para
cumplir sus objetivos. Si entendemos su situación actual (as is), es más
probable que propongamos proyectos analíticos factibles (to be) que los
impacte positivamente. 

Probablemente detectaremos varias oportunidades, por lo que tendremos que

priorizar. Una forma de hacerlo es usando una matriz que fue popularizada a
principios de la década de 1970 por Boston Consulting Group.
Le pediremos a los gerentes evaluar cada fila de la “Bus Matrix” respecto al
beneficio que aporta al negocio. A su vez solicitaremos a TI que evalúe la
factibilidad para entregar los datos asociados. Ubicaremos los resultados en la
matriz de priorización y aquellos que se encuentren en el cuadrante superior
derecho serán los primeros en ser implementados.

Otra estrategia válida es el método MoScoW. Sí, sé que mi nombre está ligado
a un señor ruso y este método suena parecido a la capital de Rusia, pero en
realidad es el acrónimo de Must have, Should have, Could have, Won’t have.

Eje tecnológico de la plataforma analítica

Las iniciativas analíticas (DW/BI) suelen enfrentarse a múltiples problemas,

entre ellos: integración de datos e interoperabilidad de tecnologías. Antes de
comprar algún producto, la recomendación es diseñar una arquitectura
adecuada para la compañía.

Diseño de la arquitectura técnica analítica

El objetivo del diseño arquitectónico es establecer un framework y una visión

de largo plazo considerando 3 factores claves. Los requerimientos del negocio,
el entorno tecnológico actual (no es lo mismo extraer datos de SQL Server que
AS 400, Cobol o de SAP) y el plan tecnológico de los próximos años. Como
resultado obtendremos un listado de capacidades, componentes y requisitos de
administración adaptados a nuestra organización.

Importante: Esta tarea nos invita a realmente pensar la plataforma que

necesitamos y en lo posible evitar un pensamiento per alia del tipo: “si todos
están hablando del software X y además está en lo más alto del cuadrante
gartner, entonces deberíamos comprar el software x”.
Selección de productos analíticos e instalación

Usando el diseño arquitectónico podremos informadamente “ir de compras” y/o

desarrollar parte de los componentes que necesitemos. La decisión habitual es
adquirir herramientas de ETL y visualización. Una vez que hemos concretado
nuestro listado de productos, procedemos a instalar e instanciar nuestro
ambiente analítico.

Eje de los datos – Data Track

Modelamiento dimensional
En esta etapa nos enfocaremos en crear modelos de datos lógicos que sean
flexibles, fáciles de usar para los usuarios y cuyo rendimiento sea rápido a la
hora de realizar consultas de grandes volúmenes de datos.

A diferencia de otros enfoques basados en la normalización como el de Inmon

(CIF), se adopta la estrategia conocida como modelamiento dimensional. Si
bien el grupo Kimball la popularizó, su origen se remonta a un proyecto de
investigación realizado por General Mills y la universidad de Dartmouth en la
década del 60.
A grandes rasgos esta estrategia clasifica los datos en hechos de medición
(facts) o dimensiones que dan contexto a los hechos.

Diseño físico de modelos analíticos

El paso de llevar nuestro modelo lógico a una base de datos se conoce como
implementación física del modelo. Si nuestros modelos son creados en bases
de datos relacionales, se les conoce como modelo estrella. En cambio, si son
creados en bases de datos multidimensionales (por ejemplo Sap BW o MS
Analysis Services) se les conoce como cubos OLAP.

Nota: Hay una serie de herramientas que nos permiten pasar de un modelo
lógico a un modelo físico a casi un clic de distancia. Mi recomendación es que
consideres usar alguna. Por ejemplo, podrías usar Oracle Data Modeler, Toad
Data Modeler, Sap PowerDesigner o Erwin por nombrar algunas.

Diseño y desarrollo de procesos de ETL

Los procesos de ETL consideran la extracción de datos de diversos sistemas,

aplican criterios de calidad y consistencia de datos. Luego los unifican para que
puedan ser utilizados en conjunto y finalmente entregan los datos, en un
formato dimensional, para que los desarrolladores/analistas BI puedan crear
aplicaciones y los usuarios finales puedan tomar decisiones.
Como mencione en Qué es ETL y 3 Pecados Capitales cometidos, esta
tarea es compleja y requiere de mucho tiempo por lo que conviene
desarrollarlos de una forma estructurada y repetible. Una muy buena pauta a
seguir son los “34 subsistemas ETL”.
Eje Business Intelligence

A pesar de que este artículo lo vas leyendo secuencialmente, es importante

recalcar que los 3 ejes se pueden (y deberían) trabajar en paralelo.

Diseño de aplicaciones BI

En esta etapa identificamos y diseñamos aquellas aplicaciones que aportarán

valor tempranamente. Además definiremos el medio o portal por el cual
accederán nuestros usuarios y las capacidades que debería tener dicho portal
(alertas, integraciones, envío de email, etc.). 

Desarrollo de aplicaciones BI

Para nuestros usuarios, esta es la única capa visible del proyecto, pero
cuidado, no basta con entregar reportes y dashboards efectivos. Es crucial
que seamos ordenados en cómo los entregamos (home, carpetas, buscador,
índices). Debemos preocuparnos de pulir la capa semántica, los metadatos y
generar la documentación adecuada.
Nota: Una buena documentación facilita el onboarding a las herramientas
seleccionadas en nuestra arquitectura (Power BI, Tableau , SAP SAC, etc.).

Deployment, Mantención y Crecimiento

El deployment es la culminación de una iteración (proyecto analítico) que

considera la unión de los 3 ejes claves. Sin embargo, tras el primer
deployment, rápidamente surgen tareas de mantención (índices, particiones,
respaldos, etc.). No subestimes las actividades de mantención ya que son
claves para mantener una experiencia de los usuarios positiva.
Si nos fue bien, es casi seguro que la comunidad quiera más. Puede que algún
área diga “cuándo nos tocará a nosotros” o exprese “queremos lo mismo”. Esto
es una buena noticia ya que nuestra plataforma ha logrado una aceptación y
por lo mismo seguirá creciendo.
Resumen de la Metodología Kimball
Hay 3 aspectos que encuentro muy interesante de esta metodología:

 El primero es el referido a poner al usuario al centro. Si bien esto hoy

es casi un estándar en los 80 no era para nada una prioridad. 
 El segundo es darnos cuenta que no basta con tener el modelo de
datos perfecto y lo último en tecnología. Hay varias facetas
adicionales por coordinar incluyendo la mantención y crecimiento. 
 El tercero es el enfoque iterativo el cual en esta época lo llamaríamos
ágil. Para el framework es esencial exponer avances tempranamente.

https://explodat.cl/Analytics/business-intelligence/la-metodologia-kimball-para-data-
warehouses-y-bi-exitosos/