Hoy día se proponen muchas opciones para encarar proyectos de análisis de información. Pero cuando uno las analiza, se reducen a dos.

Se trata de ver donde pararse: en la implementación de componentes de IT separados o en la resolución de los issues de negocio. Ver el árbol o el bosque.


¿Cómo es la historia del BI?

Se trató de la implementación de los componentes, y de sorprenderse que “siempre” faltaba otro más, ya sea porque no performaba, que no cerraban los números, que se dejaban de usar por el negocio.
.

• ¿Se acuerdan de los cubos? La idea era muy buena: tener una respuesta rápida a unas preguntas básicas, pero exigían largos procesos de actualización y no daban la respuesta final para tomar una decisión.
• ¿Del Data Warehouse? Proyectos vendidos estratégicamente que implicaban inversiones fuertes y mucho esfuerzo, pero que por lo general no lograron cumplir las expectativas del negocio. Parecía que todos los datos de la empresa -limpios- iban a estar allí, pero la explotación se delegaba en otros componentes, y en el negocio se armaban mini centros de cómputos para hacer el collage de los datos y presentarlos en planillas personales sin lineamientos de gobierno corporativo.
• ¿De las soluciones de reporting? La provisión de reportes estáticos poco amigables para su uso, con un gradual deterioro de performance, por el crecimiento de volumen de información con el tiempo.
• ¿Del ETL? El proceso de transformación de los datos provenientes de los sistemas transaccionales, con interfaces hacia esas aplicaciones y un fuerte mantenimiento, y que delegan en la base de datos del DW la visión integrada.

 
Hace unos diez años, comprobamos que sólo un tercio de esas iniciativas tuvieron éxito. Y hoy, al ponerse de moda el tema Analytics y proliferar los proveedores, esto se repite en el enfoque de los nuevos proyectos que surgen con el incremento de las fuentes de información, el vuelco de datos en la nube, la incorporación de redes sociales o de IoT y la mejora de performance en el hardware que da apoyo al procesamiento. Pero la clave, sigue siendo la integración tecnológica, la visión del bosque. 

Quienes toman las decisiones sobre las iniciativas de BI en las organizaciones, al no dar el paso para dejar de ver sólo el árbol y encontrar la luz al final, se alejan de sus áreas de negocio, que no se sienten comprendidas en sus necesidades y limitaciones. 

Llegué a la conclusión, después de tantos proyectos en diferentes tipos de organizaciones, que el principal problema fue la integración de la información del mundo transaccional con la visión distinta que pedíamos las personas, que necesitábamos muchos más atributos (algunos de ellos calculados y otros condicionales) de los que venían en los transaccionales. Y ni que hablar cuando había que integrar distintas bases de datos, que hoy es la norma.


Si somos formales podemos hablar de que esto es el inicio al DATA MANAGEMENT: pero hacerlo “popular” es clave para el éxito, para que no sea un proyecto de IT, sino de la ORGANIZACIÓN COMPLETA. Entonces:
 

• ¿Lo que conocimos como Data Warehouse es la herramienta para tener datos críticos Y datos inferidos por áreas usuarias a partir de simulaciones de analistas, o tener distintas versiones o alternativas de presupuestos?  
• O si voy a la nube, ¿me niego a resolver muchas limitaciones que tiene mi demanda? ¿Hasta dónde se puede llegar? ¿No estoy cayendo en prototipos, sin profundidad y sin amplitud (modelos de datos complejos), y no me estoy focalizando en temas meramente operativos?
   

 
Entonces estoy incorporando una capa tecnológica pero no una solución a aspectos cruciales del negocio. Me niego a contar con una herramienta de transformación en serio. 
 

La pregunta es por qué digo eso y allí les cuento mi experiencia con Qlik, en la que pasé de la desconfianza a la sorpresa, y con el tiempo al reconocimiento al valor diferencial (ahora voy con eso) y después a la creación de una plataforma analítica.  
 
 
¿Qué aprendí trabajando con Qlik?

Tal vez lo más importante es que los datos hablan por sí solos, a través de las relaciones entre los distintos valores que toman los diversos campos que se analizan. Poder simplificar ese “descubrimiento” es clave para el éxito de los proyectos.


El segundo factor clave es la posible interacción de “valores de campo” en cientos de campos y no sólo en los que resultan de un query. Eso da una mayor nitidez en la interpretación del negocio, por una asociación de muchos más campos/atributos. Esto le da una visibilidad al análisis que a veces iguala o supera al producto de la “minería de datos”, porque es intuitivo. Se trata de ver el bosque.  

 
Entonces me pasa que, en el mundo actual de sobreoferta de componentes, veo desconocimiento, anteojeras o engaño, basados en la visión del árbol…Como tengo este componente lo trato de imponer como la solución, pero sin ser consciente de las implicancias que conlleva la solución completa. Me imagino que porque puedo almacenar datos en grandes volúmenes puedo ofrecer una visión nítida a partir de ese almacenamiento, como dispongo de capacidad de procesamiento casi ilimitada me animo a ofrecer soluciones que no están probadas. O porque tengo un acuerdo corporativo le impongo al cliente mi componente para que sea el “standard corporativo”. Entonces puedo llegar a plantear la disyuntiva “Árbol o Bosque” para BI. O algo peor:  a partir del posicionamiento de un producto a cero costo, el cliente se ve forzado a invertir en el proyecto seriamente en recursos sin la esperanza de conseguir algo valioso.


Los challenges de una solución de BI son muchísimos (ver artículo de inhibidores de una buena solución de BI). ¿Cómo es posible que a partir de un componente convenzas a un decisor a entrar en una arquitectura que no responde a las necesidades de negocio, incompleta?

 
Y últimamente encuentro una respuesta. Muchas veces la decisión de los productos está en IT y eso implica en esa área varios esfuerzos “especiales”:
 

• Salir del enfoque de standard corporativo
• Ponerse en el lugar del usuario, que necesita ver la luz con sus “lentes” y no con los que usamos en IT
• Que esté abierto a formar parte de un equipo liderado por el negocio, con un ejecutivo a cargo y título para llevar adelante la Transformación Analítica de la empresa
• Que esté dispuesto a ser un habilitador más que el desarrollador/implementador de la solución de ese equipo

 
Hoy el Business Intelligence debe tomar un peso propio mayor.
 

• No puede depender solamente de la visión tecnológica (IT), sino que debe integrar IT con el resto de la organización, sujeto a la planeación de la compañía. (Impulsar los esquemas de Governance de BI multidisciplinarios, IT+Negocio).

• No es del CFO, no es de comercial o de logística. Está directamente relacionado con la innovación de la organización. Y en muchas organizaciones, IT no le puede dar la importancia que tiene para el negocio, o porque no está en la mesa chica, o sino que le asigna un rol inferior, sujeto a algo operativo que es el soporte a la operación, como puede ser un ERP o el Office, y con su asignación de presupuesto alineado con esta priorización. ¿Acaso no es más importante hoy ver cómo me adapto a los cambios del entorno y del mercado, a potenciar y afinar mi propuesta de valor al mercado que atender las urgencias operativas de mi contabilidad, algo que vengo haciendo hace años?

 
Cuando hablamos de ver la luz, acá vienen las elecciones:
 

• Mi pregunta para hacer esta elección en el mundo del BI es: ¿cómo quisiera ver a mi empresa? ¿Qué debo poder hacer para ganar negocios, ganar mercado, ser más eficiente, ser innovador? ¿A qué nivel de detalle debería ver la operación global, las distintas actividades, los N procesos?
• ¿Con qué claridad de información debo tomar cada decisión de negocio? ¿Qué es lo que debo conocer y qué información debería ver integrada al tomar cada tipo de decisión?

 
A partir de allí comienzan a escribirse las reglas de la arquitectura de solución y a partir de allí se empieza a recorrer un camino con altas chances de ser exitoso. No al revés. Porque no se llega.