Notación BI

30 05 2008

Todavía existo y me la he pasado documentando.

Hay muchas cosas que podemos platicar acerca de la documentación pero de todas ellas siempre me llama la atención lo difícil que es documentar procesos en un data warehouse. Hay que describir paso por paso las cosas por ejemplo “…el presupuesto total se multiplica por el % de participación de los productos dentro de cada cliente…”, “el desglose de las ventas por cliente” o algo así (además de dibujar el respectivo diagrama para respaldar las palabras).

Confieso que soy ingeniero en otra cosa y de sistemas no estudié nada. Pero eso sí vimos matemáticas y matemáticas a lo bestia y si algo era fácil ahí era describir algo con simples símbolos. Así que para facilitarme la vida me he atrevido a proponerles estas cosas.

Para representar una métrica desglosada por una dimensión podemos usar

image

Donde el indicador es ventas y el subíndice Cliente representa la dimensión por la que se desglosa la métrica.

image

De esta forma podemos representar un porcentaje de participación. Las Ventas desglosadas por cliente dividido entre el total de ventas me dá como resultado con cuanto participa cada cliente en el total. Si el indicador no lleva subíndice representa el total de la métrica.

Mientras documentaba requería representar el % de participación que tienen los productos dentro de cada cliente.

image

Al usar un subíndice compuesto puedo representar un desglose por 2 dimensiones (lado derecho). En el lado izquierdo léase como el desglose del % de participación por producto dentro de cada cliente (que no es lo mismo que el simple % de participación por producto).

Un prorrateo donde el presupuesto se tiene a nivel región pero hay que explosionarlo a nivel producto (SKU) utilizando la historia existente en el datawarehouse me quedó:

image

Mientras más le rasco más útil me parece y más sencillo se me ha hecho documentar. Claro, hay mil cosas para donde irse …¿…como represento Ventas año pasado?¿las ventas del último periodo antes del cierre? Tampoco soy un experto y habría que resolver las distintas interpretaciones que diferentes personas les damos a a las cosas

¿ustedes que piensan?¿será útil?¿alguien conoce algún método parecido y me estoy inventado el hilo negro y complicando la vida?¿será mejor usar el método de las bolitas y de los cuadritos?

Por lo pronto creo que me urge el fin de semana… Nerd

About these ads




¿Cuantas dimensiones puede tener un cubo?

24 04 2008

muchasdimensiones

Muchas veces me han preguntado esto ¿los cubos tienen un límite de dimensiones? Dependerá del software que utilice para hacer los cubos.

Tal vez el punto debiera ser ¿necesitamos tantas dimensiones? Lo que he visto en la práctica es que demasiadas dimensiones confunde y deja inservible el modelo. Hay que ser todo un experto en el diccionario de datos para saber que la dimensión 423 (llamada Depto E. por que ya nos acabamos todas las combinaciones de Depto.) es la que necesitamos ¿podrá tomar el usuario una decisión válida si no está seguro que el desglose de la información que está viendo a lo mejor no es correcta?

Por otro lado pocas dimensiones nos dejarán con el deseo de profundizar mas en el asunto.

dimensionesLos modelos de dirección para ser prácticos deben de andar entre 10 y 30 dimensiones. Mas 30 dimensiones y el modelo será operativo y difícil de dominar. En mi opinión creo se debería evaluar quien será el usuario del modelo y a partir de ahí determinar el # de dimensiones que será conveniente para dicho usuario.

No quiere decir que no se pueda (tener muchas dimensiones); se puede y muchas veces se tiene y se debe de hacer. Si es de los que tiene dimensionitis, puede agrupar las dimensiones para que al hacer drill down las dimensiones estén agrupadas según a la entidad que pertenecen (por ejemplo agruparlas por producto, por cliente, etc.)

Bueno, pero que mejor que todos para determinar que es mejor: ¿cuantas dimensiones has usado en promedio?¿ Te han funcionado? ¿te ha funcionado bién con muchisimas dimensiones?¿el usuario? ¿cual es el # máximo de dimensiones que has usado?¿cual es el tiempo de respuesta?¿cuál ha sido tu experiencia?…

Por cierto, en nuestro caso (Artus) se ha eliminado el límite de dimensiones que se pueden tener…

Liar

…ok, ok, dado que cla_descrip es un int, soportamos entonces 2,147,483,647 dimensiones, ese es el límite.





Requerimientos de Hardware

21 02 2008

AutoPedales

Creo que me he llevado en el camino muchas novatadas, pero la que más recuerdo con cierto afecto fue la de requerimientos de hardware.

Años atrás, en un gran desarrollo y de largos meses me preguntaban antes de comenzar «¿cuáles son los requerimientos de hardware?». En ese momento hacer un documento detallado de cuales serían los requerimientos de hardware no estaba en mis prioridades. Así que los posponía por uno u otro motivo una y otra vez.

Y esto continuó hasta que alguien me dijo:

«Adrián, requerimos saber cuales son los requerimientos de hardware para saber si las portátiles que nuestra gente trae cumplen con la especificaciones de la aplicación. Si no la cumplen y tu no me las das, yo no puedo comprar 1000 portátiles de un día para el otro, para la siguiente semana o para el siguiente mes. Hay que hacer contactar a los proveedores, hacer una evaluación, ver las diferentes opciones, hacer la compra, recibirlas, prepararlas instalándoles todo el software que la compañía usa, el correo y demás cosas.

Los vendedores están repartidos por todo el país, y la información que tienen ellos en sus máquinas actuales no es fácil transferirla, nunca acabaríamos de enviar y recibir máquinas. Si ocurre que hay que cambiar las máquinas lo mejor sería hacer convenciones, tal vez una en el norte, una en el sur y otra en el pacífico. Estando la gente ahí aprovechamos y hacemos el cambio de máquinas y capacitación.

Todo esto hay que prepararlo con meses de anticipación en conjunto con otras áreas. ¿Entiendes ahora cual es la prisa?»

Creo que nunca me ha quedado más claro. Solamente a partir de ahí fue que aprendí la importancia de los requerimientos de hardware.

Saber si el servidor o las máquinas a disposición del desarrollo tendrán la capacidad suficiente es de vital importancia.

Por cierto, cuando entregamos los requerimientos de hardware hay que hacerlo sin miedo. ¿Cuantas veces ha pasado que el servidor ha quedado muy chico o solamente tuvo la capacidad suficiente por un año? Muchas veces por no sé que motivo ponemos la capacidad al mínimo, luego tenemos PCs con 256 mb de memoria, en las que el usuario tendrá que correr el sistema operativo, su correo, las noticias con Internet Explorer abierto, las 4 hojas de excel con información de la compañia, nuestra aplicación y los 3 jueguitos  en flash que el usuario tiene.

Y además tendremos que soportar conversaciones como esta:

— Tu aplicación está bien lenta, tarda mucho cargarse
— Ya ni la jodes, tienen 256 MB de Memoria y n aplicaciones ejecutándose.
— Me pusiste que esa memoria era suficiente ¿no?

Bueno, en este aspecto al menos me queda el consuelo que pasa lo mismo con los requerimientos impresos en la caja de Windows Vista.





Desventajas de un Data warehouse

2 10 2007

carretera

Segun las estadísticas casi todos los días alguién llega hasta aquí tratando de buscar información acerca de las desventajas de un data warehouse. Esto ha llamado bastante mi atención y es que no veo las desventajas por ningún lado. ¿Será que llevo tanto tiempo en esto que me he vuelto ciego y no veo lo obvio?

Veamos, para hacerlo más fácil puedo comparar un datawarehouse con un auto. Si en este momento alguién me preguntara ¿cuáles son las desventajas de tener un automovil? En automático diría:

  • hay que ponerle gasolina
  • hay que aprender a conducir
  • hay que llevarlo a los respectivos mantenimientos en la agencia $$$
  • hay que cambiarle las llantas cada cierto tiempo $$$
  • hay que soportar los malditos embotellamientos…
  • en México cada año hay que pagar impuestos por él.
  • hay que cambiar el aceite
  • a veces todo mundo te quiere de chofer…
  • hay que …

En todo caso todos los puntos anteriores son costos inherentes al beneficio de tener un automovil. Así es un data warehouse, hay muchos costos implicitos ($$$ y no $$$) pero los beneficios que se obtienen de él hacen que muchas veces el retorno de la inversión sea inmediato y con creces.

¿alguién que pueda dar más luz?





Automatizando estupideces

8 08 2007

Reportes1

Los proyectos que más odio son aquellos en donde todo está dicho.

Recuerdo con especial interés uno de ellos. Fue un cliente muy difícil. La prospección duró varios meses y nos evaluaron todo. Que si los tableros de control, que si los componentes, que si soportaba mapas o velocímetros, que si tenia alarmas, que si hacía dril-down, que si los cubos, que si las bases de datos, que si mil cosas mas.

Cuando pasó todo esta etapa de la venta y el proyecto inició me entregaron una carpeta bastante gruesa de reportes o informes. Eran cientos de ellos y con la consigna: «así los quiero».

Los reportes uno tras otro consistían en una tabla con “n” columnas y filtros arriba. Las columnas casi siempre eran las mismas: los meses del año, el YTD, el mes pasado, el presupuesto…en fin columnas más, columnas menos.

—Oye, pero podemos hacer cosas mucho mejores que esto
—NO, así los quiero
—pero son puras tablas…
—si, así los quiero. El objetivo es poder imprimir los reportes tal cual.

Y ahí esta. No se requiere un análisis, todo esta perfectamente definido. ¿El drill-down? ¿Los múltiples componentes? Bien, gracias.

Si insistes en preguntar obtienes la siguiente respuesta:

—Nuestro director es una persona importante, el maneja esos reportes a la perfección. Sabe donde esta cada dato y carga esa carpeta para todas partes y en cada viaje. No podemos modificar nada de ahí.

Pues a darle. A desarrollar cada uno de los reportes, columna por columna, cuidando la separación en pixeles de cada una, los encabezados, los títulos, el pie de página, el espacio del engargolado…y mil cosas más que dan un dolor de cabeza.

Pues listo, terminé los famosos reportes y a cuadrar los datos. En esa etapa pude trabajar hombro con hombro con el usuario. Cada vez que no cuadraba un numerito enfrente del usuario le hacía drill-down, lo graficaba, le sacaba tendencias y obtenía la diferencia. Al ver todo esto todo esto el usuario me preguntó que era todo eso, así que le hice una demo de la herramienta.

Quedó fascinado y a la vez pensativo. Viendo sus reportes se volteó y me dijo.

—Estás automatizando mis estupideces ¿verdad?
—la mera verdad, SI.

Y me platicó la historia de los famosos reportes. La primera versión de los reportes surgió cuando tenían COBOL y se imprimían en aquellas hojas verdes gigantescas. Como tuvieron que sustituir COBOL por otra cosa y las impresoras gigantes por las pequeñas pues contrataron a alguien que desarrollara en FOX aquellos reportes. Luego vendrían las bases de datos cliente servidor y las impresoras laser, así que contrataron a alguien que los desarrollara en Visual Basic y se imprimieran en Laser. Los reportes desde los 70’s no habían cambiado en nada y ahora era mi turno de hacerlos. Ellos tenían que cambiar la tecnología por otra mejor.

De esta plática como resultado muchos de los reportes se fueron a la basura y pude proponer algunos tableros. Hay mucho que aprender de esta anecdota.

Las reflexiones las dejaré para un post posterior.








Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 28 seguidores