¿Qué gráfico elegir?

domingo, 19 de julio de 2015

He encontrado en el blog de Extreme Presentation este interesante diagrama que muestra diferentes tipos de gráficos en función de la información que se quiera mostrar:

Qué gráfico elegir en un sistema Business Intelligence

Evidentemente, el diagrama es espléndido, y me enorgullece comprobar que Crono Analysis supera con nota el examen, ya que nuestro software de Business Intelligence es capaz de realizar la mayoría de estas visualizaciones.

Entre los pocos (y raros) gráficos que (aún) no podemos hacer están los gráficos de área 3D, las columnas de anchura variable, y alguno más... Son gráficos poco habituales... En cambio, somos capaces de representar algunas visualizaciones que no aparecen en la imagen superior, y que considero que son importantes... Me refiero, en especial, a los gráficos geográficos (¡mapas!), los gráficos de embudo, y alguno más.

La siguiente imagen muestra los gráficos que pueden hacerse a día de hoy con Crono:

Visualizaciones disponibles en Crono Business Intelligence

Como siempre, lo más destacable de Crono no es tanto el número o la cantidad de opciones (que como veis son muchas) sino la facilidad con las que el usuario puede realizar cualquiera de esta visualizaciones a partir de sus datos...

Seguiremos informando.

Business Intelligence fácil (y minimalista)

domingo, 12 de julio de 2015

Hola,

Esta semana estreno un nuevo diseño en nuestro blog de Business Intelligence fácil. El nuevo diseño es más sencillo y minimalista que el anterior. Es curioso que rediseño tras rediseño siempre busco la simplicidad y un aspecto limpio, elegante y profesional... Me pregunto cómo será el próximo rediseño... ¿Y cómo serán los blogs dentro de 10 años? ¿Y cómo serán las aplicaciones BI dentro de 10 años? De lo que estoy seguro es que primarán las interfaces sencillas y muy usables. Se acabaron esas aplicaciones con decenas de botones o funcionalidades que nadie usa... El siguiente chascarrillo muestra claramente lo que quiero decir....

La simplicidad y las tendencias minimalistas marcan sin duda el camino

En fin... El cambio de hoy es probablemente el cambio estético más relevante desde que inicie este blog hace más de 7 años... Aquí dejo las imágenes para recordarlo:

Este era el antiguo diseño del blog BI fácil



Y este es el diseño del blog BI fácil hoy

Como no podía de ser de otra manera, en esta ocasión hemos pensado especialmente en los lectores desde dispositivos móviles. Si lees este blog desde un móvil o tableta, verás que la lectura es más cómoda y ya no es necesario hacer zoom para leer el texto cómodamente, etc...

¿Lo veis todo correctamente?

Espero que os guste.

Dimensiones lentamente cambiantes (SCD)

viernes, 3 de julio de 2015

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 dimensiones 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 sobrescriben los valores

Es el tipo de carga más básico y el más habitual. En este caso, se sobrescriben 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 finalizar 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... :-)

La clave para aplicar metodologías ágiles correctamente

jueves, 25 de junio de 2015

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.

¿Qué son las metodologías ágiles?

sábado, 20 de junio de 2015

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.