Vengo de una visita comercial a un potencial cliente. Resulta que se han comprado una herramienta para hacer informes a partir de la información que tienen en su sistema ERP (hecho a medida por cierto). El objetivo, encomiable, es que la dirección pueda hacerse sus propios informes y consultas sin tener que llamar al departamento de IT.Hasta aquí nada extraordinario hasta que nos enteramos que aún no saben qué tipo y estructura de información va a querer ver la dirección - vaya hombre, compran la herramienta y aun no saben si ésta va a poder sacar y gestionar la información requerida por los usuarios, pienso yo en el momento que me lo explican.
El tema se pone más crudo cuando nos enteramos que no sólo han comprado la herramienta a ciegas sino que ya han invertido un número considerable de horas en definir el modelo de datos de la base de datos intermedia que necesita esta herramienta (la mayoría de este tipo de aplicaciones funciona explotando una base de datos intermedia, resumida de la transaccional o principal).
En la reunión está el director financiero (impulsor de la iniciativa) y el director de IT, el que ha buscado la herramienta y puesto en marcha el proyecto.
Hemos quedado en que nos veríamos dentro de unos meses a ver que tal les ha ido y hacerles una especie de auditoría ... no se pero algo me dice que tendremos mucho trabajo a hacer y un montón de usuarios frustrados y cabreados. Al director de IT no se si lo veremos.
8 comentarios:
Otra vez estoy por aquí. Nosotros también tenemos este tipo de herramientas. Hace dos años estuvimos viendo algunas y finalmente nos decidimos por Microstrategy, aunque hay muchas en el mercado.
La base de datos intermedia a que te refieres es el datawarehouse, que como su nombre indica es un almacén de datos, y se pone en un entorno distinto del transaccional o donde está el ERP simplemente porque su cometido es que sea un entorno analítico, con un tipo de consultas mucho más pesadas que el transaccional.
La idea que dices de que esta base intermedia es un resumen es totalmente errónea, es justo al revés, lo suyo es que en el DW vaya TODA la información posible sin agregación, para que sea el usuario el que decida qué agregaciones quiera porque sea lo que vaya a investigar.
Por ejemplo, el DW de Cortefiel tiene varios teras, porque tiene almacenado entre otras cosas toda la descomposición prenda a prenda de los tickets de cada cliente que compra en sus tiendas. Esto le posibilita hasta llegar a saber qué se vende qué día y quien lo compra, o el gasto medio de la gente que lo compra. Si además utilizan su tarjeta, ya saben todo el historial de compra de un cliente (igual que en los hiper).
Otra característica de los datos del DW es que guardan la dimensión temporal del hecho, por lo que se pueden hacer análisis de evoluciones temporales.
En fin, que en un DW bien diseñado, debía tener toda la información que quisiera quien fuera de la compañía, porque tendría que haber de todo desagregado. Es un error partir de un DW resumen, y así seguramente habrá algo que quieran saber y que se habrá perdido al acumular la información.
Las herramientas sólo sumarizan información a nivel del detalle del DW, por lo que el fallo no estaría en la herramienta sino en el diseño del DW (bueno, tampoco es así, porque hay herramientas que con grandes cantidades de datos funcionan peor, pero la idea es que ya son por cuestiones puramente técnicas, y no de funcionamiento teórico)
Ésta en concreto necesita que agreguen la información porque no aguantaría toda la información transaccional. Microstrategy es otra dimensión.
De todas formas discrepo en que siempre te tengas que bajar todo el detalle ya que para eso puede que fuese más práctico atacar directamente la BBDD transaccional. Es más, creo que un buen diseño de DW agrega/agrupa/calcula/reorganiza la información que baja/sube de una forma inteligente para no tener que "replicar" toda la BBDD transaccional. Es cierto que en algún caso sí te tienes que bajar/subir "a nivel" del detalle pero no todo. Y siempre queda el recurso de enlazar con la BBDD transaccional si es necesario (drilldown)
Por cierto, conozco bien al que hizo el diseño de Cortefiel.
Discrepo un poco en tu apreciación: para acumular datos estarían los distintos datamarts que sobre el DW se pudieran montar, porque como tú bien dices en el post, el criterio de acumulación ya está presuponiendo una visión del análisis que se va a hacer sobre los datos, y si no se sabe el uso que se va a hacer, no se sabrá si está correctamente hecho. Y se supone que un DW va a dar cabida a todas las visiones de la empresa.
De todas formas, una cosa es la teoría de un DW y otra la disponibilidad de recursos que se tengan: a la hora de implementar uno, puedes ver que la tecnología disponible es la que es, porque estos recursos suelen ser bastante caros: entre hardware y software la verdad es que se te va un pico.
Por cierto del caso de Cortefiel probablemente la fuente de contacto sea la misma que tú conoces: yo me puse en contacto con el gerente de Accenture del proyecto porque habían elegido la misma herramienta de ETL que al final elegimos nosotros, y me contó un poco lo que estaban haciendo.
Ah, se me olvidaba. La visión de acceder directamente a los datos del transaccional desde el entorno analítico la venden mucho los de IBM, pero no la veo tampoco.
Si las querys de los 15 usuarios analistas que tenemos fueran directamente al DB2 del transaccional, dejamos tiritando a los 1000 y pico usuarios que están trabajando sobre la misma información. Esta alternativa fue rechazada frontalmente por nuestro administrador de Db2.
Por llegar a una conclusión consensuada: digamos que a la BBDD intermedia llega la información del transaccional "reorganizada", léase en unos casos agrupada, en otros reordenada, en otros traspuesta (de filas se pasa a columnas), etc.
Además depende del contexto: en un entorno contable-financiero suelen agrupar por periodo por ejemplo
Además yo no descartaría llegar a la BBDD transaccional ya que a veces el usuario quiere ver el documento original. Eso es rápido y directo, no se trata de hacer selecciones masivas donde si que se podría caer la máquina (y aún así hay técnicas que lo podrían evitar)
En el caso que explico, es una situación particular, que exige la agrupación de información por la naturaleza de la herramienta elegida (no es un DW sino un generador de informes).
Interesante debate...
Básicamente estoy más de acuerdo con Carmen, que defiende el punto de vista más académico al respecto.
El problema suele ser que el usuario de dirección está encantado con sus informes de alto nivel (donde ni siquiera ve números, solo colores). Pero un día tiene tiempo libre y empieza a bajar y bajar y bajar...y quiere llegar no al nivel de detalle de la transacción (sea pedido, ticket o factura), sino a verlo en el mismo formato que el transaccional.
Respecto al caso, yo estuve allí, aunque supongo que os referís a AM o JPM, ambos buenos amigos míos.
Me parece que estamos todos de acuerdo en lo básico aunque mi posición es cierto que ha estado condicionada desde el principio porque comento un caso muy específico que exige agrupar.
Veo por lo que comenta al final Rafa que hubo más de un responsable de diseño. Yo conozco a AB, de la oficina de Barcelona de la consultora que hizo el proyecto y en la que estábamos Carmen y yo.
Vaya, esto del debate se pone calentito. ¿A ver si vais a tener que quedar un día a debatir "face2face" no sea que querais chillaros o liaros a mamporros y no podais? ;)))) Propongo un punto intermedio: Los madriles.
Bueno, coñas al margen, Yo sigo viendo lo de siempre: en una esquina, los "TIC"; en la de enfrente, los directivos. ¿Y en medio? Pues eso, el de la camiseta de rayas en medio del ring. Pero... ¿cuál es su labor? "Ajustar", "templar", "adecuar", etc...
Claro que eso, precisamente "eso", es lo que vale, el resto es sólo hardware y puro almacén de datos (vaya, veo que has publicado una serie de fotos alegóricas con un precioso camioncete, Tic ;^) ) pero las empresas, tanto las clientes como las proveedoras, suelen tender últimamente a eliminar dicha pieza precisamente porque cuesta.
¡Ay si alguien fuera capaz de ver que esas piezas cuestan "porque valen lo que valen" y no al revés...!
Publicar un comentario