Business Intelligence
viernes, 3 de julio de 2015

Dimensiones lentamente cambiantes (SCD)

Un concepto importante en el diseño de los procesos de aprovisionamiento de un DWH es la estrategia de carga de las dimensiones. No es la primera vez que hablo sobre esto.

Trataré de explicar en este artículo cómo se deben cargar las dimensiones de un DWH. Conceptualmente, no es algo complejo en absoluto.

Se suele hablar de "dimensiones lentamente cambiantes" pero desde mi simplificador punto de vista esa es una expresión desafortunada. Todas las dimensiones son "lentamente cambiantes". Me explico:

  • El término dimensiones lentamente cambiantes (SCD, por sus siglas en inglés: Slowly Changing Dimensions) hace referencia a que los datos de las dimensoines van cambiando poco a poco a lo largo del tiempo. No son incrementales como los "hechos". Cada día hay nuevas ventas o pedidos, sin embargo la categorización de los productos o clientes va cambiando poco a poco a lo largo del tiempo.
  • Las dimensiones pueden ser estáticas como los meses, o cambiar muy muy lentamente (como el nombre de los municipios), o cambiar algo más rápidamente (como la edad de los clientes, o la clasificación de los productos en familias...). Entre dos días consecutivos, nuestro maestro de clientes puede crecer un poco, o puede aparecer un nuevo producto esporádicamente.
  • En realidad, no sé cuales son las dimensiones rápidamente cambiantes. Dependerá, en todo caso, de la paciencia del observador el determinar si los cambios son más rápidos o más lentos.

Por lo tanto, a todos los efectos, hablar de estrategias SCD es hablar del modo de cargar dimensiones. Punto. Las dimensiones son así.

Si buscas por internet, verás que se habla hasta de seis tipos de estrategias de carga SCD. La wikipedia también habla de un montón de tipos de carga SCD.

Desde un punto de vista práctico, sin embargo, solo dos tipos de carga SCD merecen nuestra atención. Las cargas tipo 1 y las cargas tipo 2. El resto solo tienen interés desde un punto de vista académico (o histórico). En la práctica, hoy en día, lo único que hemos de tener en cuenta a la hora de diseñar la estrategia de carga de una tabla de dimensión es si queremos guardar la historia de los cambios o no.

Dimensiones Tipo 1: Se sobreescribren los valores

Es el tipo de carga más básico y el más habitual. En este caso, se sobreescriben los valores existentes en el maestro con los nuevos valores.

Pensemos en el caso del pueblo burgalés de "Castrillo Mota de Judíos" que antes se llamaba "Castrillo Matajudíos". ¿Cómo debemos cargar la tabla de municipios de nuestro datawarehouse? ¿Es importante conocer la fecha en que ese pueblo cambio de nombre? ¿Cuando consultemos las ventas de los habitantes de Castrillo Mota de Judíos queremos que se incluyan también las ventas de cuando se llamaba Castrillo Matajudíos?

Evidentemente, no. No nos importa. Ese cambio de nombre será importante desde un punto de vista histórico y será relevante políticamente como muestra de integración y respeto cultural, etc. Sin embargo, en nuestro DWH de llamadas telefónicas, o de ventas, o de acciones comerciales... es un cambio irrelevante. No es necesario guardar esa historia. Nos basta con el nombre actual.

Para finlaizar este tema, un apunte relevante: Que no nos interese guardar la historia de cambios no implica que no debamos mantener campos de auditoría. Todas las tablas de dimensión deben tener los campos de fecha de alta, fecha de baja y fecha de modificación. Es una buena práctica tener siempre estos campos de auditoría y nos será de utilidad para detectar incidencias... Recuerda:

Dimensiones Tipo 2: Se guarda la historia de cambios

En los casos que sí que nos interesa guardar la historia se utiliza la estrategia conocida como "SCD Tipo 2". En este caso, la tabla de dimensión incluye los campos de fecha inicio de vigencia y fecha fin de vigencia. Estas fechas nos permiten determinar en que estado estaba la dimensión en cualquier fecha del calendario.

Esta estrategia ETL de aprovisionamiento se utiliza, por ejemplo, para guardar la estructura comercial de una organización (quién es el responsable de un determinado producto o zona en un momento determinado...). También es habitual en otros escenarios: En un entorno CRM puede interesar conocer los cambios de domicilio de los clientes, o sus cambios de preferencias...

Siempre que nos interese guardar la historia de cambios utilizaremos fechas de vigencia (ya sea en el maestro principal o en una tabla auxiliar...).

En estos casos, tampoco hemos de olvidar los campos de auditoría (fecha de alta y fecha de modificación, al menos...).

Cómo se hace

Todo lo anterior está muy bien, ¿Pero cómo se hacen estas cargas? ¿Cuál es el código SQL o qué herramientas tenemos para aplicar correctamente estas estrategias de carga?

Lo comento otro día que hoy ya me he alargado suficiente. Suscríbete al blog si no quieres perdértelo... :-)

Categoría: Definiciones

Comentarios: Ver comentarios

jueves, 25 de junio de 2015

La clave para aplicar metodologías ágiles correctamente

Tras casi 20 años en el mundo de la consultaría Business Intelligence, como consultor y como cliente, he cometido todos los errores que se pueden cometer... como consultor y como cliente... Eso me permite hablar con cierto conocimiento. Actualmente, no soy exactamente lo uno ni lo otro, por lo que puedo desvelar algunos secretos de tirios y troyanos con cierta libertad :-)

La semana pasada hablaba de las "metodologías ágiles" de un modo algo teórico. Hoy trataré de explicar, siempre desde mi personal punto de vista, la cuestión diferencial de este tipo de proyectos y algunas consecuencias prácticas muy importantes. Hablare de LA CUESTIÓN.

En último artículo decía que los proyectos ágiles debían entregar resultados de una manera frecuente, continua e incremental. Esa es la clave. De modo orientativo, hablaba de entregar resultados cada 3 o 4 semanas... Pero podrían ser igualmente 5 o 6... A estos periodos de tiempo se les suele denominar "sprints" o "iteraciones" (yo prefiero este último término).

El contrato

Antes de hablar propiamente de las iteraciones conviene recordar cómo se contratan los proyectos (ágiles o no), porque una cosa es decir que cliente y consultor deben colaborar codo con codo con independencia del contrato, y otra cosa es hacerlo. No es lo mismo predicar que dar trigo.

Tradicionalmente han existido y existen dos tipos de contratos claramente diferenciados:

  • Contratos por horas. Oh, los proyectos por horas. Escasos y deseados. Es la gloria de cualquier consultaría. Cualquier retraso es siempre compensado por el cliente. Si después de 5 meses el proyecto aún no está terminado, es porque falta análisis, diseño, pruebas o lo que sea. Por supuesto, no es difícil de imaginar que el cliente evita contratar proyectos por horas, y este tipo de contratos se reserva para mantenimientos, pequeños evolutivos, bolsas de horas, o simple subcontratación de recursos....

  • Proyectos a precio cerrado. En este caso, el alcance y el precio es acordado al principio del proyecto y cualquier retraso es asumido por el consultor (de los "adelantos" ya tal). Teóricamente es todo muy sencillo: Solo es necesario calcular los materiales que harán falta, las nóminas del equipo, añadir un margen, etc. Este es, evidentemente, el método preferido por el contratador.

No desvelo ningún secreto al señalar los efectos indeseables que generan estos tipos de contratos. Las consultoras están obligadas a sobrevalorar el esfuerzo de cualquier proyecto para protegerse de posibles retrasos. Y los clientes utilizan la fuerza que les proporciona la aceptación del proyecto para alargarlo y pedir extras a base de lecturas imaginativas del "alcance". O requerimientos de última hora. O por mis cataplines:

SIN ESTO QUE PIDO AHORA EL PROYECTO NO SIRVE PARA NADA (Super jefe en la reunión de cierre)

Por supuesto, ninguna consultora puede tolerar tener un equipo de 5 o 6 personas durante un par de meses cerrando flecos y sin facturar. Conozco un amigo que ha visto equipos de 10 personas trabajando "gratis" (de manera no planificada) durante meses. Por supuesto, se buscarán el modo de facturarlos y al cliente no le saldrá gratis (se facturará en el siguiente proyecto, ya sea sobreestimando los costes o reduciendo la calidad).

En serio, clientes y consultoras, los REYES NO EXISTEN.

Esos contratos tradicionales tienen sentido para contratar la construcción de una autopista o para hacer los planos de una casa. El alcance y los requerimientos en esos casos están claros, y clientes y proveedores han participado en proyectos similares. En el caso de la consultaría tecnológica (estoy hablando de proyectos de desarrollo, y específicamente de Business Intelligence), el alcance esconde sorpresas y los requerimientos se van descubriendo tras cada reunión. El grado de indefinición y los riesgos son mucho más elevados en nuestro caso. Si no cambiamos la manera de trabajar, con independencia del tipo de contrato escogido, es solo cuestión de tiempo que clientes y proveedores se estén engañando mutuamente... y sabiendo mutuamente que son mutuamente engañados. No os riáis que hablo en serio. Conozco un amigo que pedía 10 manzanas a 1 euro porque necesitaba 2 sandías de 5€. En fin...

Por lo anterior, creo que la apuesta por las metodologías ágiles ha de reflejarse de algún modo desde el contrato mismo. En caso contrario, más pronto que tarde empezarán a surgir bandos y tiranteces que afectarán negativamente al proyecto... Más controles, más seguimientos, más listados de cosas con las que defenderse o atacarse.... Y menos entregas frecuentes.

La solución

DISCLAIMER: La solución que propongo es puramente teórica, y forma parte de una guerra que de momento voy perdiendo. No penséis que hablo por experiencia. Cualquier cambio es complicado, y clientes y consultoras seguirán empleando sus viejas armas para defender lo que creen que los beneficia. Se desconocen los efectos a largo plazo. Si estás embarazada o crees que puedes estarlo, consulta tu abogado. No emplear sobre lactantes.

La solución es trabajar por iteraciones. No es un proyecto a precio cerrado (pero se le parece), ni es un proyecto por horas o por jornadas (pero se le parece).

En un proyecto por iteraciones el precio es conocido (lo que gusta al cliente... y también al consultor) y la duración también es conocida de antemano (lo que gusta al consultor... y también al cliente).

La teoría es relativamente sencilla:

  • En lugar de planificar un proyecto de 9 meses con 3 meses de análisis, 3 meses de diseño, y 3 meses de construcción, debes planificar un proyecto de 9 iteraciones de 1 mes cada uno.
  • Cada una de estas iteraciones tendrá un entregable. Insisto, cada iteración debe tener un entregable funcional. No un diseño o un powerpoint. Software que funciona. Debemos entregar valor para el cliente en cada una de las iteraciones.
  • Debemos empezar desarrollando aquellos aspectos más importantes y prioritarios (siempre y cuando estén suficientemente definidos).
  • Cada iteración tendrá su propio alcance. Al comenzar la iteración, ese alcance debe estar suficientemente acotado (sí, hemos de ser capaces de describir suficientemente el resultado de un mes de trabajo).
  • La iteración se cierra en la semana prevista, por definición. Se entrega lo que ha podido hacerse. El cliente debe revisarlo, trasmitir su feedback y replanificar el proyecto.
  • El proyecto finaliza 3 o 4 semanas después de finalizar la última iteración. Punto. Se abonan todas las facturas y clientes y consultores se dan un beso.
  • Si es necesario, se contratan más iteraciones y se dan nuevos besos.

Este modo de trabajo tiene algunas implicaciones positivas que a mi me resultan evidentes (y a ti no sé):

  • Los consultores no necesitan sobreestimar costes ni los clientes necesitan un abogado para escribir o interpretar los requerimientos.
  • Clientes y consultores pasan a ser un mismo equipo. No hay razón para mirar el contrato ya que ambos saben que finalizará en la fecha prevista.
  • El equipo conoce el ritmo de trabajo. Cada mes hay un entregable, y existe visibilidad sobre lo que se ha hecho (y sobre lo que no ha podido hacerse).
  • Por lo anterior, es fácil replanificar mensualmente el trabajo y tener una idea realista sobre lo que se alcanzará al finalizar el proyecto (y lo que no y deberá renunciarse a ello o posponerse para siguientes proyectos).
  • El esfuerzo de "seguimiento" y "perseguimiento" es menor. No andamos valorando si tal funcionalidad está al X%. Eso es siempre una farsa. Deja al equipo de desarrollo trabajar y al finalizar la iteración tendrás el resultado.

Y algunas implicaciones negativas... ¿negativas?

  • El cliente debe involucrarse más. Debe ir definiendo y validando el proyecto durante mucho más tiempo. Esto no es como comprar un coche que te entregan las llaves cuando está listo. En el caso de los proyecto IT, el coche lo has de construir tú...
  • El consultor no puede escudarse en un contrato o en un acta para no hacer algo que solicita el cliente. El consultor ha de ser flexibile, diseñar y construir sabiendo que los requerimientos pueden cambiar. Cambiarán seguro, de hecho.

Este método no te asegura el éxito del proyecto. Únicamente te asegura descubrir pronto que vas por el buen o mal camino. Si eres cliente, en la tercera o cuarta iteración ya debes tener una idea de la capacidad de trabajo del equipo. Debes decidir si te conformas con ello o decides cancelar el proyecto y probar con otro proveedor. La alternativa no es, desde luego, esperar al último día para decir que además quieres esto u aquello. Lo verdaderamente prioritario ya deberías tenerlo desde hace meses, y lo que falta por hacer, probablemente, no sea tan importante como piensas...

Sin duda, al terminar el proyecto quedarán cosas por hacer y otras podrían mejorarse. Es estéril discutir en ese momento si se debe a la mediocridad del equipo de desarrollo, a la indefinición de los usuarios. Unos dirán que el cliente no proporcionó los medios adecuados, otros que el proyecto estaba mal planificados desde el inicio, etc... Con toda seguridad, la causa es la suma de todas esas cosas al mismo tiempo. Usuarios, clientes, gestores y técnicos son culpables por igual de resultado. Cada uno tiene su parte de culpa y su parte de mérito. Por eso son un equipo.

Esos problemas, de existir, deberían haberse detectado y gestionado durante el proyecto. Si eres cliente, y crees que la culpa es de los consultores, trata de buscar soluciones cuanto antes. Los problemas no se resuelven solos. Si no te gusta su trabajo, échales al tercer mes, o al cuarto, o al quinto, o al sexto... O propón soluciones. Involucrarte y pon más recursos. En el único momento que no puedes quejarte es al final del proyecto. En ese momento la culpa es solo tuya por no haberlos echado antes.

Lo que queremos evitar son cosas así:

¿Cómo puede ser que un proyecto, tras 10 años, no esté en producción? RT si te parece inadmisible. A las pocas semanas debería estarlo.

Las claves

Tras el sensacionalista título del artículo, me veo obligado a señalar dos claves (distintas que las que señale la semana pasada, por cierto):

  • Entrega frecuente de resultados. Hemos de ser transparentes. Mostrar cada mes hasta donde hemos llegado y tener un listado actualizado realista de hasta donde llegaremos.
  • Flexibilidad. Los requerimientos se van descubriendo a lo largo del proyecto. El cambio es la norma. Hemos de ser flexibles para hacer cosas de más y que nadie había pedido, y flexibles para hacer cosas de menos que no son tan importantes o tal vez son demasiado complicadas. Eso nos obliga a ser creativos y buscar alternativas. En equipo todo es mucho más fácil de lo que parece...

Me dejo muchísimas cosas en el tintero. Gestión de expectativas, listado de funcionalidades, la importancia del feedback de los usuarios, los tests, el calendario, los mantenimientos, y cosas así. Tal vez otro día.

Me despido con el último vídeo promocional de Crono que hemos preparado. Espero que os guste. Crono es el software de Business Intelligence más fácil de usar y creado pensando en el usuario de negocio. (¡y desarrollado siguiendo metodologías ágiles, por supuesto!).


Si te ha interesado lo anterior, te encantará este otro vídeo sobre cómo construir un cuadro de mando con Crono Business Intelligence.

Categoría: Definiciones

Comentarios: Ver comentarios

sábado, 20 de junio de 2015

¿Qué son las metodologías ágiles?

Las metodologías ágiles van ganando popularidad en los proyectos informáticos y también en los proyectos de Business Intelligence que interesan a los amables lectores de este blog.

Este modo de trabajo resulta recomendable en aquellos proyectos donde se requiere flexibilidad y donde los requerimientos no son suficientemente conocidos al inicio del proyecto. ¿Os suena?

En este artículo intentaré exponer los principios y características de las metodologías ágiles.

Principios

Los principios tradicionales de las metodologías ágiles se definieron en 2001, en el conocido como "Manifiesto ágil", son cuatro:

  • Personas e interacciones en lugar de procesos y herramientas
  • Software funcionando en lugar de documentación detallada
  • Colaboración con el cliente en lugar de negociación del contrato
  • Responder al cambio en lugar de seguir un plan

El manifiesto defiende que aunque hay valor en los elementos de la derecha, se valoran más y se prefieren los elementos de la izquierda.

Mucha gente asocia esta metodologías ágiles con proyectos sin documentación o proyectos donde existe un control deficiente. Por supuesto, ambas cosas pueden ocurrir, como ocurren en todo tipo de proyectos, pero se trata de una visión simplista o directamente errónea. Lo que defienden estos principios es:

  • La importancia de un equipo fuerte técnicamente, motivado y que sepa coordinarse de manera eficiente y autónoma.
  • El objetivo de cualquier proyecto tecnológico no es documentar, ni siquiera analizar o diseñar el sistema. Lo importante es entregar una solución y que funcione. La documentación, el análisis y el diseño son solo medios para conseguir ese fin.
  • Firmar un contrato, por muy extenso y detallado que sea, nunca ofrecerá unos resultados comparables a la colaboración diaria de todo el equipo. En un proyecto de BI, es muy difícil que el cliente pueda definir los requerimientos con el detalle que un verdadero contrato requeriría. Por ese motivo, es mejor asumirlo, y trabajar con “alcances orientativos”. Por supuesto, para que esto sea posible, es necesario que los proyectos sean cortos y acotados (y no proyectos enormes que intenten abarcarlo todo).
  • Por último, pero no menos importante, las metodologías ágiles asumen que los requerimientos iniciales cambiarán. Los clientes nunca saben el uso que harán de la información disponible hasta que no lo tienen en su escritorio. Hemos de tener un modo de trabajo que permita responder con agilidad a este entorno cambiante.

Características principales

Hasta aquí, unos principios preciosos, pero poco nos dicen sobre cómo trabajar ágilmente. De hecho, existen varias "metodologías ágiles" que se suelen citar, y que cada equipo luego las adapta a sus propias necesidades de manera más o menos estricta.

Personalmente, destaco dos características que deben tener los proyectos ágiles:

  • Entrega frecuente de resultados. Organízate como quieras pero por favor entrega resultados frecuentemente para que el usuario pueda verlos y criticarlo cuanto antes. Olvídate de estar 3 meses diseñando, y 3 meses construyendo. Ni hablar. Hazlo de tal modo que cada 3 o 4 semanas puedas entregar algo de valor al cliente.
  • Simplicidad. Valorar las soluciones sencillas es esencial. Habitualmente, las soluciones excesivamente complejas esconden una pobre comprensión del problema. Además, por supuesto, dificultan exponencialmente el mantenimiento del sistema. El toque de simplicidad debe notarse en todas las áreas del proyecto. Desde las extracciones hasta los informes. Debe darse prioridad siempre a las soluciones sencillas frente a las complejas, a las soluciones automáticas frente a las que requieran un gran trabajo manual, etc. Esta exigencia de simplicidad puede implicar, incluso, la no realización de determinadas tareas o que estas sean pospuestas hasta que se aclaren los aspectos que generan la complejidad. La habilidad de detectar funcionalidades innecesarias es importante (y la falta de simplicidad suele ser un indicador de ello).

Volved a leer el artículo para certificar que no he dicho nada ni he definido ninguna metodología. Sería imposible hacerlo ya que la metodología adecuada en cada caso depende del cliente y de las características del proyecto. Sí que creo que las ideas aquí expuestas son importantes y hay que interiorizarlas para detectar cuanto antes que lo estás haciendo mal. La próxima vez que quieras protestar porque "el usuario no sabe lo que quiere", muérdete la lengua y dí esto otro con pose seria.

Como os amenace con un artículo semanal hasta final de año, podéis contar que volveré a hablar sobre metodologías ágiles, y específicamente sobre sus riesgos y dificultades. Afirmación - apertura.

Categoría: Definiciones

Comentarios: Ver comentarios

domingo, 14 de junio de 2015

Pequeño Bobby Tablas

He añadido en la sección de enlaces de este blog la fantástica página de xkcd, que contiene tiras cómicas tan geniales como esta:

Tira cómica sobre los riesgos de la inyección SQL...

Ya puestos, he aprovechado para actualizar la página de enlaces recomendados de este blog. He tenido que eliminar algunos enlaces a blogs que están más muertos que lo que ha estado éste últimamente. Afortunadamente, otros continúan tan activos e interesantes como de costumbre (Todo BI, Anibal Goicochea., SQL Server Si!, Dataprix, ...).

Seguro que me dejo otros blogs o referentes importantes sobre Business Intelligence. ¿Qué enlace añadirías tú?

Por cierto, ¿Alguien mira aún estas "páginas de enlaces"? ¿Alguien tiene web favoritas que mira regularmente en búsqueda de novedades? Mucho me temo que no. Leemos solo aquello que nos llega a través de las redes sociales o allá donde caemos después de una búsqueda en Google.

Por este motivo, recuerda que si no quieres perderte ningún artículo de este renacido blog de Business Intelligence puedes suscribirte y recibirás por correo electrónico mis ocurrencias... :-)

Categoría: Humor

Comentarios: Ver comentarios

jueves, 4 de junio de 2015

La promesa incumplida del Business Intelligence




Echando la vista atrás recuerdo con nitidez cuales eran las promesas con las que los consultores de Business Intelligence tratábamos de conquistar a nuevos clientes. Eramos jóvenes inconscientes sin mala intención, y si de algo se nos podía acusar era de preocuparnos en exceso por nuestros clientes. No eran presentaciones de venta. Eran declaraciones de amor eterno, y es sabido que lo que se dice por amor no es verdad ni es mentira... Es poesía.

Nuestra poesía afirmaba que comprando nuestra mega-super-plataforma-integrada, el usuario sería autónomo para acceder a su información con facilidad. Ofrecíamos facilidad de uso y autonomía. No penséis que llevo toda la semana buscando para encontrar esta cita....

Cualquier directivo o analista de negocio que tenga que realizar una función de planificación o gestión se va beneficiar en gran medida de un sistema de Business Intelligence por dos razones principales: (1) Las facilidades de análisis que permiten estas herramientas y (2) la autonomía que confiere este tipo de sistemas (Marisa Rodriguez Rodriguez, Deloitte & Touche) (negritas mías)

La anterior cita la he extraído del número de abril del 2001 (sic) de la histórica revista http://www.bi-magazine.com. Hace al menos 15 años que ofrecemos facilidad de uso y autonomía para el usuario... Pero... ¿Lo hemos logrado? ¿Realmente hoy el usuario es autosuficiente para acceder a sus datos de una manera rápida y confiable? ¿Pueden hacer consultas ad hoc? ¿Se sienten todos los usuarios cómodos y capaces con las herramientas que les ofrecemos? No y rotundamente no. Solo unos pocos usuarios expertos son capaces de manejar adecuadamente las herramientas BI actuales. El resto de usuarios siguen delegando estas tareas a eslabones inferiores de la cadena trófica empresarial... hasta llegar al becario externo subcontratado que pica la query según entiende él los requerimientos que le transmiten...

Los paradójico es que la solución a esta problemática es tan conocida como el problema mismo. Las soluciones de BI necesitan una capa semántica. Punto. Es necesaria y lo sabemos desde hace más de 20 años. Los que analizan la información y toman decisiones deben interactuar con la herramienta hablando el lenguaje propio del negocio. A ellos les da rematadamente igual como se construye un datawarehouse , o como hemos transformado o agregado los datos que extraemos de sus sistemas...

Lo verdaderamente importante es "servir" esta información al usuario final en un lenguaje de negocio que él comprenda, con el que se sienta cómodo y que no necesite interpretar a que se refiere. (Jorge Fernández, Abast)

La anterior cita la he rescatado del número de abril del 2006 de Data TI. Hace casi 10 años y no ha habido ningún avance relevante en este aspecto clave y crucial en el Business Intelligence.

Lo peor es que las expectativas no son buenas. Los proveedores tradicionales parecen haber olvidado sus suites de BI y las han abandonado a su suerte hasta que algún cambio de paradigma les permita volver a facturar 500.000 € a sus clientes... Oracle BI tiene el mismo aspecto desde que Sarda presentaba Crónicas Marcianas. Los catálogos de IBM Cognos son un chiste malo. Y veremos la Sagrada Familia terminada antes de que SAP unifique los productos que compró a finales de la década pasada.

A ver si me explico... Sus productos fueros punteros hace mucho y tienen cosas fantásticas... ¡Pero es que no han evolucionado prácticamente nada desde que fueron adquiridos por sus actuales propietarios!. Como consultor de BI, encuentro a diario graves defectos de usabilidad que se arrastran desde hace años, o pequeñas mejoras que nunca se incorporan y que agradecerían mucho los clientes. No me creo que sea yo solo el único que lo vea. Alguien en algún despacho de Palo Alto debe saberlo. Han de saberlo a la fuerza, pero no parece importarles demasiado. Los clientes están ya atados y bien atados, y la preocupación es venderles ahora la cosa aquella del Big Data. o Hana. O Cloud. O...

El Big Data es puro humo para el 99,9% de las empresas españolas. Me niego a creer que el análisis de los tuits (u otra información semiestructurada) pueda aportar más valor que las ventas por semana, producto, y tienda... Y resulta que existen cientos de maneras distintas de ver las ventas por semana, producto y tienda que aún no pueden consumir autonomamente los usuarios. Pero dejo el artículo incendiario sobre el Big Data para otro día...

Lo único mínimamente interesante en el panorama actual son herramientas como QlikView, Tableau, o incluso si me apuras Microsoft BI... Son herramientas que presentan los datos de una manera vistosa y como espera el usuario, pero tienen un grave pecado original. Estas herramientas carecen de capa semántica y por este motivo el usuario no tiene la capacidad de crear sus propias pantallas o análisis.

Y esta es la eterna promesa incumplida. Que miles de millones de euros después, el usuario sigue sin ser autónomo para acceder y analizar SU información con facilidad. Han pasado muchísimos años desde que mentimos por primera vez. Ya no podemos disculparnos atendiendo a la ingenuidad o la inconsciencia. No somos adolescentes enamorados y debemos mirar la realidad sin telarañas en los ojos:

  • La culpa no es del usuario, que es muy torpe, muy funcionario, o que no se leen las actas.

  • No es cierto el mito aquel según el cual todas las herramientas son igualmente buenas y que lo importante es un consultor encorvatado de Andersen Consulting con experiencia y que conozca tu negocio.

  • Tampoco es cierto que el usuario no sabe lo que quiere. Vaya excusa más socorrida.

La pura y dura realidad es que todas las malditas herramientas son un maldito obstáculo entre el usuario y sus necesidades.

Aquí termino por hoy. Solo me ha faltado mentar a vuestra madre. Espero que aprovechéis los comentarios para defenderos :-)

Categoría: Mercado

Comentarios: Ver comentarios