Gestión de Proyectos Analíticos con la Metodología Kimball

A la fecha, la metodología Kimball cuenta con más de 30 años de vida y numerosos casos de éxitos. Sin embargo, resulta natural preguntarse si puede aplicarse a la situación actual y futura donde contamos con más datos, a mayor velocidad y variedad (big data) que hace 30 años atrás. La respuesta es sí, la metodología Kimball puede ser útil para tomar decisiones con datos, sean estos Gigas, Teras o Exabytes.

Ahora bien, si los datos no son de calidad, por muchos Terabytes disponibles será bien difícil que ocupemos la plataforma analítica que los suministra. Por lo tanto, no es solo el aspecto tecnológico (big data) que hay que cuidar.

Parafraseando a Steve Jobs el “stay data hungry and stay data foolish” requiere que las organizaciones gestionen activamente sus activos, entre ellos los datos. En este artículo veremos cómo gestionar proyectos analíticos y la plataforma asociada mediante la metodología kimball (técnicamente del grupo Kimball).

¿Cómo podemos gestionar proyectos analíticos?

Existen propuestas muy interesantes, por ejemplo, podemos encontrar el método BI Pathway. Este método propone insertar las iniciativas analíticas dentro de un portafolio que impacte los procesos de negocio core. Un enfoque distinto es Data Vault 2.0 Standard el cual persigue altos estándares de integración, escalabilidad y auditabilidad (SEI/CMMI) ofreciendo una arquitectura, metodología y buenas prácticas para lograrlo.

En este artículo revisaremos un framework pionero, propuesto por el grupo Kimball a mediados de los 80, conocido como “The Data Warehouse Lifecycle Toolkit”. Su mantra focus on the business es apalancado por 3 ejes: Tecnología, Datos y Business Intelligence.

¿Cuál es la premisa de la Metodología Kimball?

Considera que las iniciativas analíticas deben ser guiadas con el negocio para resolver necesidades del negocio. ¿Esto significa que TI está cada vez más lejos? Eso quisieran algunos vende self services, pero no, la idea es construir junto a TI una plataforma de soporte para Business Intelligence. Esta plataforma incluye una arquitectura conocida como Data Warehouse (DW).

Según la experiencia del grupo Kimball el mantra “focus on the business” implica:

  1. Enfocarnos en procesos de negocio. Es clave entender qué es lo que deben hacer nuestros usuarios en su trabajo y cual es el ciclo de vida del dato.
  2. La participación de perfiles híbridos. En aquella época se decía que una persona debía ser “mitad DBA” y “mitad MBA”. Hoy en día los llamamos Data Analyst, Data Scientist y quién sabe en el futuro, quizás Data Rangers.
  3. El uso de técnicas y diseños flexibles. Es probable que nuevos requerimientos surjan, nuevos módulos o sistemas deban ser incorporados e incluso puede ocurrir cambio de gerentes. Me ha tocado vivir todo lo anterior en el transcurso de un mismo proyecto.
  4. Abordar el desarrollo de la plataforma analítica de manera incremental y ágil en vez de seguir una estrategia Big Bang. El todo se conformará por el desarrollo de las partes, las cuales van reutilizando componentes previos (dimensiones conformadas).
  5. Estructurar los datos de forma tal que permita al negocio rentabilizarlos por sí mismos vía queries ad hoc, herramientas BI y/o reportes paramétricos. 

Una anécdota y reflexión sobre las capas de una solución analítica

Como dato anecdótico, a nivel de argot analítico, muchas personas promovieron el término BI para resumir todas las capas de la solución en un solo término. Es decir, BI podría incluir desde los modelos y ETLs hasta el delivery en formato de reportes, dashboard y Data Mining. A pesar de esto, la filosofía del grupo Kimball siempre fue considerar dos siglas: DW/BI,  al más estilo de Batman y Robin. Desde su punto de vista, BI sin una arquitectura (DW) que los respalde no sería efectivo y viceversa.

Lector: Ok Lenin,  pero entonces ¿siempre necesitare un Data Warehouse? ¿qué pasa con los mensajes del tipo “realice BI directo a sus fuentes de datos”?

Lenin: En general la respuesta es sí, necesitas una arquitectura llámese Data Warehouse, Data Lake, Data Vault o Lakehouse. A falta de una arquitectura, nuestros usuarios terminan convirtiéndose en “Ninjas Cinturón Negro del BuscarV”, trasladando valioso tiempo de análisis a la preparación de datos.

Una arquitectura permite ahorrar tiempo a mediano plazo, aporta linaje, gobernanza y credibilidad en los datos. Sin embargo, debemos diseñarla disciplinadamente, tal como lo esperaríamos en la elaboración de un puente. 

Hasta aquí hemos revisado la base de Kimball para elaborar nuestro puente analítico, ilustrando el qué y para qué, ahora veremos el cómo hacerlo. Ponte cómodo porque lo sigue es un poco más extenso de lo habitual.

¿Listo? Let’s rock!

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:

Métodología Kimbal Lifecycle para proyectos analíticos. Cuenta con 3 ejes: Datos, Tecnología y BI
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.

Enterprise Data Warehouse Bus Matrix
Enterprise 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.

Matriz de Priorización de Proyectos - 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.

Eje tecnológico de la metodología Kimball

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

Eje de datos de la metodología Kimball

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.

Eje BI de la metodología Kimball

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.

Difusión

Si crees que este contenido puede ser útil para otras personas no dudes en compartirlo. De igual forma te invitamos a seguirnos en LinkedIn, Facebook, Instagram y Youtube donde estamos publicando semanalmente tips relacionados con DW/BI, Data Science, Visualización y Software a la Medida que es justamente lo que más nos apasiona hacer en Explodat.

Referencias:

1. The Data Warehouse Lifecycle Toolkit, 2nd Edition

2. Sitio Web Grupo Kimball.

Agregar un comentario

Su dirección de correo no se hará público.