En el tiempo que llevo trabajando en el mundo del BI, veo una problemática que afecta a todo tipo de empresas, grandes, medianas y pequeñas, sin importar el tamaño del proyecto: La falta definición del proyecto. Si, aunque suene absurdo, una gran cantidad de proyectos de datos, se comienzan sin que estén las bases del proyecto listas, muchas veces, por falta de conocimiento por parte del usuario, otras por falta de tiempo, otras por falta de comunicación, por burocracia y así podría seguir enumerando, los motivos son muy variados.
Esta falta de definición tiene muchísimas desventajas, gastos de dinero innecesarios, gastos de recursos no estimados, iteraciones infinitas entre desarrollador y usuario, hasta incluso, como alguna vez eh visto, no seguir con el proyecto y cancelarlo.
Como desarrollador/Consultor, es nuestro deber guiar al usuario/cliente a no caer en este pozo negro, al fin y al cabo, nos ahorrara algunos dolores de cabeza a nosotros también.
Aquí es importante remarcar que hay algunos datos que son fundamentales, es decir que sin ellos no se podrá comenzar y otros, que no son excluyente tenerlos antes de comenzar, pero que, sin duda, si están, el proceso de desarrollo será más rápido, con menos iteración y mucho más preciso.
Dicho esto, vamos a ello …
Es importante, antes de comenzar a desarrollar, que este definido el alcance del proyecto y el objetivo. Una descripción de lo que se espera sea el producto final. Supongamos, que el producto final será un dashboard. Este punto debe responder lo siguiente: ¿Qué preguntas se desean responder con este cuadro de mando?
Acá se podría hacer un artículo entero sobre este punto, pero en forma resumida y sin entrar en el detalle, será fundamental saber la arquitectura con la que se trabajara, que tipo de base de datos se utilizara, que herramienta de ETL, que orquestador y que herramienta de visualización. Además, habrá que evaluar si la arquitectura que hay es suficiente para lo que se quiere desarrollar o no.
Sin datos no hay proyecto, por ello, es necesario que el usuario nos diga de donde saldrán los datos, si es una base de datos, que tablas y que campos son los que se usaran, si es un fichero, donde se encuentra, que campos usaremos, si son orígenes externo como nos conectaremos, que credenciales necesitaremos, etc.
Aquí, puede pasar también, que no se tenga muy claro de donde salen los datos, a veces pasa y será tarea del desarrollador ponerse a investigar y validar con el usuario que lo que se encuentra es lo que se necesita.
Una vez tenemos el alcance y los objetivos definidos, sabemos que la arquitectura que hay montada es suficiente y ya tenemos los orígenes de datos listos y validados, lo siguiente será dejar el dato listo para ser consumido. Para ello, será fundamental tener definidas las métricas, es decir lo que se quiera medir, las dimensiones y filtros, que serán los campos por los que analizaremos esas métricas.
A modo de ejemplo, imaginemos que lo que el cliente espera como producto final es un dashboard de servicio para poder medir como esta siendo la entrega a sus clientes. Entonces el cliente, nos deberá pasar la definición de esas métricas, las dimensiones y filtros que se quieran usar en el dashboard.
Métricas:
Dimensiones:
Filtros:
Esta es la visión que se querrá tener en la visualización. ¿Se quiere una visión diaria, semanal, mensual, trimestral o anual?
Este es un punto fundamental, ya que todas las métricas se calcularán al nivel de fecha que se quiera visualizar.
En este punto ya nos metemos en un terreno un poco mas complejo y otro punto que seria necesario un articulo completo, pero de forma resumida y sencilla sería definir que puede ver cada usuario.
A modo de ejemplo, supongamos que el cliente para el que estamos desarrollando tiene filiales en diferentes países del mundo, una manera en la que se podría definir la seguridad es filial-usuario, es decir cada usuario podrá ver solo datos de su filial.
En power BI se podría definir el Row Level security. Para saber como configurarlo pueden consultar el artículo Row Level Security Dinámico de mi colega Mariano Canavessio donde lo explica a la perfección.
En Strategy la seguridad es un poco mas compleja y mi colega Joaquin Attanasio explica en su post MicroStrategy Security los diferentes niveles de seguridad.
Este punto no es fundamental antes de arrancar el proyecto de BI, ni tampoco tiene que venir de parte del cliente. Aquí el desarrollador podría hacer propuestas visuales. Claro está, que si el cliente tiene muy claro lo que quiere visualizar y como lo quiere visualizar, se hace lo que se pide, siempre y cuando sea posible hacerlo y caso cerrado.
Como vimos, la documentación previa a un proyecto de BI no es un mero trámite burocrático: es la base que asegura que el desarrollo avance de forma ordenada, con menos retrabajo y con resultados alineados a lo que el negocio realmente necesita. Definir correctamente el alcance, los orígenes de datos, las métricas y la seguridad no solo ahorra tiempo y dinero, sino que evita frustraciones y aumenta las probabilidades de éxito. En definitiva, un proyecto de BI bien definido desde el inicio es un proyecto con mucho más camino recorrido hacia el éxito.
MicroStrategy ofrece varias herramientas de administración en MicroStrategy para facilitar la gestión, automatización y validación de los proyectos. Entre ellas, Command Manager, Integrity Manager y Object Manager son herramientas clave. A continuación, se explica para qué sirve cada una, cómo funcionan y cuáles son sus diferencias.
* Tu información será utilizada exclusivamente para contactarte en relación al Business Data Master. No hacemos spam ni compartimos datos con terceros.