La potencia sin control no sirve de nada

¿Quién no se ha encontrado con la siguiente situación? Una organización. Tiene un Data Warehouse. Que recoge toda la información de la organización. Y cuando digo toda, es toda. Sí, todo el mundo tiene en la cabeza tiene la palabra mágica: corporativo.

Pero hasta ahí llegó la parte bonita. El diseño del Data Warehouse no es el adecuado. La información no se carga en el tiempo necesario. El usuario final no recibe la información adecuada en el momento adecuado y no puede tomar las decisiones adecuadas. ¿Qué pasó se pregunta uno?

Al final, un cúmulo de condiciones: considerar el proyecto como cerrado, considerar que no vale la pena tener una estrategia Business Intelligence, considerar que se debe tener una política restrictiva de datos, considerar que no vale la pena proporcionar al usuario con las herramientas adecuadas, considerar que la función del Data Warehouse es simplemente la de repositorio de datos, considerar que la automatización de procesos no es importante,…

…y entonces vienen los problemas de siempre. El usuario final necesita soluciones y aparece los silos de información. ¿Será que no estamos haciendo las cosas bien? Es el momento de tomar las riendas de la situación y encontrar situaciones.

Diseño de un data warehouse: medidas (II)

Continuamos con el tema de los indicadores que empezamos en el post anterior.

Cabe comentar lo siguiente. Es mejor tener pocos indicadores, relativamente fáciles de medir, con los datos actualizados en consonancia a la necesidad de detectar desviaciones o de confirmar resultados, y significativos respecto de nuestros objetivos de control. Y uno se preguntará ¿por qué? Es cuestión de economía de la atención. Nuestra percepción está limitada a manejar una cantidad relativa de conceptos. Más allá de eso ya no nos resultan prácticos.

Además, siendo formales:

• Los indicadores por sí solos no aportan información. Es preciso complementarlos con una documentación que ayude a interpretarlos.
• No todos los indicadores aportan información para todas las audiencias. Hay indicadores que son significativos para quien controla un proceso (ejemplo: tiempo medio de resolución de incidencias), otros aportan información para los responsables de TIC (ratio de satisfacción del usuario), y otros, para la dirección de la organización (coste de no productividad debido a incidencias). Hay que seleccionar el grupo de indicadores que permite a cada nivel poder gestionar objetivos y resultados.
• Se han de aplicar métricas a los procesos cuyo control es básico.
• Los indicadores se han de seleccionar dentro de unas características que se recomiendan:
  • Especificidad: miden algo concreto.
  • Medibles: debemos poder asignar un valor o categoría de manera objetiva y con un esfuerzo razonable. No se debe confundir una indicación con un objetivo.
  • Relevantes: nos ofrecen un dato significativo sobre la pregunta que nos hacemos acerca de lo que queremos medir.
  • Comparables internamente: para preguntas similares, hay que escoger indicadores similares que nos permitan establecer paralelismos.
  • Comparables externamente: nos deberían facilitar la comparación entre los resultados de nuestra gestión con los resultados de otra organización similar, o incluso de un sector distinto.
• Se debe hacer un esfuerzo por crear un clima de credibilidad:
  • Se debe acordar con la dirección cómo se recogen las medidas.
  • Asegurar que éste se lleva a cabo correctamente.
  • Monitorizar el proceso de recogida de datos periódicamente.
  • Asegurar la calidad de los datos. Éstos deben ser auditados periódicamente.
• Disponer de un catálogo de indicadores (jerarquizados) y de su interpretación para cada audiencia.
• Difundir los informes de manera predecible, en las frecuencias de tiempo que sean razonables para la detección de desviaciones y confirmación de resultados y de manera específica para cada audiencia.

Quizá sea coneniente ilustrar tanta teoría. Lo planteamos en un futuro post.

Clasificación espectral de un Data Warehouse

Hay veces que cuando me pongo a divagar, estoy completamente convencido que las términos y los conceptos de otras áreas del conocimiento encajan perfectamente en otros contextos. Esto me recuerda al artículo en el que hablé de la entropía.

Siguiendo con el tema del DWLM, a veces pienso que se podría categorizar un data warehouse mediante una variante de los criterios de clasificación de estrellas existentes (y sí, estamos hablando de una esfera de plasma autogravitante, en un estado de equilibrio hidrostático o muy cercano a él, que genera energía en su interior la cual es sostenida mediante reacciones termonucleares). Y es que claro, dependiendo de su gestión de ciclo de vida, un data warehouse puede mutar su forma. Imaginemos por un momento que existiera una clasificación espectral de un data warehouse como la que sigue:

• Pulsar: un data warehouse que se contrae y se expande repetidamente. Imaginaos un contexto en el que necesitamos una información que debe generarse a partir de la información histórica, pero que su vida útil sólo tiene sentido para un período corto de vida. Se generaría la información, se usaría y se desecharía. 
• Supernova: un data warehouse que explota en tamaño. Las razones para tal situación pueden variar. Pero imaginad la siguiente situación. Una empresa en fase de expansión respecto su modelo de negocio tiene un un sistema de inteligencia de negocio.  Y, con esa fase de expansión, la información que se genera se multiplicará también exponencialmente. También puede aplicarse a una cierta área de una organización y su correspondiente data mart.
• Enana Blanca: un data warehouse que era de un determinado tamaño, pero que debido a diferentes razones ha perdido su funcionalidad llegando a permanecer sin significado real. 
• Gigante Roja: es un data warehouse de gran tamaño que en un cierto momento tuvo una gran expansión pero que ha llegado a una fase de estancamiento y que ahora sólo requiere pequeñas modificaciones o evolutivos menores. Puede contener data marts sin funcionalidad.
• Estrella de neutrones: un data warehouse en fase de enana blanca que recupera su funcionalidad y se transforma en un data warehouse de grandes dimensiones y utilidad.

Y ya fuera un poco de la lista anterior… ¿y si pensamos en un sistema binario? ¿y en agujeros negros? No nos engañemos a veces las comparaciones son odiosas. Imaginaos que el ciclo de vida de un data warehouse tuviera estas similitudes.

Para los que tengan curiosidad por la evolución estelar consulten la wikipedia (otra vez).

Nos dejamos de divagaciones para el siguiente post.